KI findet PHP-Lücke, BSI rät zum Abschalten

Seit Mittwochnachmittag, dem 21.10.2026, gibt es PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Die Versionen schließen zwei Lücken im PHP-Kern, CVE-2026-109618 und CVE-2026-109619, beide mit CVSS 9,2. Angreifer können damit ohne Anmeldung Code auf dem Webserver ausführen. Betroffen ist laut BSI jede PHP-Installation, die Webanfragen verarbeitet, zurück bis mindestens PHP 5: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten stuft das PHP-Sicherheitsteam das Risiko bei mod_php ein, dort reicht eine Anfrage, und der Angriff läuft, bevor überhaupt Anwendungscode ausgeführt wird.

Das BSI hat die Warnstufe 3 (Orange) ausgerufen. Wer nicht sofort patchen kann, soll erwägen, den Server vorübergehend vom Internet zu trennen, weil die bekannten Workarounds keinen vollständigen Schutz bieten. Viele haben das getan. Laut heise waren unter anderem die Charité komplett offline, berlin.de teilweise, die Internetwache der Berliner Polizei war nicht erreichbar, dazu Behörden- und Polizeiseiten in Bayern und Niedersachsen. Auch in Dänemark, Finnland, Frankreich und den Niederlanden gingen Regierungsseiten vom Netz.

Zwei Modelle, eine Lücke

Gefunden haben die Lücken zwei Teams unabhängig voneinander, beide mit KI. Die Sicherheitsfirma Calif arbeitete mit GPT-5.6 Sol im Rahmen von OpenAIs Initiative "Patch the Planet", wie OpenAI schreibt. Wiz entdeckte dieselben Fehler am 19.08.2026 mit Hilfe von Gemini 4 Argon und meldete sie am 24.08. an PHP. Wiz zufolge war das Modell bei der Suche wie bei der Exploit-Entwicklung beteiligt: "Frontier models were critical to making this process practical."

Einfach auszunutzen sind die Lücken trotzdem nicht. Laut heise klappt kein Exploit beim ersten oder zweiten Versuch, zuverlässig wird es nach einigen tausend bis zehntausenden Anfragen. Für automatisierte Angriffe ist das kein Hindernis. Cloudflare sah laut heise Millionen Exploit-Versuche, die rund zehn Stunden vor der Veröffentlichung der Details begannen.

Das Embargo hielt nicht

Geplant war die Veröffentlichung für den 22.10. Daraus wurde nichts. Laut PHP Foundation tauchten die CVE-Nummern am 20.10. gegen 17 Uhr deutscher Zeit in Foren und sozialen Medien auf, mit falschem Termin und einem falschen CVSS-Wert von 10,0. Technische Details seien nicht dabei gewesen. Das Projekt zog den Release auf den 21.10., 16 Uhr vor. Danach veröffentlichte Calif versehentlich ein Video mit einem Proof of Concept, und am Morgen des 21.10. brach Chainguard das Embargo, indem es schon gepatchte Images herausgab.

Die PHP Foundation nutzt den Anlass für einen offenen Blick auf ihre Lage. Seit dem 01.07.2026 hat PHP 15 CVEs veröffentlicht, mehr als 100 Meldungen erwiesen sich als ungültig, doppelt oder nicht reproduzierbar. KI hilft dem Team beim Prüfen und Gruppieren solcher Meldungen, die Entscheidungen und jeden Patch macht aber ein Mensch. Die Foundation hat dafür einen "AI Security Engineer in Residence" eingestellt und bittet Firmen, Hoster und Regierungen um Geld für mehr Leute mit tiefem PHP-Wissen.

OpenAI schlägt zu dem Fall ein Verfahren in fünf Schritten vor, wie Maintainer, Distributoren, Hoster und Behörden vor einer Offenlegung zusammenarbeiten sollen. Der Konzern erwartet, dass ähnliche Funde "in den kommenden Monaten stark zunehmen". Der Vorschlag kommt allerdings von einem Anbieter, dessen Modelle diese Funde liefern, und der Fall selbst zeigt, wie wenig Zeit bleibt, wenn viele Beteiligte eingeweiht sind.

Patchen, aber an der richtigen Stelle

• Patchen, und zwar die Laufzeitumgebung. Ein Update von WordPress, Drupal, TYPO3 oder Nextcloud hilft nicht, die Lücke steckt in PHP selbst. Wer PHP über die Paketverwaltung der Distribution bezieht, bekommt meist einen Backport mit anderer Versionsnummer. Das BSI rät, mit php -v und dem Advisory der Distribution abzugleichen. Debian, Ubuntu, Red Hat, Fedora und SUSE haben laut heise Pakete bereitgestellt. Für die nicht mehr gepflegten Zweige 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam Backport-Patches herausgegeben.
• Container neu bauen. Ein Docker-Image mit PHP wird nicht dadurch sicher, dass der Host gepatcht ist. Images mit aktuellem Basis-Image neu bauen und ausrollen.
• Bei Managed Hosting nachfragen. Viele Hoster patchen selbst, oft ohne dass sich die angezeigte Version ändert. Für Seiten mit Login, Shop oder Kundendaten lohnt die schriftliche Bestätigung, dass gepatcht ist.
• Versteckte PHP-Installationen suchen. PHP steckt auch in Produkten, die man nicht als PHP-Anwendung wahrnimmt: Firewalls wie pfSense und OPNsense, NAS-Systeme, Router, Raspberry-Pi-Projekte. Das niederländische NCSC sammelt betroffene Produkte in einem GitHub-Repository, auf das das BSI verweist.
• Workarounds nur zur Überbrückung. Das PHP-Team nennt unter anderem memory_limit=-1 und kleinere post_max_size-Werte, das BSI listet sie samt Details auf. Sie verkleinern die Angriffsfläche, schließen die Lücke aber nicht. WAF-Regeln von Cloudflare oder Bunny Shield blockieren bekannte Angriffswege, mehr nicht.

Nach Spuren lohnt es sich auch zu schauen. Wiz nennt als Anzeichen ungewöhnliche Multipart-Anfragen mit anschließenden Memory-Limit-Fehlern oder gehäuften HTTP-500-Antworten, auffällig große PHPSESSID-Cookies und PHP-Worker, die ohne Grund neu starten.

Patchen in Stunden statt Wochen

PHP2Shell ist der bisher deutlichste Fall für etwas, das wir seit dem Frühjahr beobachten: KI-Modelle finden Lücken in Software, die seit Jahrzehnten von vielen Leuten gelesen wird. Bei Symfony waren es im Mai 19 Funde durch Claude Mythos, jetzt trifft es den Kern einer Sprache, auf der ein großer Teil des Webs läuft. Das BSI schreibt dazu nüchtern, dass Angreifer seit dem Aufkommen KI-gestützter Exploit-Werkzeuge Patches in kurzer Zeit analysieren können.

Für Teams heißt das vor allem, dass Patchen in Stunden statt in Wochen passieren muss, und dass man dafür vorher wissen sollte, wo überall PHP läuft. Wer erst bei der nächsten Warnung anfängt, eine Liste zu machen, ist zu spät. Wie KI die Schwachstellensuche insgesamt verändert, steht in unserem Bericht zur KI-Bugjagd.