Am 21. Oktober hat das PHP-Projekt gleich vier Sicherheitsversionen auf einmal veröffentlicht: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Sie beheben die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619, die nach CVSS v4.0 jeweils mit 9.2 bewertet werden. Ausnutzbar sind sie durch nicht angemeldete Angreifer aus der Ferne, im schlimmsten Fall bis hin zur Remote-Code-Ausführung. In der Mitteilung heißt es, es gebe keine vollständige temporäre Gegenmaßnahme; ein Update sei der einzige wirklich gründliche Weg.
Entdeckt wurden die Lücken vom Cloud-Sicherheitsanbieter Wiz, der den Vorfall PHP2Shell getauft hat. Bei der Suche setzte das Forschungsteam von Wiz die hauseigene Plattform Wiz Atlas sowie Googles Gemini 4 Argon und OpenAIs GPT-5.6 Sol ein.
Das Problem steckt in der Engine selbst
Hinter den beiden CVEs stehen insgesamt vier Fehler: ein Use-after-free im Deserialisierer für den Upload-Fortschritt, das Auslesen von Prozessspeicher aus der Ferne, ein Use-after-free im Backtrace bei fatalen Fehlern und eine Typverwechslung (Type Confusion) in OPcache. Gemeinsame Wurzel ist der Umgang von PHP mit fatalen Fehlern, vor allem solchen, die durch erschöpften Speicher ausgelöst werden.
Wird eine Anfrage abnormal beendet, bleiben beschädigte Daten im internen Zustand zurück. Verarbeitet derselbe Worker-Prozess anschließend die nächste Anfrage, nutzt er diesen veralteten Zustand weiter – es kommt zu Speicherlecks oder Speicherkorruption. Selbst ohne Code auszuführen, können Angreifer so Passwörter, Tokens und API-Schlüssel aus dem Prozessspeicher auslesen.
Die Lücke liegt in der PHP-Engine und hat nichts damit zu tun, wie sicher die darüberliegende Anwendung geschrieben ist. Wiz demonstrierte die Ausnutzung anhand der aktuellen Container-Images von WordPress, Drupal und Joomla; schon eine Seite, die nur „Hello World“ ausgibt, kann betroffen sein, und das Speicherleck funktioniert auch dann, wenn die Anwendung nie session_start() aufgerufen hat. Der betroffene Bereich reicht bis zurück zu PHP 5.4: Jede in den vergangenen zehn Jahren veröffentlichte Version enthält mindestens eines der Probleme.
Wo die KI mitgeholfen hat
Die Zeitleiste von Wiz: Die erste Schwachstelle wurde am 19. August entdeckt, am 24. August an das PHP-Sicherheitsteam gemeldet, am 21. September bestätigte PHP sie und begann mit der koordinierten Behebung, am 21. Oktober folgte die Veröffentlichung. Von der Meldung bis zum Patch vergingen fast zwei Monate, der größte Teil davon floss in Behebung und Abstimmung.
Laut Wiz war Argon an Schwachstellenfindung, Exploit-Entwicklung, Angriffserkennung und Patch-Verifikation beteiligt. Die großen Modelle halfen den Forschern, den Exploit-Code an unterschiedliche PHP-Versionen, Konfigurationen und Speicherlayouts anzupassen; schlug ein Versuch fehl, analysierten sie die Ursache und iterierten. Wiz formuliert es so:
"Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit."
(Spitzenmodelle haben diese Hürde erheblich gesenkt und einen lange bestehenden Fehler in einen funktionierenden Exploit verwandelt.)
Wiz zufolge erledigte ein einzelner Forscher innerhalb einer Woche, wofür Spitzenteams früher mehrere Monate gebraucht hätten. Auch OpenAI hat zur koordinierten Offenlegung einen Beitrag veröffentlicht; öffentlichen Berichten zufolge stellte das Unternehmen zudem einen Codex-Skill bereit, mit dem Websites prüfen können, ob sie betroffen sind. Welche Szenarien er genau abdeckt, lässt sich derzeit nicht einzeln überprüfen.
Das Problem der älteren Seiten in China
Viele kleine und mittlere Websites, Firmenauftritte und Foren in China laufen auf PHP, oft in Umgebungen, die per Mausklick über ein Hosting-Panel eingerichtet wurden; dass die Version noch bei 7.x steht, ist keine Seltenheit. Laut der offiziellen Release-Liste decken die Patches diesmal nur vier Zweige von 8.2 bis 8.5 ab. 7.x wird längst nicht mehr unterstützt und bekommt keinen offiziellen Fix, und auch 8.2 wird nur noch bis zum 31. Dezember dieses Jahres gepflegt.
Für Seiten, die noch nicht aktualisiert wurden, nennt Wiz mehrere Anhaltspunkte zur Überprüfung: ungewöhnliche Multipart-Anfragen, unmittelbar gefolgt von Fehlern wegen überschrittenen Speicherlimits, wiederholt auftretende HTTP-500-Antworten, ungewöhnlich große oder fehlerhaft formatierte PHPSESSID-Cookies sowie häufige, abnormale Neustarts von PHP-Worker-Prozessen. Cloudflare, Fastly, Google und weitere Anbieter haben bereits Schutzregeln ausgerollt, sodass Seiten hinter einem CDN teilweise geschützt sind. An der offiziellen Schlussfolgerung ändert das nichts: Erst mit eingespieltem Patch ist die Sache erledigt.
Quellen: offizielle PHP-Sicherheitsmitteilung, Wiz-Forschungsblog, CocoLoop, OpenAI-Sicherheitsmitteilung; geprüft wurden die Nummern der Patch-Versionen, CVE-Kennungen, CVSS-v4.0-Bewertungen und der Umfang der betroffenen Versionen.