PHP2Shell: KI findet jahrzehntealte Kernfehler in PHP

Am 21. Oktober 2026 hat das PHP-Sicherheitsteam Updates veröffentlicht, die mehrere Speicherfehler im Kern der Sprache beheben, zusammengefasst unter den Kennungen CVE-2026-109618 und CVE-2026-109619 und dem Namen PHP2Shell ^[1][2]. Die Bewertung könnte kaum höher ausfallen: beide CVEs tragen einen CVSSv4-Score von 9.2, und nach Angaben von Wiz Research ist jede PHP-Version der letzten Dekade bis zurück zu 5.4 von mindestens einem der Fehler betroffen ^[1]. PHP treibt nach W3Techs-Zählung 69,3 Prozent aller Websites an, deren serverseitige Sprache bekannt ist, darunter WordPress, Drupal, Joomla, Laravel und Magento ^[2].

Zwei Dinge machen diesen Fall zu einem Wendepunkt. Erstens liegen die Fehler unterhalb der Anwendungsebene: Verwundbar ist PHP selbst, nicht ein bestimmtes Content-Management-System. Selbst eine triviale „Hello World“-Anwendung auf einer betroffenen Version ist angreifbar ^[1][3]. Zweitens wurden die Lücken mit Hilfe von Frontier-Sprachmodellen gefunden und zur vollen Codeausführung entwickelt, eine Arbeit, die nach Einschätzung der Beteiligten an der Grenze dessen lag, was menschliche Researcher praktisch leisten können ^[1]. Diese Analyse ordnet Technik, Chronologie und Ausnutzungslage ein und prüft, was an den großen Behauptungen belastbar ist.

Vier Bugs, zwei CVEs, ein Muster

Alle veröffentlichten Schwachstellen sind Speichersicherheitsfehler, die aus derselben Architekturentscheidung erwachsen: PHPs Behandlung fataler Fehler während der Request-Verarbeitung, insbesondere bei Speicherknappheit (Out-of-Memory, OOM). Bricht ein Request unerwartet ab, kann korrumpierter interner Zustand zurückbleiben. Ein späterer Request, denselben Worker-Prozess treffend, verwendet diesen veralteten Zustand weiter, was zur Offenlegung oder Korruption von Speicher führt ^[1]. Wiz hat vier konkrete Bugs an das PHP-Team gemeldet, die unter zwei CVEs gruppiert wurden; nach Einschätzung der Researcher existieren weitere getrackte und vermutlich ungetrackte Varianten desselben Musters, die der Patch an der Wurzel beseitigt ^[1].

Wie die Angriffe technisch funktionieren

Der gemeinsame Nenner ist die Wiederverwendung von Zustand über Request-Grenzen hinweg. PHP verarbeitet mehrere Requests nacheinander in denselben Worker-Prozessen; eigentlich wird der gesamte Request-Zustand am Ende sauber abgeräumt. Ein fataler Fehler im falschen Moment, etwa eine fehlgeschlagene Allokation während der frühen Initialisierung, durchbricht diese Aufräumgarantie ^[1].

Beim Upload-Progress-Bug dekodiert das Session-Modul Session-Daten schon während der Upload-Fortschrittsverarbeitung, in einem Fenster vor der normalen Modulinitialisierung. Der Decoder hält request-eigene Buchhaltung in einer globalen Struktur. Eine fehlgeschlagene Allokation zerstört den Request-Heap und lässt den globalen Unserializer-Zustand veröffentlicht zurück. Beim nächsten Request desselben Workers kann PHP vom Angreifer zurückgeforderten Speicher als lebendige Unserializer-Buchhaltung lesen, ein starkes Korruptionsprimitiv, das Wiz mit der Memory Disclosure kombinierte, um Adressunsicherheit zu beseitigen und unauthentifizierte Codeausführung auf WordPress, Drupal und Joomla zu erreichen ^[1].

