PHP2Shell und was Ihr jetzt an Eurem Server prüft

PHP läuft laut W3Techs auf 69,2 % aller Websites, deren serverseitige Sprache bekannt ist. Und genauso groß ist die Angriffsfläche von PHP2Shell. Angreifer können über die Lücken ohne Login fremden Code auf Euren Server bringen und dort Hintertüren einrichten oder Kundendaten abgreifen. Die Stadt Mainz hat ihr Portal mainz.de deshalb vorsorglich abgeschaltet, und laut ZDF reagierten auch Universitäten und Krankenhäuser.

Was hinter PHP2Shell steckt

Hinter dem Namen stehen die Schwachstellen CVE-2026-109618 und CVE-2026-109619, beide mit einem CVSS-Wert von 9,2 von 10 bewertet. Das BSI stuft sie als kritisch ein, weil Angreifer sie aus der Ferne und ohne Anmeldung ausnutzen können. Das Ergebnis heißt Remote Code Execution, also fremder Code, der mit den Rechten des Webservers läuft. Laut dem Advisory des PHP-Teams auf GitHub entsteht der Fehler in der Speicherverwaltung, sobald PHP eine Anfrage nach einem Out-of-Memory-Fehler abrupt abbricht.

Betroffen sind alle PHP-Installationen, die Webanfragen beantworten, von PHP-FPM über Apache mit mod_php bis zu FrankenPHP und LiteSpeed. Am stärksten gefährdet ist mod_php, und laut Wiz genügt schon eine simple Hello World-Anwendung als Ziel. Wiz hat die Lücken am 24. August gemeldet, aufgespürt mit Calif, OpenAI und KI-Modellen, die auch beim Bau der Exploits halfen. Weil KI-Werkzeuge Exploits beschleunigen, erwartete BSI-Vizepräsident Thomas Caspers eine Ausnutzung binnen Stunden: „Es besteht also unverzüglicher Handlungsbedarf!“

Warum vier Tage Vorsprung so viel ausmachen

Amazon hat den ersten Angriffsversuch am 17. Oktober in seinem Honeypot-Netz registriert, vier Tage vor der Veröffentlichung. Die Patches folgten am 21. Oktober um 16 Uhr deutscher Zeit, erste Proofs of Concept kursierten da schon seit Stunden, auch weil Details vor Ende des Embargos durchgesickert waren. Seit dem 24. Oktober ist laut BleepingComputer eine erfolgreiche Codeausführung auf einem Honeypot mit Apache, mod_php und PHP 8.4.26 belegt. Der Countdown ist also abgelaufen.

Die gepatchten Versionen heißen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 7.4, 8.0 und 8.1 gibt es laut Rapid7 lediglich eingeschränkte Backports im Quellcode, weil diese Zweige ihr End of Life erreicht haben. Wer noch mit PHP 7 unterwegs ist, fährt sozusagen mit der TÜV-Plakette von 2022 über die Kö. Der Umstieg auf eine unterstützte Version hat jetzt Vorrang, am besten mit einem Testlauf auf einer Staging-Umgebung, bevor die Live-Seite umzieht.

So prüft und patcht Ihr Eure Website

Wir Agenturleute klingen beim Thema Updates gern wie eine Schallplatte mit Sprung, diesmal gibt uns das BSI Rückendeckung. Bei Shared Hosting spielt meist der Hoster den Patch ein, bei Managed Hosting regelt es Euer Vertrag, und auf dem eigenen VPS seid Ihr selbst am Zug. In WordPress zeigt Euch der Menüpunkt „Werkzeuge“ unter „Website-Zustand“ und „Bericht“ im Abschnitt „Server“ die laufende PHP-Version. Laut Google wird der Patch erst mit einem Neustart der PHP-Prozesse wirksam, weil alte Prozesse den verwundbaren Code im Speicher behalten.

• PHP-Version abgleichen für jede Installation, auch für Testumgebungen, alte Kampagnenseiten und vergessene Microsites im Hosting-Paket
• Beim Hoster schriftlich nachfragen, wann der Patch eingespielt wurde und ob der Neustart erfolgt ist
• Session-Upload-Progress abschalten mit session.upload_progress.enabled=0 in der zentralen php.ini, da ini_set() und .user.ini laut Rapid7 zu spät greifen
• Diese Einstellung auch nach dem Patch behalten, denn die dritte Lücke CVE-2026-115560 betrifft laut Cloudflare auch gepatchte Versionen und wird erst mit dem nächsten regulären PHP-Release geschlossen
• Auf PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen und die PHP-Worker anschließend neu laden
• Multipart-Anfragen am Webserver blockieren, wenn Eure Website keine Formulare mit Datei-Upload nutzt, wie es das PHP-Team als Übergangslösung empfiehlt
• Router, Firewalls und VPN-Geräte prüfen, denn laut BSI veröffentlichen immer mehr Hersteller von Netzwerkkomponenten eigene Sicherheitshinweise
• Automatische Sicherheitsupdates aktivieren für PHP-Pakete auf eigenen Servern, damit der nächste Fix ohne Handarbeit landet

