PHP2Shell: Wenn zwischen Patch und Exploit nur Minuten liegen.

CVE-2026-109618: Läuft der Speicher voll, bricht PHP per Bailout ab. Interne Request-Daten sind in dem Moment nur teilweise initialisiert. Beim Aufräumen arbeitet die Engine trotzdem mit diesem Zustand weiter. Unter mod_php greift der Exploit, bevor auch nur eine Zeile Anwendungscode läuft. 

CVE-2026-109619: Ein Use-after-free über Request-Grenzen hinweg. Nach einem fatalen Fehler oder OOM zeigt globaler Zustand weiter auf freigegebenen Speicher. Ein späterer Request im selben Worker nutzt ihn. Laut Advisory ist Session Upload Progress der wichtigste Consumer, und der ist standardmäßig aktiv. Die RCE ist gegen mod_php und FPM bestätigt. 

Bewertung: CVSS 4.0 mit jeweils 9,2. Angreifer brauchen weder Login noch User-Interaktion. Betroffen sind mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. 

Fixes: Offiziell hat PHP nur Patches für 8.2 aufwärts veröffentlicht, nämlich 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für ältere Versionen gibt es Backports nur über Extended-Support-Anbieter wie Zend. 

 Mitigation: Laut Advisory ist nur das Update eine vollständige Lösung. Bis dahin lassen sich einzelne Angriffswege eingrenzen. Gegen CVE-2026-109618 hilft unter anderem memory_limit=-1, am besten per php_admin_value, damit Anwendungen es nicht überschreiben, dazu ein niedriges post_max_size. Gegen CVE-2026-109619 hilft unter anderem session.upload_progress.enabled=0 mit anschließendem Worker-Neustart. Die vollständige Liste der empfohlenen Maßnahmen findest du im Advisory. Alle zusammen senken das Risiko, machen eine Installation aber nicht sicher. 

Alle Zeiten in MESZ. 

• 24.08.: Die Lücken gehen an das PHP-Security-Team. 
• 20.10.: PHP kündigt das Release für den 21.10. um 16:00 Uhr an, ohne Details und ohne betroffene Versionen. Am Abend leaken Details und ein PoC-Video. 
• 21.10., 04:13 Uhr: Gina Peter Banyard aus dem PHP Core Team stellt klar: „the only mitigation is patching / upgrading PHP“. 
• 21.10., 05:02 Uhr: Cloudflare aktiviert WAF-Regeln gegen erste Angriffsversuche. 
• 21.10., 16:00 Uhr: PHP veröffentlicht Patches und Advisories. 
• 21.10., ab 16:45 Uhr: Cloudflare zählt Zehntausende Angriffsversuche, 2 Stunden später Hunderttausende. 
• 21.10., Im Laufe des Tages: Bundesbehörden, Landesportale, Unikliniken, Hochschulen und mehrere Hoster gehen vorsorglich offline. 
• 22.10., morgens: Cloudflare meldet Millionen Angriffsversuche. 
• 23.10.: Die meisten Seiten sind wieder online. Ein erfolgreicher Einbruch ist nicht bestätigt. 

Im Hosting-Markt gab es 2 Strategien. Ein Teil der Anbieter hat Kundenwebsites komplett vom Netz genommen. Der andere Teil hat im laufenden Betrieb gepatcht.

Am 21.10. um 13:33 Uhr haben wir die Mitigation auf der gesamten Plattform ausgerollt. Weil sie die Lücken nicht schließt, haben wir um 16:17 Uhr alle PHP-Projekte vom Netz genommen. 2 Minuten später meldete watchTowr die ersten aktiven Angriffe. 

Den Engpass bildeten die alten Versionen. Upstream gab es Fixes nur ab 7.4, bei uns hosten aber auch Kunden, die auf ältere Versionen angewiesen sind. Die Backports haben wir implementiert, insgesamt 29.033 Zeilen Code. Wir haben in Wellen ausgerollt, und jedes Projekt ging erst gepatcht wieder online. Am 22.10. um 00:28 Uhr waren alle Versionen ab 5.6 durch. Die Patches für 5.3 bis 5.5 folgen in den nächsten Tagen. 