Die Memory Disclosure funktioniert über RFC1867-Multipart-Requests: PHP verarbeitet diese vor Abschluss der Modulinitialisierung, und die Upload-Fortschrittsbehandlung kann dabei eine Session-ID in PS(id) publizieren. Bricht ein OOM-Fehler den Request ab, bevor die Bereinigung läuft, zeigt PS(id) auf freigegebenen Speicher. Ein späterer Multipart-Request desselben Workers erreicht den Aufräumpfad, bevor die Session-Initialisierung den Zeiger zurücksetzt; PHP vertraut dem veralteten Zeiger und URL-kodiert zurückgeforderte Heap-Inhalte in ein PHPSESSID-Antwort-Cookie. Der Angriff funktioniert selbst dann, wenn die Anwendung nie session_start() aufruft, und liefert Passwörter, Tokens und API-Schlüssel aus fremden Requests ^[1].

Die beiden Bugs hinter CVE-2026-109619 folgen demselben Muster auf anderen Pfaden: Ein Backtrace des letzten fatalen Fehlers überlebt als executor-globaler Zeiger den Request-Heap, den er referenziert, und kann beim nächsten Request als kontrollierte Use-after-Free-Korruption ausgenutzt werden (demonstriert gegen Drupal). Bei der OPcache-Type-Confusion rückt ein Worker während der Persistierung kompilierter Strukturen eine prozesslokale Grenze vor, bevor die geteilte Grenze publiziert wird; eine Allokationsfehler zwischen beiden Schritten hinterlässt teilpersistierte Objekte, deren Slots ein anderer Worker später mit einem Objekt falschen Typs belegt (demonstriert gegen WordPress) ^[1].

Warum jetzt: Die Exploit-Ökonomie hat sich gedreht

Der verwundbare Code lag mehr als zehn Jahre offen da, ohne dass ihn jemand fand und ausnutzte. Der Grund ist nicht Nachlässigkeit allein: Die Verkettung mehrerer Bugs erfordert präzises Wissen darüber, wie PHP Speicher über Requests hinweg alloziert und wiederverwendet. Unterschiede zwischen PHP-Versionen, Konfigurationen und Anwendungsverhalten brechen Annahmen, von denen ein Exploit abhängt; eine Kette, die gegen ein Deployment funktioniert, muss für das nächste oft mühsam angepasst, getestet und gedebuggt werden. Vor KI war diese Handarbeit schwer umzusetzen und noch schwerer zu skalieren ^[1].

Wiz setzte durchgehend drei Werkzeuge ein: den eigenen Security-Agenten Wiz Atlas sowie die Frontier-Modelle Gemini 4 Argon und GPT-5.6 Sol. Google zufolge trug Gemini 4 Argon maßgeblich zu Entdeckung, Exploit-Entwicklung, Angriffserkennung und Patch-Validierung bei ^[1]. Parallel fand das Unternehmen Calif einen der Fehler mit GPT-5.6 Sol, im Rahmen von OpenAIs Programm „Patch the Planet“; die PHP Foundation würdigte Calif, OpenAI und Wiz für die koordinierte Offenlegung ^[2][3].

Mit Frontier-KI-Modellen und den richtigen Werkzeugen hat ein einzelner Researcher in einer Woche vollbracht, wofür früher ein Weltklasse-Team Monate gebraucht hätte.

Der ökonomische Punkt ist zweischneidig. Dieselben Modelle, die Verteidigern erlauben, jahrzehntealte Fehler systematisch aufzuspüren, senken auch den Aufwand, alte, bislang als praktisch unausnutzbar geltende Fehler in funktionierende Angriffe zu übersetzen und auf neue Zielumgebungen anzupassen ^[1]. Wiz zieht den Vergleich zu Heartbleed und Log4Shell, Schwachstellen, deren eigentliche Gefahr erst Jahre nach ihrer Entstehung sichtbar wurde ^[1][3].

Der Zeitstrahl: 63 Tage von der Entdeckung zum Patch

RCE-Demo Drupal1Tage

RCE-Demo WordPress2Tage

Meldung an PHP-Team5Tage

PHP bestätigt33Tage

Erste Ausnutzung beobachtet59Tage

Patch + Disclosure63Tage

Daten als Tabelle

	Tage seit Entdeckung
RCE-Demo Drupal	1Tage
RCE-Demo WordPress	2Tage
Meldung an PHP-Team	5Tage
PHP bestätigt	33Tage
Erste Ausnutzung beobachtet	59Tage
Patch + Disclosure	63Tage

Eigene Darstellung nach den Angaben von Wiz ^[1] und Tenable ^[2]. Tag 0 ist der 19. August 2026; die Ausnutzungsbeobachtung vom 17. Oktober (Tag 59) stammt von Amazon Threat Intelligence ^[2].

