PHP2Shell: Wie KI zwei kritische PHP-Kernlücken von 2012 ans Licht brachte

Am 21. Oktober 2026 hat das PHP-Projekt vier Notfall-Releases für zwei Schwachstellen auf Engine-Ebene veröffentlicht, die unauthentifizierte Remote-Codeausführung ermöglichen. Die Korrekturen stecken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Beide Lücken, CVE-2026-109618 und CVE-2026-109619, sind mit CVSS v4.0 9,2 bewertet. Die zugrunde liegende Schwäche ist alt. Laut dem technischen Bericht von Calif reicht der älteste betroffene Codepfad bis PHP 5.4.0 zurück. Dieses Release stammt aus dem Jahr 2012, also deutlich mehr als ein Jahrzehnt. Bemerkenswert ist der Fall auch deshalb, weil die Schwäche schon mehrfach bemerkt und dann zu den Akten gelegt worden war.

01Zwei Fehler, eine Ursache

Beide Lücken liegen in der PHP-Runtime, nicht in WordPress, Magento oder einem Plugin. Calif berichtet, ein unauthentifizierter Angreifer könne unter anderem auf Standardinstallationen von Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel und Symfony Code ausführen. Sansec weist darauf hin, dass Shops betroffen sind, selbst wenn ihr eigener Code sauber ist, weil der Fehler in der Engine steckt.

Der gemeinsame Mechanismus ist der Umgang von PHP mit fatalen Fehlerzuständen. Überschreitet eine Anfrage ihr memory_limit (standardmäßig 128 MiB) oder löst einen anderen fatalen Fehler aus, kann die C-Engine ihren Stack nicht Schritt für Schritt abwickeln. Sie ruft zend_bailout() auf, einen Wrapper um longjmp(). Ein longjmp bricht den gerade laufenden C-Code ab, ohne dass halb aufgebaute Datenstrukturen noch fertiggestellt werden können.

Die Hashtabelle hinter jedem PHP-Array, einschließlich $_POST, zeigt das Problem. Der Bericht von Calif, wie ihn Pentera wiedergibt, zeigt: Der Eintragszähler wird erhöht, bevor der Schlüssel allokiert ist. Ein Slot gilt also als belegt, bevor Schlüssel und Wert existieren. Überschreitet die Schlüsselallokation das memory_limit, löst der Bailout genau an dieser Stelle aus. Ein Feld mit verschachteltem Namen veranlasst PHP, den äußeren Namen als neuen Array-Schlüssel einzufügen, sodass der Angreifer die Schlüssellänge kontrolliert. Wählt er sie so, dass das memory_limit überschritten wird, trifft der Bailout genau die Allokation. Die anschließende Bereinigung vertraut dann dem halb initialisierten Eintrag.

Die beiden CVEs verteilen sich entlang des Anfragezyklus:

• CVE-2026-109618: Speicherbeschädigung bei der Behandlung von Out-of-Memory-Situationen, ausgelöst beim Start der Anfrage, bevor irgendein Anwendungsskript läuft.
• CVE-2026-109619: Interner Zustand, der zur Anfrage gehört, überlebt die Freigabe seines zugrunde liegenden Speichers. Eine spätere Anfrage im selben Worker kann diesen veralteten Zustand nutzen, bevor die normale Initialisierung ihn zurücksetzt. Rapid7 berichtet, das Advisory bestätige RCE gegen mod_php über die standardmäßig aktivierte Backtrace-Funktion für fatale Fehler in PHP 8.5 sowie eine RCE über den Session-Lebenszyklus gegen mod_php und FPM.

Die CISA nennt als exponierte Angriffsflächen Apache mit mod_php (das PHP als höchstes Risiko einstuft), PHP-FPM, php-cgi, FrankenPHP und LiteSpeed.

02Warum der Fehler verborgen blieb

