PHP2Shell-Schwachstellen gefährden fast jeden PHP web server
Die PHP2Shell-Schwachstellen ermöglichen es einem Angreifer ohne Benutzerkonto, über die PHP runtime Code auszuführen, also über die Software-Engine, die PHP-Seiten auf einem web server verarbeitet. PHP hat Fehlerbehebungen in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Laut dem Sicherheitshinweis von PHP bietet nur die Installation einer aktualisierten runtime vollständigen Schutz.
Bei den beiden Schwachstellen handelt es sich um CVE-2026-109618 und CVE-2026-109619. Beide erhielten eine Bewertung von 9,2 nach CVSS v4.0, einer Standardskala zur Einstufung des Schweregrads von Sicherheitslücken. Forscher von Wiz, Calif und OpenAI meldeten die Probleme, die fast jede PHP-Version bis zurück zu PHP 5.4 betreffen. Da sich die Fehler in PHP selbst und nicht im Anwendungscode einer Website befinden, kann selbst eine einfache Seite ohne komplexe Anwendungslogik gefährdet sein.
Laut dem Sicherheitshinweis gehören PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed zu den betroffenen Methoden, PHP bereitzustellen. Apache mod_php, bei dem PHP innerhalb des Apache web server ausgeführt wird, weist das höchste dokumentierte Risiko auf. Forscher zeigten, dass eine einzige nicht authentifizierte Anfrage einen Exploit auslösen konnte, bevor der eigene Code der Website ausgeführt wurde. Ein Update von WordPress, Laravel oder einer anderen Anwendung repariert nicht die darunterliegende PHP-Engine.
PHP-FPM, das PHP-Aufgaben in separaten Prozessen ausführt, verhält sich anders, da ein worker geschlossen wird, wenn eine Anfrage während der Einrichtung frühzeitig fehlschlägt. Die Analyse von PHP zeigt, dass PHP-FPM für eine der Schwachstellen anfällig ist, obwohl für diesen Angriffsweg noch kein vollständiger Exploit demonstriert worden war. Für die andere Schwachstelle wurde remote code execution über mod_php und PHP-FPM nachgewiesen, sodass Befehle von einem anderen System aus ausgeführt werden können. Der Angriffsweg über PHP-FPM hängt von einem Vorgang ab, den die laufende Anwendung ausführt.
Die Auswirkungen beschränken sich nicht auf die Übernahme eines Prozesses. Die Forscher demonstrierten außerdem, wie sich aktiver Speicher von PHP workers bei Anwendungen auslesen lässt, über die sie keine Kontrolle hatten. Dieser Speicher kann Passwörter, Authentifizierungs-Tokens, API-Schlüssel und Zertifikate enthalten, die zu anderen Anfragen gehören. Bei dieser Technik muss der Angreifer nicht zuerst code execution erlangen, und sie hängt nicht von einer Schwachstelle in der oberhalb von PHP installierten Anwendung ab.
Administratoren sollten je nach verwendetem Entwicklungszweig PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 installieren. Anschließend müssen sie Apache, PHP-FPM und alle anderen dauerhaft laufenden PHP workers neu starten, damit der gepatchte Code geladen wird. PHP 8.1 und ältere Versionen werden vom PHP-Projekt nicht mehr unterstützt. Das Sicherheitsteam veröffentlichte jedoch source backports, also an älteren Code angepasste Fehlerbehebungen, für PHP 7.4, 8.0 und 8.1. Das Supportende von PHP 8.2 ist für den 31. Dezember 2026 vorgesehen.
Linux-Distributionen und Anbieter mit Langzeitunterstützung erhielten die patches im Voraus. Ihre Pakete können die Fehlerbehebung daher bereits enthalten, obwohl weiterhin eine älter wirkende PHP-Versionsnummer angezeigt wird. Debian empfiehlt, im Changelog des Pakets nach dem jeweiligen CVE identifier zu suchen, statt sich ausschließlich auf die angezeigte Version zu verlassen.
Vorübergehende Konfigurationsänderungen decken nur Teile der Angriffsfläche ab. Für CVE-2026-109618 empfiehlt der Sicherheitshinweis, memory_limit=-1 festzulegen, damit Anwendungen den Wert nicht ändern können, post_max_size niedrig zu halten und die Größe von Anfragen am web server oder proxy zu begrenzen. PHP warnt davor, RLIMIT_AS oder RLIMIT_DATA als Ersatz zu behandeln, da sie denselben anfälligen Angriffsweg aktivieren können. Für CVE-2026-109619 können Administratoren session.upload_progress.enabled=0 festlegen und jeden worker neu starten. Auf Systemen mit PHP 8.5 sollte zusätzlich fatal_error_backtraces=0 gesetzt werden. Das Deaktivieren des Fortschritts für Session-Uploads blockiert bestätigte Session-bezogene Angriffswege, aber nicht jede mögliche Variante, und bietet keinen Schutz vor CVE-2026-109618.
Das Update führt ein hard memory limit ein. Wird dieses Limit erreicht, beendet PHP den Prozess, ohne shutdown handlers auszuführen, also Aufgaben, die normalerweise beim Abschluss einer Anfrage erledigt werden. Administratoren sollten memory_limit und post_max_size nach dem patching daher mit den legitimen Anforderungen ihrer Anwendungen abgleichen. Um eine mögliche frühere Kompromittierung zu erkennen, empfehlen die Forscher, nach ungewöhnlichen multipart requests zu suchen, die häufig für Datei- und Formular-Uploads verwendet werden, gefolgt von Fehlern wegen des Speicherlimits oder wiederholten HTTP 500-Serverfehlern. Weitere Warnzeichen sind unerwartet große PHPSESSID response cookies und unerklärliche Neustarts von PHP workers.
Angriffsverkehr wurde bereits beobachtet, zum Zeitpunkt des jüngsten Updates war jedoch keine konkrete Kompromittierung eines Servers bestätigt. Cloudflare meldete frühe Angriffe und erklärte später, dass Angreifer ihre payloads geändert hätten, um firewall-Regeln zu umgehen, die das Unternehmen am 21. Oktober um 03:02 UTC standardmäßig aktiviert hatte. Das Unternehmen bezeichnete diese Regeln als vorübergehende Maßnahme und drängte zur Installation des patches. watchTowr meldete zunächst um 11:26 UTC keine Ausnutzung in freier Wildbahn, erklärte dann jedoch um 14:19 UTC, aktive Versuche gegen beide Schwachstellen zu beobachten. Zu diesem früheren Zeitpunkt war keiner der beiden CVE-Einträge im Known Exploited Vulnerabilities-Katalog der CISA enthalten.
Einige Dienste wurden vorsorglich offline genommen und nicht aufgrund eines bestätigten Eindringens. BambooHR setzte seinen Dienst in den Vereinigten Staaten, Kanada und Irland aus und warnte, dass die Lohn- und Gehaltsabrechnung unterbrochen werde, ohne einen Zeitpunkt für die Wiederherstellung zu nennen. Nach Angaben von NOS gingen auch niederländische Dienste offline, darunter MijnOverheid, DigiD, die Website der unteren Parlamentskammer, das nationale Cybersicherheitszentrum und mehrere Bildungssysteme. Das Zentrum erklärte, keinen Missbrauch beobachtet zu haben, riet Organisationen jedoch zur Installation des patches.
Der Zeitplan für die Offenlegung geriet durcheinander, bevor die Fehlerbehebungen verfügbar waren. Ein Beitrag auf Hacker News vom 20. Oktober nannte beide CVEs und behauptete, ihre Offenlegung sei für den 22. Oktober vorgesehen. PHP veröffentlichte an diesem Abend eine Vorabmitteilung und zog die Veröffentlichung auf etwa den geplanten Release-Zeitpunkt am 21. Oktober um 14:00 UTC vor. PHP bewertet beide Schwachstellen mit 9,2 und nicht mit der im Leak behaupteten Punktzahl von 10,0. Die PHP Foundation erklärte später, Calif habe am 20. Oktober gegen 20:00 UTC versehentlich ein Video eines funktionierenden proof of concept veröffentlicht. Chainguard veröffentlichte daraufhin am 21. Oktober um 07:41 UTC erstellte Images mit dem patch, rund sechs Stunden vor der offiziellen Fehlerbehebung. Dadurch konnten die Änderungen untersucht werden, während andere Benutzer noch warteten.
Der anfällige Code existierte seit mehr als einem Jahrzehnt. Die PHP Foundation erklärte, ein core developer habe während eines externen Audits im Jahr 2024 Anzeichen des Out-of-Memory-Problems hinter CVE-2026-109618 bemerkt. Damals sei jedoch noch kein konkreter Weg zu code execution nachgewiesen worden. Vorgeschlagene Fehlerbehebungen bargen das Risiko von Kompatibilitätsproblemen, denial-of-service-Zuständen oder Änderungen für Erweiterungen von Drittanbietern. Die Arbeiten gerieten ins Stocken, weil das kleine Team nur schwer eine Entscheidung treffen konnte. Die Foundation bezeichnete dies als strukturelles Versagen und erklärte, sie habe seitdem ihre Entscheidungsprozesse für Sicherheitsfragen geändert sowie zusätzliches Personal und weitere Werkzeuge bereitgestellt.
Im Jahr 2026 von Calif, OpenAI und Wiz eingereichte Berichte belegten einen funktionierenden Exploit und erhöhten die Priorität der Schwachstelle. Die Forscher erklärten, Modelle künstlicher Intelligenz hätten einem Forscher dabei geholfen, innerhalb von etwa einer Woche Arbeiten abzuschließen, für die ihrer Einschätzung nach ansonsten ein Team mehrere Monate benötigt hätte.