Vorab durchgesickerte Schwachstellen: Angriffe liefen vier Tage vor dem Patch
Am 21. Oktober 2026 veröffentlichte das PHP-Entwicklungsteam Sicherheitsupdates für zwei kritische Schwachstellen zur Remote-Code-Ausführung (RCE): CVE-2026-109618 und CVE-2026-109619. Beide Schwachstellen wurden nach CVSS v4.0 mit 9.2 bewertet. Die offiziellen Fehlerbehebungen erstrecken sich über PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für die längst eingestellten Zweige PHP 7.4, 8.0 und 8.1 stellte das Sicherheitsteam ausnahmsweise quelltextbasierte Backport-Patches bereit.
Klassische koordinierte Offenlegungsverfahren (Coordinated Vulnerability Disclosure) basieren auf der Annahme, dass Patches Verteidiger erreichen, bevor funktionierende Exploits im Umlauf sind. Bei PHP2Shell versagte dieser Mechanismus vollständig. Noch vor der Veröffentlichung der Patches schlug das Sicherheitsunternehmen Huntress unter dem Titel „Leaked Critical PHP Vulnerabilities“ Alarm: Technische Details waren vorab durchgesickert. In einem beispiellosen Schritt veröffentlichten die PHP-Maintainer auf php.announce die Ankündigung Nr. 509 und forderten Systemadministratoren weltweit auf, sich unverzüglich vorzubereiten. Ars Technica berichtete über diesen ungewöhnlichen Schritt und betonte, dass der öffentliche Frühwarnruf der Maintainer den Kontrollverlust über den Prozess verdeutlichte.
Angreifer warteten nicht auf die offiziellen Patches. Datadog Security Labs hatte bereits vor der Veröffentlichung eigenständig einen funktionierenden Exploit nachgebaut. Das AWS Threat Intelligence Team bestätigte über sein MadPot-Honeypot-Netzwerk, dass bereits am 17. Oktober reale Ausnutzungsversuche erfasst wurden – vier Tage vor der offiziellen Behebung. Öffentliche Server wurden aktiv sondiert, lange bevor Verteidiger offizielle Warnmeldungen erhielten.
Das Sicherheitsunternehmen Sansec warnte eindringlich: Innerhalb von 15 Minuten nach Veröffentlichung der Patches würden automatisierte, weltweite Angriffe einsetzen. Bis zum 21. Oktober bestätigte Datadog unter Berufung auf Telemetriedaten von Patchstack, dass sich zahlreiche reale Angriffe und wahllose Scans im Internet ausbreiteten. Angreifer und Verteidiger erhielten den Patch-Code zeitgleich – das reguläre Upgrade-Zeitfenster schrumpfte schlagartig auf null.
Abbildung: Übersicht über Angriffsvektoren und Auswirkungen von PHP2Shell. Quelle: Datadog Security Labs
Ausführung vor dem App-Code: Parser-Bereinigung übergibt die Shell
Viele Sicherheitskonzepte für Webanwendungen stützen sich primär auf API-Gateways, Routing-Authentifizierung und Quellcode-Audits. In den Praxistests von Datadog Security Labs umging PHP2Shell jedoch sämtliche Logiken der Anwendungsebene. In einer Testumgebung mit PHP 8.5.11, Apache prefork mit mod_php sowie standardmäßigen Grenzwerten (memory_limit=16M, post_max_size=64M) reichte ein einziger, unauthentifizierter HTTP-POST-Request aus, um den Server vollständig zu kompromittieren.
Der Exploit greift auf der C-Ebene der PHP-Laufzeitumgebung. Sobald die bösartige Anfrage den Server erreicht, wird sofort ein Parsing-Fehler provoziert. Zu diesem Zeitpunkt wurde die Ausführung noch an kein einziges Anwendungsskript übergeben. Das Verhängnis tritt in der Bereinigungsroutine von PHP für fehlgeschlagene Anfragen ein: Dort werden die im Payload platzierten Systembefehle unmittelbar ausgeführt. Selbst wenn auf dem Server nur ein minimales Skript läuft, das lediglich einen statischen Text ausgibt, wird das System im Augenblick des Parsing-Fehlers kompromittiert.
Diese Schwachstelle betrifft nahezu alle gängigen Betriebsumgebungen. Laut Berichten von Huntress und technischen Verzeichnissen sind Versionen von PHP 5 bis PHP 8 betroffen. Zu den betroffenen Laufzeiten zählen Apache mod_php, das klassische php-cgi, die Produktionsstütze PHP-FPM sowie FrankenPHP und LiteSpeed. Authentifizierungen auf Anwendungsebene können in der Parsing-Phase schlicht keine Barriere aufbauen.
Abbildung: Aufrufablauf, bei dem die Parser-Bereinigung Systembefehle ausführt. Quelle: Datadog Security Labs
Zähler vor Speicherallokation: Die Ursachen der beiden CVEs
Die beiden Schwachstellen nutzen unterschiedliche Schwachpunkte im Verarbeitungszyklus von HTTP-Anfragen aus. CVE-2026-109618 beruht darauf, dass eine Bereinigungsroutine nach einem Allokationsfehler fälschlicherweise ungültige Datenstrukturen als legitim ansieht. Der Auslöser liegt in der Kernfunktion _zend_hash_str_add_or_update_i() der Zend Engine. Beim Eintragen von Schlüssel-Wert-Paaren in eine Hash-Tabelle inkrementiert diese Funktion den Bucket-Zähler, noch bevor sie Speicher für den Schlüsselnamen reserviert.
Übersteigt die Anforderung des Schlüsselnamens das memory_limit, wirft die Zend Engine sofort einen fatalen Fehler. Zu diesem Zeitpunkt zählt der interne Zähler den noch nicht zugewiesenen Bucket-Knoten jedoch bereits mit. In diesem Knoten verbleiben uninitialisierte Speicherreste (Dirty Bytes) aus früheren Heap-Operationen. Die anschließende Bereinigung behandelt diese Reste fälschlicherweise als gültige Variablen und versucht, sie freizugeben. Durch die Kontrolle über diese Speicherreste können Angreifer den Aufruf von system() auslösen. Selbst in PHP 8.5.12 wird der Zähler weiterhin vor der Allokation erhöht; der offizielle Patch korrigierte die Fehlerbehandlung, sodass fehlgeschlagene Allokationen keine halbinizialisierten Einträge mehr hinterlassen.
Die zweite Schwachstelle, CVE-2026-109619, nutzt die Wiederverwendung von Zuständen in persistenten Worker-Prozessen über mehrere Anfragen hinweg aus. Unter PHP 8.5 und mod_php können Backtraces fataler Fehler direkt zu beliebiger Befehlsausführung führen. Bei regulären Datei-Uploads werden Session- oder Decoder-Zustände nach fatalen Fehlern an nachfolgende Anfragen weitergegeben. Die in vielen Distributionen standardmäßig aktivierte Option session.upload_progress.enabled läuft im Hintergrund, ohne dass die Anwendung jemals explizit session_start() aufrufen muss.
Um CVE-2026-109619 erfolgreich auszunutzen, müssen aufeinanderfolgende bösartige Anfragen denselben Worker-Prozess treffen. In Multi-Process-Pools oder stark frequentierten Umgebungen sinkt zwar die Wahrscheinlichkeit eines Einzeltreffers statistisch, die Kritikalität der Schwachstelle bleibt davon jedoch unberührt.
Abbildung: Mechanismus persistenter Worker-Prozesse bei der Wiederverwendung unreiner Speicherbereiche. Quelle: Datadog Security Labs
Deaktivieren des Upload-Fortschritts genügt nicht: Konfiguration heilt keine Speicherfehler
Unmittelbar nach Bekanntwerden der Schwachstellen empfahl die Community mancherorts, session.upload_progress.enabled = 0 als Übergangslösung zu setzen. Diese Maßnahme birgt jedoch erhebliche Sicherheitslücken. Sie schließt lediglich einen Teil der Upload-Vektoren für CVE-2026-109619, bietet aber keinerlei Schutz gegen die Speicherallokationsfehler von CVE-2026-109618. Bleibt der Allokationsfehler unkorrigiert, beseitigt das Abschalten des Upload-Fortschritts das Risiko keineswegs.
Das offizielle PHP-Team legte daher strikte Richtlinien für Übergangskonfigurationen vor. Für CVE-2026-109618 wird dringend empfohlen, memory_limit = -1 zu setzen. Gleichzeitig müssen Administratoren am Reverse-Proxy die Größe von Anfrage-Bodys strikt begrenzen und auf Containerebene cgroups-Grenzen erzwingen. Prozessbegrenzungen wie RLIMIT_AS oder RLIMIT_DATA dürfen keinesfalls verwendet werden, da genau diese Kontingente die für den Exploit erforderlichen Allokationsfehler künstlich provozieren.
Für CVE-2026-109619 muss unter PHP 8.5 neben der Deaktivierung des Upload-Fortschritts zusätzlich fatal_error_backtraces = 0 konfiguriert werden. Sämtliche Einstellungen müssen vor dem Parsen von Anfragen geladen sein, was einen rollierenden Neustart aller Worker-Prozesse erfordert. CERT-EU riet in der Warnung 2026-018, Systeme ohne unmittelbare Patch-Möglichkeit vorübergehend vom Netz zu trennen. Datadog empfiehlt ergänzend, verdächtige Anfragen bereits an vorgeschalteten Proxys abzufangen.
40 Jahre technische Schulden: Nur ein sofortiger Austausch der Laufzeit schützt
Rückblickend betrachtet zerstörte PHP2Shell nicht nur die Parser-Sicherheit von PHP, sondern das grundlegende Modell geordneter Sicherheitsupdates: Hersteller patchen, Sicherheitshinweise erscheinen, und Administratoren aktualisieren in Ruhe. Durch das vorzeitige Leak und vier Tage vorab stattfindende Angriffe brach das Sicherheitszeitfenster der Verteidiger vollständig zusammen. Da Angreifer und Verteidiger gleichzeitig Zugriff auf die Patches erhielten, begannen weltweite Scans bereits wenige Minuten nach der Veröffentlichung.
IEEE Spectrum brachte das Ereignis auf den Punkt: KI zwingt die Industrie dazu, 40 Jahre an akkumulierten technischen Schulden schlagartig abzutragen. PHP2Shell ist das Paradebeispiel dafür: Das Inkrementieren eines Zählers vor der Speicherallokation war ein über Jahrzehnte unberührtes Muster. Selbst in PHP 8.5.12 wurde lediglich die Fehlerbehandlung nachgebessert, nicht aber die problematische Reihenfolge selbst.
Administratoren, die ihre Infrastruktur auf Kompromittierungen prüfen, sollten auf drei zentrale Indikatoren achten: sprunghaft ansteigende Out-of-Memory-Fehler in der Initialisierungsphase von Anfragen, ungewöhnlich große Formulardaten mit auffälligen Feldnamen sowie unerwartet gestartete Shell-Kindprozesse unter der Benutzerkennung des Webservers. Treten solche Muster auf, deutet dies auf akute Ausnutzungsversuche hin.
Wenn Reaktionszeiten auf null schrumpfen, sind Konfigurationsanpassungen nur ein fragiles Provisorium. Reverse-Proxys können Angriffe zwar dämpfen, die interne Schwachstelle im Interpreter jedoch nicht beheben. Der schnellstmögliche Austausch betroffener Laufzeitumgebungen in allen Produktionssystemen bleibt für Verteidiger die einzige wirksame Schutzmaßnahme.
Referenz-Links:
- Datadog Security Labs Analysebericht zur Schwachstelle
- Offizielle PHP-Sicherheitsankündigung und php.announce Nr. 509
- Huntress Threat Intelligence Bericht
- AWS Security Blog Telemetriedaten
- Ars Technica Hintergrundbericht
- CERT-EU Sicherheitswarnung 2026-018
- IEEE Spectrum Schwerpunktbericht