Einen Out-of-Memory-Zustand zu erzwingen, lässt sich leicht beschreiben, aber aus der Ferne nur schwer umsetzen. Standardmäßig begrenzt PHP eingehende Uploads über post_max_size auf 8 MiB. Eine so kleine Anfrage kann einen 128-MiB-Heap normalerweise nicht erschöpfen. Calif fand Wege, das zu umgehen. PHP prüft post_max_size gegen den deklarierten Content-Length-Header, erzwingt die Grenze aber nicht gegen die tatsächlich verarbeiteten Bytes. Apache kann daher Chunked-HTTP/1.1- oder längenlose HTTP/2-Multipart-Anfragen ohne aussagekräftige deklarierte Länge durchreichen. Ein zweiter Weg erschöpft das memory_limit mit einer Multipart-Anfrage, die unter post_max_size bleibt.

Die Konfiguration spielt dennoch eine Rolle. CrowdStrike zufolge erfordert der demonstrierte Weg über URL-Kodierung ungefähr memory_limit < 4 × post_max_size, was die ausgelieferten PHP-Standardwerte nicht erfüllen. Rapid7 stellte ebenfalls fest, dass öffentliche Proofs of Concept jeweils nur gegen eine bestimmte Kombination aus Betriebssystem, PHP-Version und Webserver funktionieren und keiner breit zuverlässig wirkt. Das ist eine Grenze der derzeit öffentlichen Werkzeuge. Es macht den Fehler nicht ungefährlich, wenn man ihn bestehen lässt.

Die Vorgeschichte erklärt das Jahrzehnt der Unauffälligkeit. Übereinstimmend heißt es, die Idee, ein Speicherlimit zur Unterbrechung auszunutzen, habe Stefan Esser 2004 veröffentlicht. Ein verwandtes Out-of-Memory-Problem beim Multipart-Parsing wurde 2020 gemeldet (manche Darstellungen nennen 2019), und ein Audit von OSTIF/Quarkslab aus dem Jahr 2024 markierte einen verwandten Fehler, ließ die Ausnutzbarkeit aber unbewiesen. Jedes Mal fehlte einer plausiblen Speicherbeschädigung ein nachgewiesener Weg zur Codeausführung, sodass sie ein Robustheitsfehler mit niedriger Priorität blieb. Aus „könnte Speicher beschädigen“ ein „liefert zuverlässig eine Shell“ zu machen, erfordert anhaltenden, spezialisierten Aufwand, und genau dieser Aufwand hat sich verändert.

03Was die KI tatsächlich geleistet hat

Die Zuschreibung ist komplizierter, als die Schlagzeilen nahelegen. Calif gibt an, die erste Lücke am 1. August 2026 im Rahmen von OpenAIs Initiative „Patch the Planet“ gefunden und am 11. August an PHP gemeldet zu haben. Eine Sekundäranalyse hält fest, Calif beschreibe eine KI-Analyse, die von der Hypothese eines Forschers geleitet wurde, während Wiz die KI als Beitragende über Entdeckung, Exploit-Entwicklung, Angriffserkennung und Patch-Validierung hinweg darstelle. Dieselbe Analyse berichtet, OpenAIs Codex Security habe am 11. August einen unabhängigen Root-Cause-Bericht und am 18. September weitere Angriffsvektoren eingereicht. Die Modellnamen (GPT-5.6 Sol, bei Wiz zusätzlich Gemini 4 Argon) stammen aus Sekundärberichten, nicht aus dem PHP-Advisory.

Nicht alle sehen darin die Entdeckung von etwas Neuem durch KI. Ein Kritiker argumentiert, jedes Element von PHP2Shell habe längst in öffentlichen Trainingsdaten gestanden. Diese Lesart passt zur oben geschilderten Chronik. Sie schärft zugleich den Kern: Der Beitrag des Modells wirkt weniger wie das Aufspüren einer neuartigen Fehlerklasse als wie die geduldige Arbeit, Ausführungspfade nachzuverfolgen, Primitive zu verketten und einen funktionierenden Exploit zu bauen. Ein Bericht beschreibt, wie KI-Agenten Fehler in der Initialisierungsreihenfolge der Hashtabelle sowie Pfade nachverfolgten, in denen beim POST-Parsing auf eine ungültige Zustandstabelle verwiesen wurde. Menschliche Audits waren davor stehen geblieben.

04Offenlegung, Lecks und das Patch-Gerangel