Für beide CVEs haben wir zunächst verifiziert, dass die Lücken auch in unserer Umgebung bestanden. Nach dem Patchen haben wir auf demselben Weg geprüft, ob sie geschlossen sind. Zusätzlich haben wir alle Projekte darauf gescannt, ob die Lücken bereits ausgenutzt wurden. Ergebnis: keine Findings.  

Der Preis dafür waren rund 8 Stunden Downtime. Wir wissen, dass das für dich und deine Kunden ärgerlich war. Wir haben uns trotzdem bewusst so entschieden: Ein System mit bekannter, aktiv angegriffener Lücke wollten wir nicht online lassen. Danke an alle, die in dieser Nacht Geduld mit uns hatten. 

Die Exploit-Ökonomie hat sich verschoben. Das Grundproblem ist PHPs Umgang mit vollem Speicher. Es ist seit 2024 bekannt und galt als praktisch nicht ausnutzbar. Calif, Wiz und OpenAI haben mit KI-Modellen daraus eine funktionierende Exploit-Kette gebaut. Laut Wiz hat ein einzelner Forscher dafür 7 Tage gebraucht. Früher hätte ein Team Monate daran gearbeitet. „Schwer auszunutzen“ ist damit kein Grund mehr, einen Fix liegen zu lassen. 

Das Patch-Fenster ist weg. Zwischen Release und ersten Angriffen lagen Minuten, nicht Tage. Der Patch selbst wird zur Anleitung für den Exploit. Betreibst du selbst Infrastruktur, brauchst du Prozesse, die in Stunden reagieren. Dazu gehören Builds für alle Versionen, die bei dir im Einsatz sind. 

EOL-Runtimes werden zur Hypothek. Wie viele Server noch auf PHP-Versionen ohne offiziellen Support laufen, lässt sich kaum seriös beziffern. Scans erfassen nur Systeme, die ihre Version preisgeben. Klar ist: Es sind viele, und im Ernstfall braucht jede davon einen eigenen Backport, oder sie bleibt offen.  

Open Source Security braucht Ressourcen. Die PHP Foundation nennt die verschleppte Behebung selbst „a structural failure“. Sie hat ein eigenes Security-Team aufgebaut und entscheidet künftig per Mehrheit statt Konsens. Außerdem ruft sie Hoster und Unternehmen auf, diese Arbeit zu finanzieren. 

Unsere Backports haben dieses Mal funktioniert. Trotzdem gilt: Versionen mit offiziellem Support bekommen auf jeden Fall offizielle Fixes. Bei allen anderen muss man hoffen, dass ein Backport möglich ist, und er kommt über einen Umweg. Für ältere Versionen setzen wir auf Extended Support. Das gibt euch mehr Zeit für den Umstieg, kostet im Ernstfall aber Zeit, bis die Fixes bereitstehen. Und genau diese Zeit zählt, wenn Angriffe nach Minuten starten.  

Prüf deshalb, welche PHP-Versionen in deinen Projekten laufen. Plane für alles ohne offiziellen Support ein Update ein. Bei PHP2Shell bekamen die Versionen 8.2 bis 8.5 reguläre Fixes. Für dich als Agentur ist das auch ein guter Anlass, mit deinen Kunden über Wartung zu sprechen. Ein Update kostet Aufwand. Eine offene Lücke kostet im Zweifel deutlich mehr. Brauchst du Hilfe bei der Umstellung, meld dich bei unserem Support. 

• Die Backport Pipeline aus dieser Nacht bleibt. Beim nächsten Mal starten wir nicht bei null. 
• Mitigations sollen noch schneller auf der gesamten Plattform greifen. 
• Wir prüfen, ob wir Maßnahmen nach SAPI und Exposition abstufen. So müssen nicht jedes Mal alle Projekte gleichzeitig offline. 
• Den Fortschritt beim Rollout zeigen wir künftig live auf unserer Status-Seite. 

PHP2Shell wird nicht der letzte Vorfall dieser Art sein. Die kritischen Node.js-Lücken, die fast zeitgleich kamen, waren schon der nächste. Wir bleiben dran und halten dich auf dem Laufenden.