KI entdeckte einen 20 Jahre alten PHP-Fehler – er führt Code auf Ihrem Server aus. Jetzt patchen.

Am 21. Oktober veröffentlichte das PHP-Projekt gleichzeitig vier Versionen – 8.5.12, 8.4.27, 8.3.36 und 8.2.35 –, um zwei kritische Sicherheitslücken mit einem CVSS-Score von jeweils 9,2 zu beheben: CVE-2026-109618 und CVE-2026-109619. Zusammen werden sie als php2shell bezeichnet. Jede der beiden Lücken ermöglicht es einem nicht authentifizierten Angreifer, Code auf einem Server auszuführen, der nichts weiter tut als PHP bereitzustellen. Es ist kein Anwendungsfehler erforderlich. Eine einfache „Hello World"-Seite auf einem betroffenen Build reicht aus.

Beide Schwachstellen befinden sich in Bereichen von PHP, die nahezu jede Anfrage berührt: Speicherverwaltung und Fehlerbehandlung. CVE-2026-109618 beschädigt den Speicher bei der Bereinigung, nachdem PHP während einer Anfrage keinen Speicher mehr hat. CVE-2026-109619 ist ein Use-after-Free, bei dem der interne Zustand einer Anfrage in die nächste Anfrage desselben Workers übergeht. Wiz Research entdeckte sie mithilfe von KI-Agenten, meldete sie im August vertraulich, und die Korrektur wurde am 21. Oktober in einer mit Distributionen und Anbietern koordinierten Version veröffentlicht. Wiz zufolge sind alle PHP-Versionen ab 5.4 betroffen – also etwa das letzte Jahrzehnt der Sprache. Da PHP einen Großteil des Webs antreibt, ist die Anzahl betroffener Server enorm.

Wer wirklich betroffen ist

Das PHP-Team stuft Apache mit mod_php als das höchste Risiko ein. Eine einzige nicht authentifizierte Anfrage kann den Exploit auslösen, bevor Ihr eigener Code überhaupt läuft – sodass keine Ihrer eigenen Abwehrmaßnahmen, keine Auth-Middleware, keine Eingabevalidierung, keine In-App-Prüfungen je zum Zug kommen. Vollständige Remotecodeausführung wurde auf mod_php mit Standardeinstellungen gegen frische WordPress-, Drupal- und Joomla-Container demonstriert.

Auch PHP-FPM ist nicht sicher. RCE über den Stale-State-Fehler wurde auf FPM validiert, obwohl dieser Pfad eine geeignete Operation in der laufenden Anwendung erfordert. php-cgi, FrankenPHP und LiteSpeed sind ebenfalls betroffen. Wenn es PHP über HTTP bereitstellt, behandeln Sie es als verwundbar, bis Sie es gepatcht und neu gestartet haben.

Ein Hinweis für mobile Teams, weil das Risiko leicht übersehen wird: In unseren nativen iOS- und Android-Projekten ist die App selbst sauber, kommuniziert aber mit einer API – und diese API ist sehr oft PHP. Ein ungepatchtes Backend gefährdet Ihre Nutzer, auch wenn auf dem Gerät selbst nichts falsch ist. Prüfen Sie den Server hinter der App, nicht nur die App.

Was wir zuerst tun würden

Aus unserer PHP- und Docker-Arbeit sehen wir unter Druck immer wieder denselben Fehler: das Falsche zu patchen. Zwei Schritte sind wichtiger als alles andere.

1. Finden Sie jede PHP-Instanz, die Sie betreiben – nicht nur die offensichtliche. Sie versteckt sich in cPanel- und Plesk-Stacks, Vendor-Appliances, alten Client-Seiten, die seit zwei Jahren niemand angefasst hat, CI-Images und Basis-Containern. Die Empfehlung der CISA lautet: zunächst inventarisieren, denn PHP ist oft tief in anderer Software verborgen, und man kann nicht patchen, was man nicht gefunden hat.
2. Patchen, dann neu starten, dann die Version des laufenden Prozesses überprüfen. Ein neues Paket auf dem Datenträger bewirkt nichts, bis Sie die laufenden Worker ersetzen. Wir haben Teams beobachtet, die „gepatcht" haben und tagelang angreifbar blieben, weil PHP-FPM nie tatsächlich neu gestartet wurde.

Container verschlimmern diese Falle. Ein Upgrade in einem laufenden Container durchzuführen ist keine Lösung, weil Ihr nächstes Deployment aus dem alten Image den verwundbaren Build direkt zurückbringt. Erstellen Sie das Image auf Basis eines gepatchten Basis-Images neu, pushen Sie es und rollen Sie die Worker aus. Dann prüfen Sie den Server und bestätigen Sie, dass die erwartete Version antwortet.

Wenn Sie heute wirklich nicht patchen können

Das PHP-Team ist deutlich: Nur ein Update ist eine vollständige Lösung, und die Übergangskonfigurationen schränken lediglich bestimmte Angriffspfade ein. Die empfehlenswerten Einstellungen sind memory_limit=-1, erzwungen dort, wo die App es nicht überschreiben kann – über php_admin_value in Ihrem FPM-Pool oder der Apache-Konfiguration –, dann session.upload_progress.enabled=0 und ein konservatives post_max_size. Wenn Sie Cloudflare nutzen, ist die verwaltete WAF-Regel für diese CVEs bereits aktiv. Mit einer Edge-Regel Zeit zu gewinnen, während Worker gepatcht werden, ist genau das, was wir bei der Cloudflare-Konfiguration für Kunden während eines Vorfalls einrichten. Ein Vorbehalt: Diese Regel greift auf den Standard-Feldnamen des Upload-Fortschritts zurück. Wenn Sie session.upload_progress.name umbenannt haben, schützt sie Sie nicht.

Was Sie mehr beunruhigen sollte als dieser eine Fehler

Was mich an php2shell wirklich beschäftigt: Diese Fehler lagen etwa zwanzig Jahre im Code. Niemand hat sie ausgenutzt, weil die Umwandlung einer Speicherbeschädigungskette in einen zuverlässigen Exploit für jede PHP-Version, jeden Extension-Satz und jedes Heap-Layout langsame Spezialarbeit war – die Art, die Monate dauert. Wiz nutzte modernste KI-Modelle für diese Anpassung, und es dauerte stattdessen nur ein paar Wochen.

Bei unseren Pentesting-Einsätzen für Gaming-Studios war das Schwierige selten, einen verdächtigen Codepfad zu erkennen. Es war, einen echten, wiederholbaren Exploit zu beweisen, bevor jemand bereit war, dafür zu zahlen. Diese Ökonomie hat sich verändert. Angreifer profitieren von derselben Beschleunigung, was bedeutet, dass die Zeitspanne zwischen der Veröffentlichung eines Patches und massivem Scanning immer kleiner wird. Cloudflare meldete Probingversuche rund um den Zeitpunkt der Veröffentlichung, und ein Proof of Concept kursiert bereits.

Das ehrliche Fazit ist unbequem: Ihr Patch-Rhythmus ist jetzt Ihre Sicherheitsstrategie. Wenn Sie eine kritische Laufzeitumgebung in Ihrer gesamten Infrastruktur nicht innerhalb eines Tages finden und aktualisieren können, ist das die eigentliche Lücke – und php2shell wird nicht das Letzte sein, das sie auf die Probe stellt.

Wenn das Thema, PHP über Staging, Produktion und eine Reihe älterer Client-Seiten hinweg gepatcht, neu gestartet und verifiziert zu halten, vertraut klingt, sprechen wir.