PHP2Shell: Wie Frontier-KI jahrzehntealte PHP-Lücken zur RCE macht

Am 21. Oktober 2026 hat sich der Kern des Internets verrenkt: PHP hat einen Notfall-Release geschoben, weil Wiz Research zwei kritische Schwachstellen im Kern-Engine gefunden hatte, die unter dem Namen PHP2Shell durch die Welt laufen. Die Zahlen, die in den Veroffentlichungen der beteiligten Firmen stehen, sind kein Alarmismus-Beitrag: Wiz beziffert die Reichweite von PHP auf rund 70 Prozent aller Websites, VirusTotal zahlt rund 5,1 Millionen IP-Adressen, die PHP anbieten, und die Schwachstellen tragen CVSS 9.2. Was den Vorfall zur Sache macht, ist ein Detail, das weit über die PHP-Welt hinausreicht: Frontier-KI-Modelle sind der Schritt gewesen, der jahrzehntealte Schwachstellen aus Theorie in Praxis verwandelt hat.

Die Details im schnellen Durchlauf: PHP hat vier Schwachstellen unter zwei CVEs zusammengefasst, CVE-2026-109618 und CVE-2026-109619, beide Memory-Safety-Probleme, die mit unauthentifizierten Anfragen erreichbar sind. Wiz hat gezeigt, dass die Schadenskette ein Skript ausreicht: ein einzelnes Skript, das von WordPress, Drupal und Joomla installierte Instanzen unauthentifizierten Code ausführen lässt. Wer von der PHP-Infrastruktur abhängt, sollte prüfen, welche PHP-Version der eigene Server läuft und ob der Fix vom 21. Oktober 2026 oder ein Vendor-Backport eingespielt ist.

Betroffen sind PHP-Versionen von 5.4 bis 8.5, also jede Release der letzten zehn Jahre. Die gepatchten Versionen sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Wer auf einer Enterprise-Distribution sitzt, hat meistens einen Vendor-Branch, der den Fix zurückportiert - wer die Version auf dem eigenen Server selbstständig verwaltet, hat meistens keine Auskunft darüber, wie schnell das durchs System geht.

Das zweite Schadensszenario ist leiser, aber genauso teuer: Ohne Code-Ausführung lässt sich Arbeitsspeicher der Worker-Prozesse auslesen. Wiz demonstrierte das anhand von Sitzungsdaten: Passwörter, Authentifizierungs-Token, API-Keys und Zertifikate aus fremden Anfragekontexten. Für einen Verteidiger bedeutet das: Der Auswirkungsrahmen der Schwachstellen reicht von Code-Ausführung bis zur stillen Datenabfluss - und der Abfluss ist schwerer zu sehen als die Code-Ausführung.

Die Version selbst ist dabei nicht das eigentliche Problem. Die Schwachstellen liegen im PHP-Kern, nicht in einer Anwendung; die Exploit-Skripte laufen unterhalb der Applikationsebene. Für Betreiber bedeutet das: Die eigene Web-Anwendung kann sauber gepflegt sein, und der Server bleibt trotzdem angreifbar. Application-Logs zeigen nichts, weil das Problem nie in der App ankommt. Wer nach Angriffssignalen sucht, muss auf Server- und Runtime-Ebene suchen: auffällige multipart requests, Memory-Limit-Fehler, HTTP-500-Serien, unnatürlich große PHPSESSID-Cookies.

Das eigentliche Signal des Projekts liegt woanders: Wiz beschreibt explizit, dass die Schwachstellen jahrzehntelang in der PHP-Codebasis lagen und niemand sie ausgenutzt hat, weil die Exploit-Kette zu komplex war. Erst Frontier-Modelle - Wiz benutzt Wiz Atlas, Gemini 4 Argon und GPT-5.6 Sol - haben die Arbeit mechanisiert, die Exploit-Kette an mehrere Ziele angepasst und daraus in Stunden ein funktionierendes Skript gemacht. Diese mechanische Umsetzung ist der Wendepunkt: Der Aufwand für die Ausnutzung altbekannter Schwachstellen sinkt radikal.

Der Ablaufplan der Entdeckung liest sich wie ein Werkstattbericht: Am 19. August 2026 fand Wiz die erste Schwachstelle, am 20. und 21. August 2026 wurde unauthentifizierte RCE auf Drupal und WordPress bestätigt, am 24. August 2026 meldete Wiz die Funde an das PHP-Sicherheitsteam, am 21. September 2026 bestätigte PHP die Funde und begann die Koordination, am 21. Oktober 2026 erschienen gepatchte Versionen. 63 Tage vom ersten Fund bis zum Patch, dazwischen Koordinierungs- und Portierungsarbeit.

Der Ablauf der Veröffentlichung hat die Sache nicht leichter gemacht: Am 20. Oktober 2026 kündigte PHP den Notfall-Release für den 21. Oktober an. Noch vor der Fertigstellung der Veröffentlichung traten die ersten Schwächen der Kontrollen zutage, Exploit-Details leakten vor der offiziellen Disclosure. Patchstack meldete laut eigener Auskunft bereits am 21. Oktober um 07:34 Uhr mehrere aktive Ausnutzungsvorfälle bei Hosting-Partnern, Stunden vor der offiziellen Patch-Veröffentlichung. Cloudflare, Fastly, AWS, Google Cloud, Microsoft, Vercel und WAF-Anbieter schoben Mitigations, und PHP hat den Release vorgezogen.