Der ursprüngliche Release-Plan sah den 22. Oktober vor; nachdem die CVE-Kennungen am 20. Oktober auf Hacker News und in sozialen Medien durchgesickert waren, zog das PHP-Team die Veröffentlichung um einen Tag vor und kündigte an, bei konkreten Ausnutzungsbelegen noch früher zu liefern. CERT-EU veröffentlichte zeitgleich das Advisory 2026-018 ^[2]. Die vorschnell kursierenden CVE-Einträge trugen nach Angaben der PHP Foundation einen falschen CVSS-Score von 10.0; die offizielle Bewertung liegt bei 9.2 ^[2].

Verbreitung und aktive Ausnutzung

Zur Größenordnung der Angriffsfläche: Sicherheitsforscher Silas Cutler schätzt grob über 1,3 Millionen potenziell verwundbare, dem Internet ausgesetzte Hosts; eine Shodan-Auswertung von Henk Poley zählt über 1,9 Millionen exponierte PHP-Hosts ^[2]. PHP nennt als gefährdete Server-APIs PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed; das höchste Risiko sieht das Team bei mod_php, wo ein demonstrierter Exploit durch einen unauthentifizierten Request ausgelöst werden kann, bevor überhaupt Anwendungscode läuft ^[2].

Zur Ausnutzungslage liegen mittlerweile mehrere unabhängige Beobachtungen vor: Amazon Threat Intelligence registrierte am 17. Oktober einen Ausnutzungsversuch gegen sein MadPot-Honeypot-Netz, vier Tage vor der Veröffentlichung, mit ungeklärter Herkunft der Exploit-Information. Weitere Versuche folgten am 21. Oktober mit Payloads und Infrastruktur, die auf mehrere Akteure hindeuten; Amazon spricht inzwischen von breiter Ausnutzung in freier Wildbahn und empfiehlt, Untersuchungen mindestens ab dem 17. Oktober anzusetzen ^[2]. Cloudflare-CTO Dane Knecht meldete am 21. Oktober „early attacks“, watchTowr hat beide Lücken reproduziert und beobachtet ebenfalls Ausnutzungsversuche ^[2]. Zur Einordnung: Die PHP Foundation prüfte nach dem Leak kursierende PoCs und identifizierte zum Zeitpunkt der Veröffentlichung keinen funktionierenden öffentlichen Exploit; CISA hatte bei seinem Alert vom 21. Oktober noch keine Ausnutzung beobachtet ^[2].

CISA fordert in seinem Alert vom 21. Oktober zum sofortigen Patchen auf; Organisationen, die nicht aktualisieren können oder noch PHP 8.1 und älter einsetzen, sollen PHP-basierte Systeme offline nehmen, bis ein Update möglich ist. Eine Aufnahme in den Known-Exploited-Vulnerabilities-Katalog war Stand 22. Oktober noch nicht erfolgt ^[2]. Historisch ist das keine leere Drohkulisse: Der KEV-Katalog führt bereits drei PHP-Schwachstellen, darunter CVE-2024-4577 und CVE-2019-11043, die beide nachweislich in Ransomware-Kampagnen genutzt wurden ^[2].

Patches, Backports und Notfallmaßnahmen

Das Update ist nach Angaben des PHP-Teams die einzige vollständige Behebung. Wer nicht sofort aktualisieren kann, findet im Advisory Konfigurationsänderungen, die einzelne Angriffspfade reduzieren, aber keine Installation sicher machen: Für CVE-2026-109618 memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können; für CVE-2026-109619 session.upload_progress.enabled=0 und unter PHP 8.5 zusätzlich fatal_error_backtraces=0. Nach jeder Änderung sind alle PHP-Worker neu zu starten. Ein Container- oder cgroup-Speicherlimit kann als Verfügbarkeitsgrenze dienen, ist aber ebenfalls keine vollständige Abmilderung ^[2]. CERT-EU rät, internetexponierte Anwendungen im Zweifel vom öffentlichen Netz zu isolieren, bis der Fix eingespielt und verifiziert ist ^[2].

