PHP2Shell: KI half, kritische RCE-Sicherheitslücken in PHP zu finden

Am 21. Oktober hat das PHP-Team die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Sie schließen zwei kritische Sicherheitslücken, über die sich ohne Anmeldung Code aus der Ferne ausführen lässt: CVE-2026-109618 und CVE-2026-109619. Am selben Tag beschrieb Wiz Research sie als PHP2Shell und machte öffentlich, dass die Modelle Gemini 4 Argon und GPT-5.6 Sol beim Finden der Lücken und beim Schreiben des Exploits geholfen haben.

Was ist die PHP2Shell-Sicherheitslücke?

PHP2Shell sind zwei Lücken in der PHP-Engine selbst, nicht in einer bestimmten Anwendung. Beide sind mit CVSS 9.2 bewertet. Laut Mitteilung auf php.net:

1. CVE-2026-109618 betrifft die Behandlung von Speichermangel (OOM). Der Fehler kann PHP abbrechen, während interne Request-Daten nur teilweise initialisiert sind, und das Aufräumen nach dem Request behandelt sie danach so, als wären sie gültig.
2. CVE-2026-109619 ist ein sogenannter „veralteter globaler Zustand“: Interner Request-Zustand kann die Freigabe des Speichers überleben, und der nächste Request, den derselbe Prozess bearbeitet, kann ihn verwenden.

Gefährdet sind alle PHP-Installationen, die Web-Traffic bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am schlimmsten trifft es mod_php, denn dort wurde ein Exploit gezeigt, bei dem ein Request ohne Anmeldung den Angriff auslöst, bevor überhaupt Anwendungscode läuft.

Laut Wiz steckte der verwundbare Code seit über einem Jahrzehnt in PHP, betroffen sind Versionen bis zurück zu PHP 5.4. Die Forscher haben Remote Code Execution auf den aktuellen Docker-Images von WordPress, Drupal und Joomla demonstriert.

Welche Rolle spielte KI bei der Entdeckung von PHP2Shell?

Wiz schreibt, dass es während der gesamten Untersuchung vor allem sein eigenes Werkzeug Wiz Atlas sowie die Modelle Gemini 4 Argon und GPT-5.6 Sol eingesetzt hat. Gemini 4 Argon half beim Finden der Lücke, beim Schreiben des Exploits, bei der Angriffserkennung und beim Prüfen des Patches. Die Zeitleiste aus dem Wiz-Beitrag:

1. 19. August 2026: Wiz findet die erste Lücke.
2. 20. August: Remote Code Execution auf Drupal bestätigt.
3. 21. August: dasselbe auf WordPress.

Vom gefundenen Fehler bis zum funktionierenden Angriff auf WordPress vergingen also zwei Tage. Wiz erklärt, dass die Lücken schon lange existierten und der Nachweis der Ausnutzbarkeit eine sehr komplexe Kette von Schritten erforderte, die KI-Modelle aber „substantially reduced that barrier, turning a longstanding flaw into an exploit“. Raluca Ada Popa, die bei Google DeepMind die Sicherheit von Gemini verantwortet, kommentierte, Wiz habe gezeigt, „why frontier AI is a game-changer for cyber defense“.

Nicht nur Google war beteiligt. Laut heise war das Team Calif zuerst da, das im Rahmen der OpenAI-Initiative „Patch the Planet“ zusammen mit dem PHP Ecosystem Security Team Code auditierte. Wiz und OpenAI reproduzierten die Lücken mit Hilfe von LLMs und halfen, den Patch zu prüfen.

Warum sorgt das für so viel Aufsehen?

Erstens die Reichweite. WordPress, Drupal und Joomla laufen auf PHP, und die Lücke greift, bevor Anwendungscode ausgeführt wird. Die Patch-Ankündigung auf der Liste php.announce sammelte auf Hacker News über 1300 Punkte, noch bevor Details bekannt waren.

Zweitens das Leck. Laut heise sollte die Veröffentlichung am 22. Oktober erfolgen, wurde aber um einen Tag vorgezogen, weil Informationen durchgesickert waren. SecurityWeek berichtet, dass watchTowr CVE-2026-109618 schon vor den Patches nachgebaut hat, und Sansec rechnet mit Massenangriffen „within 15 minutes of the patch release“. Bisher haben watchTowr und Huntress keine Ausnutzung in echten Angriffen beobachtet.

Drittens die Richtung. Wie bei Claude Mythos bei der Bank of America finden KI-Modelle schwere Fehler schneller, als Menschen sie patchen können. Nur haben dieselben Werkzeuge auch Angreifer, wie der KI-Hackerangriff über die Plattform Cairn gezeigt hat.

Was tun, wenn wir PHP einsetzen?

1. PHP aktualisieren auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Laut php.net und Wiz ist das der einzige vollständige Schutz.
2. Die älteren Zweige 7.4, 8.0 und 8.1 sollen laut heise Backports bekommen, und Linux-Distributionen wollen innerhalb weniger Stunden Pakete ausliefern.
3. Bei Docker muss man das neue Image ziehen und den Container neu starten.
4. Prüfen wir auch Geräte mit einer PHP-Weboberfläche: NAS, Router, Appliances (heise nennt unter anderem pfSense, QNAP und Synology).
5. Bis zum Update helfen WAF-Regeln von Cloudflare, Akamai oder AWS, aber das PHP-Team nennt Workarounds in der Konfiguration „a temporary crutch“.

(beim Shared Hosting den Anbieter fragen, wann er die Patches einspielt)

FAQ

Betrifft PHP2Shell WordPress?

Ja. Wiz hat Remote Code Execution auf dem aktuellen Image wordpress:latest gezeigt, ebenso auf Drupal und Joomla. Die Lücke steckt in PHP, also hilft ein PHP-Update, nicht ein Update von WordPress selbst.

Welche PHP-Versionen sind sicher?

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 vom 21. Oktober 2026 sowie neuere. Ältere Versionen sollte man als verwundbar betrachten.

Werden die Lücken schon ausgenutzt?

Laut SecurityWeek haben watchTowr und Huntress keine Angriffe in freier Wildbahn gesehen. Die Details sind aber vor der Veröffentlichung durchgesickert, und Sansec erwartet Massenangriffe direkt nach dem Erscheinen der Patches.

Wer hat PHP2Shell gefunden?

Laut heise war das Team Calif zuerst, im Rahmen von „Patch the Planet“ von OpenAI. Wiz Research beschrieb die Lücken unter dem Namen PHP2Shell und fand sie mit Hilfe von Gemini 4 Argon und GPT-5.6 Sol.