Spuren lesen und Wartung neu aufstellen

Ein Patch schließt die Tür, bereits eingeschleuste Hintertüren bleiben davon unberührt. Amazon rät deshalb, die Webserver-Logs ab dem 17. Oktober nach POST-Anfragen mit der Zeichenfolge PHP_SESSION_UPLOAD_PROGRESS zu durchsuchen. Wer nach wp2shell im Juli schon Logs durchforstet hat, kennt die Reihenfolge: erst die Spurensuche, dann das Altbier. Für das nächste Mal hilft eine feste Wartungsroutine, die Zuständigkeiten vorab festlegt und kritische Updates innerhalb von Stunden einspielt.

• Verdächtige Kindprozesse wie sh, bash, curl oder wget, gestartet von php-fpm oder httpd unter dem Benutzer des Webservers
• Gehäufte Abstürze von PHP-Workern mit dem Signal SIGSEGV, erkennbar am Exit-Code 139
• Auffällige PHPSESSID-Cookies mit mehr als 256 Zeichen, die laut Google auf Angriffsversuche hindeuten
• Ausgehende Verbindungen von PHP-Servern ins Internet, die Ihr laut Google übergangsweise sperren solltet
• Neue oder veränderte Dateien im Webverzeichnis sowie unbekannte Administratorkonten im CMS
• Speicher sichern vor dem Neustart, sobald es Hinweise auf einen Angriff gibt, weil ein Neustart laut Google flüchtige Spuren löscht
• Zugangsdaten tauschen bei begründetem Verdacht, also Passwörter, Datenbankzugänge und API-Schlüssel, und anschließend den Hoster oder einen Sicherheitsdienstleister mit der Forensik beauftragen

FAQs zu PHP2Shell

Was ist PHP2Shell?

PHP2Shell ist der Name für die kritischen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619. Sie erlauben Angreifern, ohne Login aus der Ferne Code auf Webservern auszuführen. Der Name spielt auf Log4Shell an, die große Java-Lücke von 2021. Laut Wiz ist jede PHP-Version des vergangenen Jahrzehnts von mindestens einer der beiden Lücken betroffen.

Welche Versionen von PHP sind sicher?

Gegen PHP2Shell geschützt sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie alle späteren Versionen dieser Zweige. Linux-Distributionen liefern die Fixes teils unter eigener Paketnummer aus, maßgeblich ist dann der Changelog-Eintrag zu beiden CVEs. Für PHP 7.4, 8.0 und 8.1 ist der Wechsel auf einen unterstützten Zweig der sichere Weg. Fehlt Euch der Zugriff auf den Server, nennt Euch der Hoster den genauen Patch-Stand.

Ist Eure Website mit WordPress betroffen?

WordPress läuft auf PHP, deshalb entscheidet die PHP-Version Eures Servers. Geschützt seid Ihr mit einer der Fix-Versionen und nach einem Neustart der PHP-Prozesse. Dasselbe gilt für TYPO3, Drupal, Joomla und Shopware, die ebenfalls auf PHP aufsetzen. Die Lücken sitzen in der PHP-Laufzeit selbst, Plugin- und Theme-Updates lassen sie also unberührt.

Reicht eine Web Application Firewall als Schutz?

Eine Web Application Firewall senkt das Risiko, etwa durch Regeln gegen übergroße Anfragen. Cloudflare hat seine Regeln am 21. Oktober schon vor der Veröffentlichung aktiviert und rät trotzdem ausdrücklich zum Patchen. Die Schutzregeln gelten auch für Kunden im kostenlosen Tarif. Dauerhaft schützt laut PHP-Team ausschließlich das Update.

Gibt es nach den Patches noch eine offene Lücke?

Ja, am 23. Oktober hat PHP mit CVE-2026-115560 eine dritte Lücke gemeldet. Sie betrifft nur ungewöhnliche Session-Konfigurationen, dafür aber auch bereits gepatchte Versionen. Bis zum nächsten regulären Release schützt die Einstellung session.upload_progress.enabled=0. Wer sie bereits wegen PHP2Shell gesetzt hat, ist damit auch hier abgesichert.