Cloudflare hat WAF-Regeln für die bekannten Exploit-Vektoren für alle Kunden einschließlich des Gratis-Tarifs ausgerollt, bezeichnet das aber ausdrücklich als Überbrückung; geschützt ist zudem nur Traffic, der durch Cloudflare läuft ^[2]. Linux-Distributionen und LTS-Anbieter erhielten die Patches vorab; wer Distributionspakete nutzt, sollte deren Advisories prüfen ^[2].

Detection: Woran man Angriffe erkennt

Weil die Bugs unterhalb der Anwendungsebene liegen, liefern Anwendungslogs wenig Kontext. Bis zur Patch-Installation rät Wiz, besonders auf ungewöhnliche Multipart-Requests gefolgt von Memory-Limit-Fehlern oder wiederholten HTTP-500-Antworten zu achten, auf unerwartet große oder fehlgeformte PHPSESSID-Antwort-Cookies und auf unerklärliche PHP-Worker-Neustarts ^[1]. Amazon empfiehlt, die Untersuchung mindestens ab dem 17. Oktober zu beginnen, nicht erst ab dem Veröffentlichungsdatum ^[2].

Einordnung: Der Heartbleed-Moment der KI-Security-Forschung

PHP2Shell ist nicht die erste KI-gefundene Schwachstelle, aber die bisher folgenreichste: Infrastruktur, die etwa siebzig Prozent des Webs trägt, ein Jahrzehnt alter Fehler, zwei kritische CVEs und eine Exploit-Kette, die nach Einschätzung der Finder an der Grenze menschlicher Machbarkeit lag ^[1][3]. Erwarten lässt sich eine Serie ähnlicher Fälle: Fehler, die alt, bekannt schwierig und bislang praktisch unausnutzbar waren, werden zu realistischen Zielen. Für Verteidiger ist dieselbe Entwicklung eine Chance, Altlasten in Kernsoftware systematisch aufzuarbeiten, bevor Angreifer es tun; die koordinierte Arbeit von Wiz, Calif, OpenAI, dem PHP-Team und den großen Edge-Anbietern in diesem Fall zeigt, wie das aussehen kann ^[1][3]. Für Betreiber bleibt die unbequeme kurzfristige Wahrheit: Wer PHP im Internet betreibt, muss jetzt patchen, und wer nicht patchen kann, muss Systeme vom Netz nehmen ^[2].

Methode

Grundlage sind der technische Bericht von Wiz Research ^[1], das fortlaufend aktualisierte FAQ von Tenable Research (Stand 22. Oktober) ^[2] und die Morning-Tokens-Ausgabe vom 22. Oktober ^[3], alle am 23. Oktober 2026 selbst geöffnet. Eigene Rechnungen: alle Tagesdifferenzen im Zeitstrahl (z. B. 19. August bis 21. Oktober = 63 Tage); sie sind im Text als eigene Rechnungen gekennzeichnet. Technische Beschreibungen der vier Bugs folgen ausschließlich dem Wiz-Bericht.

Grenzen

• Die Exploit-Demonstrationen stammen von Wiz und wurden von keiner unabhängigen Stelle repliziert; watchTowr hat die Lücken reproduziert, aber nicht die vollständigen Ketten von Wiz verifiziert ^[2].
• Aussagen zur Ausnutzung in freier Wildbahn beruhen auf Beobachtungen von Amazon, Cloudflare und watchTowr; wie viele Versuche gegen reale Systeme erfolgreich waren, ist offen ^[2].
• Die Zahl der Varianten desselben Fehlermusters im PHP-Code ist unbekannt; Wiz spricht von weiteren getrackten und vermutlich ungetrackten Varianten ^[1].
• Die Host-Schätzungen (1,3 beziehungsweise 1,9 Millionen exponierte Systeme) sind grobe Internet-Scans, keine Zählung tatsächlich verwundbarer Installationen ^[2].

Quellen

1. PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet, Wiz Blog (abgerufen 2026-10-23) ↩1 ↩2 ↩3 ↩4 ↩5 ↩6
2. php2shell (CVE-2026-109618, CVE-2026-109619): Frequently asked questions about critical PHP remote code execution vulnerabilities, Tenable (abgerufen 2026-10-23) ↩1 ↩2 ↩3 ↩4 ↩5 ↩6
3. AI News Oct 22, 2026: PHP2Shell, Railway breach, Claude Duet, Morning Tokens (abgerufen 2026-10-23) ↩1 ↩2 ↩3 ↩4 ↩5 ↩6