Für Betreiber ist die Handlungsanweisung kurz: PHP aktualisieren, nicht das CMS. Die Sicherheits-Updates betreffen den Kern, und die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 sind aktuell die einzigen offiziellen Fixes. Verteidiger, die den Patch nicht sofort spielen können, haben vom Wiz- und Recorded-Future-Artikel konkrete Detection-Hinweise gezeigt: auffällige multipart requests, Memory-Limit-Fehler, ungewöhnlich große PHPSESSID-Cookies, PHP-Worker-Churn.

Der Blick auf die Zahlen zeigt, warum die Schwachstellen so ernst sind: VirusTotal zahlt rund 5,1 Millionen IP-Adressen, die PHP anbieten, und nur rund 1,1 Millionen davon geben eine Version preis. Von denen, die eine Version nennen, laufen rund 758.000 auf End-of-Life-Branches von PHP 5.4 bis 8.1, nur rund 272.000 auf einem unterstützten Branch. Modat zahlt 4.384.302 PHP-Dienste auf rund 1,9 Millionen Hosts, davon rund 79 Prozent auf nicht mehr unterstützten Branches. PHP 7.4, das seit 2022 ohne Support ist, ist die häufigste Version mit rund 878.000 Diensten. Selbst auf dem damaligen neuesten Stand - den Releases vom 24. September 2026 - zählte VirusTotal rund 85.000 IP-Adressen.

Warum die Reichweite so groß ist, ergibt sich aus der Rolle von PHP im Web: Wikipedia läuft auf MediaWiki, WordPress, Drupal und Joomla sind PHP-Anwendungen, und ein Loch im PHP-Kern betrifft jede Installation dieser Systeme, auch wenn die eigene Anwendung sauber ist. Der Wiz- und Recorded-Future-artikel stellt deshalb klar, dass Angriffsszenarien unterhalb der Applikationsebene laufen: Die eigene Anwendung ist hier nicht der Ort, an dem die Schwachstelle sitzt, aber auch nicht die Stelle, an der man den Angriff findet.

Ein Blick auf die Kette zeigt, dass Frontier-KI-Modelle hier zum ersten Mal die Determinante geschaffen haben, die jahrzehntealte Schwachstellen aus Theorie in Praxis verwandelt hat. Das ist kein PHP-Problem, sondern eine Verschiebung der Schwelle, ab der sich die Ausnutzung einer komplexen Schwachstelle lohnt. Wiz bringt es auf den Punkt: Komplexität war die letzte Verteidigungslinie, und die ist jetzt weg.

Die Konsequenz für die KI-Szene ist hart: Wer Frontier-Modelle für Verteidigungsaufgaben einsetzt, muss damit rechnen, dass dieselben Modelle bei anderen genauso für Angriffsaufgaben laufen. Die Grenze zwischen Sicherheit und Angriff liegt nicht in der KI, sondern in der Hand, die sie hält. Das gilt für die Werkzeugebene, die Wiz mit Wiz Atlas für Verteidiger baut, genauso wie für die Werkzeugebene, die Angreifer mit den öffentlichen Repo-Darstellungen und den geleakten Details benutzen.

Noch ein Blick auf die WAF-Mitigations: Cloudflare, AWS, fastly, Google Cloud, Imperva, Vercel und Fastly haben Filter gebaut, die bekannte Exploit-Pfade filtern, und Wiz beschreibt die Kette als unterhalb der Applikationsebene laufend, damit WAF-Filter die Angriffe nur schwer erreichen können. Der Hinweis aus den Quellen: WAF-Mitigations reduzieren das Risiko, ersetzen den Patch aber nicht.

Für einen One-Person-Betrieb wie meinen ist die praktische Lektion direkt und ohne Alarmismus: Versionshinweise von Runtime-Komponenten ernster nehmen, Update-Pfade für PHP-Runtimes dokumentieren, Runtime-Hygiene ist keine Backlog-Aufgabe mehr. Ich habe die Quellen am 23. Oktober 2026 gelesen und den eigenen Runtimes geprüft: Die Updates sind relevant für jeden Server, der PHP ausliefert - und für alle, die PHP-Dienste betreiben, die keinem direkten Patch-Zyklus unterliegen.

Die Frage, die ich am Ende von der Story stehen lasse, ist nicht, ob PHP gepatcht werden kann. Die Frage ist, was passiert, wenn der nächste jahrzehntealte Schwachpunkt aus der Theorie in die Praxis wandert und der Aufwand dafür über Nacht einbricht. PHP2Shell ist der Nachweis, dass dieser Punkt für die aktuelle Generation von Frontier-Modellen erreicht ist. Und PHP 5.4 bis 8.5 ist eine Erinnerung daran, dass die Schwachstellen, die sich Frontiers-Modelle als Ziel aussuchen, nicht die der letzten Jahre sind, sondern die, die niemand mehr geprüft hat.

Über den Autor: Ich bin Marcel, Grafikdesigner und betreibe das HUNTER-Cyberdeck auf einem Google Pixel 6a. Für diesen Beitrag habe ich am 23. Oktober 2026 die Wiz-Research-Veröffentlichung zu PHP2Shell und den Recorded-Future-Lagebericht gelesen; das Video von Digitale Profis vom 23. Oktober 2026 diente als Newsdesk-Auslöser. Der Newsdesk sichtet 58 Feeds, ich wähle das Thema, Drafts gehen nur mit meinem GO raus.

Quellen mit Abrufdatum 23.10.2026: Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (21.10.2026). Recorded Future / Insikt Group, PHP2Shell Exploitation: Two Critical PHP Flaws Explained (21.10.2026). Digitale Profis, KI-Angriff auf das gesamte Internet (YouTube, 23.10.2026, Newsdesk-Auslöser, als Sekundärquelle markiert).