Am 21. Oktober 2026 veröffentlichte das PHP-Team Notfall-Updates für zwei kritische Schwachstellen zur Remote Code Execution (RCE), die unter dem gemeinsamen Namen PHP2Shell bekannt wurden. Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 befinden sich im PHP-Engine selbst und nicht in einer bestimmten Anwendung. Dadurch ist jeder Server verwundbar, der Web-Anfragen über PHP verarbeitet – einschließlich PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Beide Schwachstellen sind mit 9,2 Punkten nach CVSS v4.0 bewertet und ermöglichen einem nicht authentifizierten Angreifer die Ausführung beliebigen Codes. Behebungen stehen in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 zur Verfügung – ein Update der PHP-Runtime ist die einzige vollständige Lösung.
Technische Details der Schwachstellen
Beide Schwachstellen gehören zur Klasse Use After Free (CWE-416), nutzen jedoch unterschiedliche Mechanismen innerhalb von PHP aus.
CVE-2026-109618 – RCE durch Speicherbeschädigung bei der Behandlung eines Out-of-Memory-Fehlers (OOM). Laut dem offiziellen Sicherheitshinweis verwendet PHP longjmp() für die Behandlung von OOM-Fehlern. In bestimmten Kontexten kann eine Anfrage abgebrochen werden, obwohl interne Daten noch nicht vollständig initialisiert sind. Die Routine zum Beenden der Anfrage verarbeitet dabei ungültige Daten so, als wären sie korrekt. In einer Apache-mod_php-Konfiguration ist dies besonders gefährlich: Die Shutdown-Routine wird bedingungslos aufgerufen, selbst wenn der Start der Anfrage fehlschlägt, und das automatische Parsing des Request-Bodys kann das Speicherlimit erschöpfen, bevor Anwendungscode ausgeführt wird.
CVE-2026-109619 – RCE durch veralteten globalen Zustand. Wie im Sicherheitshinweis beschrieben, kann interner, zu einer Anfrage gehörender Zustand nach dem Freigeben des Speichers erhalten bleiben. Eine nachfolgende Anfrage, die vom gleichen Worker verarbeitet wird, kann diesen veralteten Zustand nutzen, bevor die reguläre Initialisierung ihn zurücksetzt. Bestätigt wurde eine Code-Ausführung über den Pfad „fatal backtrace“ unter mod_php sowie über den Session-Lebenszyklus sowohl unter mod_php als auch unter PHP-FPM.
Neben der Code-Ausführung kann ein Angreifer den Speicher des PHP-Worker-Prozesses auslesen. Dieser kann Passwörter, Authentifizierungs-Tokens, API-Schlüssel und Zertifikate anderer Anfragen enthalten – und das bereits ohne zuvor eine RCE zu erreichen.
Betroffene Versionen und Konfigurationen
Verwundbar sind alle PHP-Versionen unterhalb von 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Der verwundbare Code ist seit mehr als zehn Jahren in PHP vorhanden und betrifft Versionen bis einschließlich PHP 5.4. PHP hebt Apache mod_php als Konfiguration mit dem höchsten bestätigten Risiko hervor: Für CVE-2026-109618 wurde ein Exploit demonstriert, der greift, bevor jeglicher Anwendungscode ausgeführt wird. PHP-FPM ist ebenfalls betroffen: Für CVE-2026-109619 ist ein Exploit-Pfad über den Session-Lebenszyklus bestätigt.
Reaktion der Branche
Noch vor der Veröffentlichung der Patches registrierte Cloudflare nach Angaben des CTO Dane Knecht erste Versuche einer Ausnutzung und rollte Notfallregeln im WAF aus, die als temporäre Maßnahme bezeichnet wurden. Gleichzeitig hat keine Quelle einen erfolgreichen Einbruch bestätigt. Das Unternehmen watchTowr, das CVE-2026-109618 reproduziert hat, verzeichnete mit Stand 11:26 UTC am 21. Oktober keine Ausnutzung in freier Wildbahn. Nach Angaben von Huntress war zum Zeitpunkt der Veröffentlichung ihres Berichts auch kein öffentlicher Exploit-Code verfügbar.
Mehrere Organisationen haben ihre Dienste präventiv abgeschaltet. BambooHR setzte den Betrieb in den USA, Kanada und Irland aus und warnte vor Störungen bei der Lohnabrechnung. In den Niederlanden wurden die staatlichen Portale MijnOverheid und DigiD, die Website der Zweiten Kammer des Parlaments, das nationale Cyber-Sicherheitszentrum sowie mehrere Bildungssysteme deaktiviert.
Warum die Einstellung session.upload_progress.enabled keinen Schutz bietet
Vor der Veröffentlichung der Patches verbreitete sich in der Community intensiv die Empfehlung, session.upload_progress.enabled=0 als Workaround zu setzen. Das Tokioter Unternehmen GMO Flatt Security hatte diese Maßnahme ursprünglich vorgeschlagen, die Empfehlung später jedoch zurückgezogen und erklärt, dass die Einstellung für sich genommen kein vollwertiger Fix sei und mit Umgehungsmöglichkeiten zu rechnen sei.
Die PHP-Core-Entwicklerin Gina Peter Banyard schrieb dazu unmissverständlich: „Das Einzige, was ich sagen kann: Die einzige Schutzmaßnahme ist, PHP zu aktualisieren. Leider weiß ich zu viel.“
Die veröffentlichten Sicherheitshinweise bestätigten: Das Deaktivieren von session.upload_progress.enabled blockiert lediglich die bestätigten Exploit-Pfade für CVE-2026-109619 über Sessions, deckt aber keine anderen Varianten ab und hat keinerlei Einfluss auf CVE-2026-109618. Das Unternehmen watchTowr stuft Änderungen an INI-Dateien als wirkungslos zur Verhinderung einer Ausnutzung ein.
Empfehlungen zu Updates und temporären Maßnahmen
Ein Update der PHP-Runtime ist die einzige vollständige Lösung. Es muss genau die PHP-Instanz aktualisiert werden, die Web-Anfragen bedient (PHP-FPM, mod_php oder CGI), anschließend sind Apache, PHP-FPM und alle langlebigen Worker neu zu starten. Das Aktualisieren von Anwendungen (WordPress, Laravel usw.) aktualisiert die PHP-Runtime nicht.
Ist ein sofortiges Update nicht möglich, reduzieren laut dem offiziellen PHP-Sicherheitshinweis die folgenden Maßnahmen das Risiko über bestimmte Angriffspfade, machen den Server jedoch nicht sicher:
- Für CVE-2026-109618:
memory_limit=-1setzen, sodass Anwendungen den Wert nicht überschreiben können;post_max_sizeniedrig halten; Beschränkungen für die Request-Größe auf Webserver- oder Proxy-Ebene durchsetzen. PHP warnt: RLIMIT_AS oder RLIMIT_DATA sind kein Ersatz – sie können denselben verwundbaren Pfad auslösen. - Für CVE-2026-109619:
session.upload_progress.enabled=0setzen und alle Worker neu starten; unter PHP 8.5 zusätzlichfatal_error_backtraces=0konfigurieren. - Isolation: CERT-EU empfiehlt, internetzugängliche PHP-Anwendungen bis zur Installation des Patches von öffentlichen Netzen zu isolieren – etwa durch VPN, Allowlists für Clients oder Authentifizierung am Perimeter.
- Minimierung der Auswirkungen einer Kompromittierung: Das Datenvolumen auf dem Server verringern, gespeicherte Zugangsdaten und Cloud-Rollen entfernen, Privilegien einschränken und sicherstellen, dass Logs in einem geschützten Speicher abgelegt werden.
Nicht unterstützte PHP-Versionen
PHP 8.1 und älter erhalten vom PHP-Projekt keine Updates mehr. Angesichts der Kritikalität der Schwachstellen hat das PHP-Sicherheitsteam jedoch minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1 veröffentlicht. Linux-Distributionen und LTS-Anbieter können eigene Fixes bereitstellen – prüfen Sie den Changelog des Pakets auf die betreffenden CVEs und nicht ausschließlich die Versionsnummer, wie es Debian empfiehlt.
Erkennung und Monitoring
Nach den Empfehlungen von Huntress zeigt sich die Ausnutzung solcher Schwachstellen meist durch verdächtige Kindprozesse, die von PHP-Workern erzeugt werden – Shells, Interpreter, Download-Utilities und Reconnaissance-Kommandos. Diese Indikatoren sind allgemeine Anzeichen einer PHP-Kompromittierung und nicht spezifisch für PHP2Shell.
Die Forscher, die die Schwachstellen entdeckt haben, empfehlen nach dem Update eine Überprüfung der Logs auf: ungewöhnliche Multipart-Anfragen in Kombination mit Speicherlimit-Fehlern oder wiederholten HTTP-500-Antworten; ungewöhnlich große PHPSESSID-Cookies in Antworten; unerklärliche Neustarts von PHP-Workern.
PHP2Shell ist ein seltener Fall, in dem nicht eine bestimmte Anwendung, sondern die Sprach-Runtime selbst betroffen ist, wodurch sogar ein Server mit einer einfachen statischen Seite verwundbar wird. Die Update-Priorität ist maximal: Zuerst Server mit Apache mod_php, danach PHP-FPM. Für nicht unterstützte Versionen sollten Backports angewendet oder die Server vom Internet isoliert werden. WAF-Regeln und Konfigurationsänderungen reduzieren das Risiko auf einzelnen Pfaden, ersetzen aber keinen Patch.