Der koordinierte Prozess wurde gestört. PHP kündigte am 20. Oktober an, das Release erscheine am 21. Oktober um 14:00 UTC. Bitdefender berichtet, Chainguard habe Container-Images mit dem Fix mehr als sechs Stunden vor dem Release veröffentlicht und damit das Embargo gebrochen. Weiter heißt es, PHP erkläre, es seien keine technischen Details durchgesickert, ein Exploit-Video habe aber die Entwicklung von Proofs of Concept beschleunigt. Forscher von Sansec rechneten laut Ars Technica innerhalb von 15 Minuten nach dem Release mit Massenangriffen. Amazon-Verantwortliche sagten laut dem Beitrag von Tech Xplore, Angreifer hätten begonnen, die Lücke „breit gestreut“ auszunutzen. Am 26. Oktober nahm die CISA beide CVEs in ihren Katalog „Known Exploited Vulnerabilities“ auf.

Die Patch-Landschaft ist uneinheitlich. AWS nennt als betroffene Bereiche 8.5.0–8.5.11, 8.4.0–8.4.26, 8.3.0–8.3.35 und 8.2.0–8.2.34, ohne Upstream-Fix für PHP 5.4–8.1. Tenable ergänzt, das PHP-Team habe minimale Quellcode-Backports für 7.4 bis 8.1 bereitgestellt, während 5.4 bis 7.3 vom Projekt nichts erhalten. Übergangseinstellungen helfen nur teilweise. Für CVE-2026-109618 empfiehlt das Advisory memory_limit=-1, nicht überschreibbar gesetzt, ein niedriges post_max_size und Größenbegrenzungen für Anfragen am Proxy. Calif warnt, dass der Verzicht auf das Speicherlimit das Risiko erhöht, dass dem Server der Speicher ausgeht. PHP vertritt die Position, keine Konfigurationsänderung entschärfe diese Schwachstellen vollständig. Betreiber größerer Serverflotten müssen außerdem PHP-FPM oder den Webserver neu starten, damit die gepatchte Runtime tatsächlich geladen wird.

05Was das für Legacy-Code bedeutet

Die praktische Lehre betrifft die Ökonomie der Ausnutzung. Michael Daniel von der Cyber Threat Alliance sagte gegenüber AFP, die Zeit vom Proof of Concept bis zu Exploit-Kits, früher Monate, werde heute in Stunden oder Tagen gemessen. Er sagte auch, die historische Ausnutzungsrate von 5–6 % der Schwachstellen zeige kein Anzeichen eines Anstiegs; geändert habe sich also die Geschwindigkeit, nicht die Menge. Der von Daniel zitierte Ausdruck des früheren NSA-Mitarbeiters Rob Joyce lautet „großer, reinigender Waldbrand alter Software“.

Daraus ergeben sich drei Konsequenzen für die Praxis:

1. „Nicht belegte Ausnutzbarkeit“ ist eine schwächere Verteidigung. Ein 2024 mangels Proof of Concept abgeschlossener Befund lässt sich heute günstig wieder öffnen. Eine Triage, die davon abhängt, dass der Aufwand für Angreifer knapp ist, wird schlecht altern.
2. End-of-Life ist eine Sicherheitsgrenze. Anwendungen auf PHP 8.1 oder früher laufen entweder mit Backports ungewisser Herkunft oder haben gar keinen Fix. Die Migrationskosten sind nun Patch-Kosten.
3. Defensive KI skaliert nur, wenn die Triage mitskaliert. Daniel warnt, ein Großteil des eingehenden Rauschens sei unwirklich oder betreffe Software, die nie dem Internet ausgesetzt war. Maintainer brauchen daher bessere Filter, wenn sich KI-generierte Meldungen häufen.

Unbewiesen bleibt das langfristige Gleichgewicht. Daniel erwartet, dass KI auf Software angewendet wird, bevor sie ausgeliefert wird, was weniger solcher Fehler in neuem Code bedeuten könnte. Vorerst gilt: Eine Speichersicherheitslücke in einer C-Runtime, die 14 Jahre, ein Audit und eine frühere Meldung überstanden hatte, wurde in rund 11 Wochen gefunden, ausgenutzt und gepatcht. Die KI-Werkzeuge, die diese Lücke geschlossen haben, stehen auch Angreifern zur Verfügung.