PHP2Shell: Das Web lief auf Ehrenamt, bis es stillstand – Grams IT

Am Mittwoch um 16 Uhr deutscher Zeit war es dann so weit. Nach einem Vormittag, an dem Landesregierungen, Städte, Kliniken und Bundesministerien ihre Webseiten vom Netz nahmen, veröffentlichte das PHP-Projekt die Updates gegen zwei Lücken, die inzwischen jeder nur noch PHP2Shell nennt. CVE-2026-109618 und CVE-2026-109619, beide mit CVSS 9.2, beide ohne Anmeldung aus der Ferne ausnutzbar, beide im Kern der Sprache, auf der nach eigener Aussage der PHP Foundation ein großer Teil des Webs läuft.

Wer gestern Server betreut hat, kennt den Tag: Warten auf 16 Uhr, Updates einspielen, Worker neu starten, hoffen. Dieser Artikel ist der Rückblick darauf. Was passiert ist, warum es passiert ist, und warum die Geschichte dahinter deutlich peinlicher ist als die Lücke selbst.

Vorab eine Korrektur, weil sie inzwischen in mehreren Versionen kursiert: Die Lücke existiert nicht „seit 2014″ und ist auch nicht seit 2014 bekannt. Sie steckt nach Angaben des BSI mindestens seit PHP 5 im Code, also seit 2004. Bekannt war sie der PHP-Entwicklung seit 2024. Das ist weniger lang, aber nicht weniger schlimm, denn zwei Jahre reichen völlig aus, um einen Fix nicht zu bauen.

Was PHP2Shell technisch ist

Die beiden Lücken sitzen dort, wo nahezu jede PHP-Anfrage durchläuft: Speicherverwaltung und Fehlerbehandlung. Die erste, CVE-2026-109618, nennt das Projekt im Security Advisory auf php.net „RCE via OOM corruption”. Erreicht eine Anfrage das memory_limit im falschen Moment, bleiben halb initialisierte interne Daten liegen, die PHP später für gültig hält. Auf Apache mit mod_php reicht dafür eine einzige Anfrage, bevor überhaupt Anwendungscode läuft.

Die zweite, CVE-2026-109619, heißt „RCE via stale global state”. Ein fataler Fehler zum falschen Zeitpunkt hinterlässt internen Zustand, der auf Speicher einer vorherigen Anfrage zeigt. Die nächste Anfrage im selben Worker nutzt diesen freigegebenen Speicher. Das Projekt schreibt dazu den Satz, den ich mir eingerahmt habe: Es gibt keine vollständigen Mitigationen, Updaten ist die einzige sichere Wahl.

Gefixt sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 7.4, 8.0 und 8.1 gibt es minimale Quellcode-Backports in eigenen Git-Branches, keine Releases. Wer noch darauf läuft, soll beim Distributor oder LTS-Anbieter nachfragen. Und PHP 8.2 läuft am 31. Dezember 2026 aus, der Hinweis steht gleich mit im Release-Text.

Der Tag, an dem Deutschland die Webseiten abschaltete

Das BSI hat am 21. Oktober die Cybersicherheitswarnung BITS-H 2026-297981-1032 veröffentlicht, Stufe 3 von 4, Orange. Darin stand ein Satz, der in der deutschen Behördenlandschaft offenbar als Anweisung gelesen wurde: Wer nicht kurzfristig patchen könne, solle eine vorübergehende Trennung des Webservers vom Internet erwägen.

Erwogen wurde ausgiebig. Laut einer dpa-Zusammenstellung bei teltarif nahm die Landesregierung Baden-Württemberg die Seiten der Ministerien und Regierungspräsidien vom Netz. In Bayern waren Ministerien und Polizei nicht erreichbar, dazu das Landratsamt Rhön-Grabfeld und das Klinikum Nürnberg. Die hessische Staatskanzlei teilte mit, dass hessen.de und die Webseiten der Ministerien und nachgeordneten Bereiche im Hessen-Web vorübergehend nicht erreichbar seien. Thüringen setzte seine Onlineangebote aus. Mainz deaktivierte mainz.de, Dresden kündigte an, bis voraussichtlich Donnerstag offline zu bleiben. Und am frühen Mittwochnachmittag gingen nach dpa-Angaben mehrere beim ITZ-Bund gehostete Seiten von Bundesministerien vom Netz. In der Schweiz zog laut SRF der Kanton Basel-Stadt den Stecker.

Man muss sich das kurz auf der Zunge zergehen lassen: Der offizielle Rat der nationalen Cybersicherheitsbehörde an die öffentliche Hand lautete sinngemäß „macht das Internet aus, bis es sicher ist”. Und das Beste daran ist, dass der Rat vermutlich richtig war. Digitalminister Wildberger nannte die Abschaltung der Bundes-Webseiten gegenüber der Bild eine richtige Entscheidung und sah keine Hinweise auf eine erfolgreiche Kompromittierung. Dann fügte er hinzu, der Fall zeige, dass wir am Beginn eines neuen Zeitalters der Cybersicherheit stünden, in dem KI-Tools Schwachstellen schneller aufspürten als je zuvor. Das stimmt sogar. Nur hat die KI die Lücke nicht gefunden. Ein Mensch hat sie 2024 gefunden. Die KI hat nur zwei Jahre später bewiesen, dass sie ausnutzbar ist.

Was die PHP Foundation einräumt

Die interessanteste Quelle des Tages war nicht das BSI, sondern das Statement der PHP Foundation, veröffentlicht wenige Stunden nach dem Patch. Es ist selten, dass ein Projekt dieser Größe so offen aufschreibt, was schiefgelaufen ist. Die Zeitleiste in Kurzform:

2024 ließ die Foundation PHP zum ersten Mal seit Jahren extern auditieren. Bezahlt hat das die deutsche Sovereign Tech Agency, organisiert hat es OSTIF, durchgeführt Quarkslab. Beim Beheben eines der Audit-Funde stieß ein von der Foundation bezahlter Core-Entwickler auf die ersten Anzeichen des OOM-Problems hinter CVE-2026-109618. Ein Exploit wurde damals theoretisch durchgespielt, aber niemand fand einen konkreten Weg, und andere Probleme mit klarerer Wirkung hatten Vorrang.

Dann kam der Teil, den jeder kennt, der je in einem Gremium gesessen hat. Das Security-Team entwickelte mehrere konkurrierende Fixes. Einer brach die Abwärtskompatibilität, einer brachte neues DoS-Potenzial mit, einer hätte Änderungen in vielen Third-Party-Extensions erfordert. Das Team arbeitete im Konsens, fürchtete die Folgen der falschen Wahl, und die wenigen Leute mit tiefem Engine-Wissen hatten noch zehn andere Aufgaben. Die Arbeit am Fix, so die Foundation wörtlich, stockte und startete über Monate immer wieder neu. Ihr eigenes Urteil: ein strukturelles Versagen, verursacht durch den Entscheidungsprozess des Security-Teams und seinen Mangel an Ressourcen.

Ich will das nicht kleinreden, aber ich will auch kurz würdigen, was hier steht. Die Lücke, wegen der gestern Landesregierungen offline gingen, lag zwei Jahre in einer Schublade, weil ein Gremium sich nicht einigen konnte, welcher von drei unangenehmen Fixes der am wenigsten unangenehme ist. Das ist nicht Bosheit, das ist Sitzungskultur. Und wer in der öffentlichen Verwaltung je versucht hat, drei Fachbereiche auf eine gemeinsame Lösung zu bringen, weiß, dass das in zwei Jahren eine ambitionierte Zeitvorgabe gewesen wäre.

Wie aus einer Schublade ein Notfall wurde

Ab dem Sommer 2026 ging es dann schnell. Im Rahmen von OpenAIs Programm „Patch the Planet” begann die Sicherheitsfirma Calif am 30. Juli einen Audit. Am 11. August meldete der Calif-Researcher Ryan A eine Remote Code Execution mit genau der Ursache, die die Foundation 2024 selbst gefunden hatte. OpenAI meldete am selben Tag unabhängig dasselbe. Wiz legte am 24. August nach, OpenAI am 18. September. Erst jetzt, schreibt die Foundation, war die volle Tragweite klar, und erst jetzt wurde der Fix zur obersten Priorität.

Auch die Zahlen dahinter sind lesenswert: Seit dem 1. Juli hat das Security-Team 15 CVEs veröffentlicht und über 100 Meldungen abgearbeitet, die ungültig, doppelt oder nicht reproduzierbar waren. KI-gestützte Forschung produziert Berichte in einer Menge, die ein Team dieser Größe nicht mehr weglächeln kann. Werkzeuge finden die Bugs. Was Werkzeuge nicht können, so die Foundation, ist entscheiden, wie man eine jahrzehntealte Design-Entscheidung in der Engine repariert, ohne das Ökosystem zu zerlegen. Dafür braucht es Leute, die den ganzen Code kennen, und davon gibt es zu wenige.

Die Pointe folgt am Ende des Statements. Die Foundation bittet Unternehmen, Hoster und ausdrücklich Regierungen um Geld. Die Sovereign Tech Agency habe mit dem Audit 2024 gezeigt, was öffentliche Förderung bewirken kann. Das ist korrekt. Der Audit hat die Lücke gefunden. Danach war das Geld alle, und der Fix lag zwei Jahre.

Coordinated Disclosure, unkoordiniert

Eigentlich sollte das Ganze am Donnerstag, 22. Oktober, veröffentlicht werden. Dann lief es so, wie Coordinated Disclosure in der Praxis meistens läuft.

Am Dienstag, 20. Oktober, gegen 15 Uhr UTC tauchten die beiden CVE-IDs in Foren und sozialen Medien auf, mit falscher Uhrzeit und einem falschen CVSS-Score von 10.0. Das PHP-Projekt zog seine Vorankündigung auf 19:30 UTC vor und den Release auf den Mittwoch, weil die Distributoren noch beim Paketieren waren. Gegen 20 Uhr UTC veröffentlichte Calif, eine der meldenden Firmen, versehentlich ein Video, das ihren Proof-of-Concept gegen echte Ziele zeigte. Das Video wurde gelöscht, Kopien kursierten. Die Mitigation-Hinweise, die das Projekt gegen 23 Uhr UTC an einige Betreiber kritischer Infrastruktur gab, sind nach Einschätzung der Foundation möglicherweise ebenfalls durchgesickert.

Und am Mittwoch um 07:41 UTC, mehr als sechs Stunden vor dem Release, veröffentlichte Chainguard fertige Container-Images mit dem Fix. Chainguard hatte den Patch wie alle Distributoren vorab bekommen. Jeder Angreifer konnte den Fix nun im Binärformat studieren, während der Rest der Welt auf 16 Uhr wartete. Die Foundation nennt das einen einseitigen Bruch des Embargos, der Wochen Arbeit vieler Beteiligter missachtet habe. Ich hätte es weniger höflich formuliert.

Was das in Zahlen bedeutet, hat Cloudflare-Chef Matthew Prince auf X zusammengefasst: In den zehn Stunden vor der Veröffentlichung sah sein Netz tausende Angriffsversuche. In den 45 Minuten nach der Veröffentlichung waren es zehntausende, nach zwei Stunden hunderttausende, am Donnerstagmorgen Millionen. Amazon berichtet laut SecurityWeek sogar von einem Exploit-Versuch gegen einen Honeypot am 17. Oktober, vier Tage vor dem Release, und weiß nach eigener Angabe nicht, woher der Angreifer von der Lücke wusste.

Fairerweise gehört dazu: Ein bestätigter erfolgreicher Einbruch war bis Donnerstag nirgends dokumentiert. Die US-Behörde CISA hatte laut CyberScoop zum Zeitpunkt ihrer Warnung keine Ausnutzung beobachtet, Huntress auf den Systemen seiner Partner auch nicht. BSI-Vizepräsident Thomas Caspers sagte laut The Next Web gegenüber Politico, man sehe Angriffe, aber keinen erfolgreichen. Und watchTowr beobachtete Massenausnutzung, stellte aber laut SecurityWeek fest, dass keiner der kursierenden Proof-of-Concepts tatsächlich Code ausführt. Millionen Versuche sind nicht Millionen Einbrüche. Das ist der Teil, den die Schlagzeilen gern weglassen.

Die Gegenposition, und warum sie trotzdem nicht reicht

Man kann das alles auch anders lesen, und die Foundation tut es in ihrem Statement selbst. Der Fix ist für vier Branches gleichzeitig erschienen, mit Backports für drei weitere, die Distributoren hatten ihn vorab, und die Leute haben nach eigener Angabe Wochenenden und Nächte durchgearbeitet. Das ist, gemessen an dem, was ein Projekt mit einer Handvoll bezahlter Entwickler leisten kann, eine beachtliche Leistung. Dass der Zeitplan überhaupt bis zwei Tage vor Release gehalten hat, ist bei so vielen Beteiligten eher die Ausnahme. Und die Abwägung zwischen Kompatibilität, Performance und Sicherheit ist bei einer Engine, auf der Millionen Anwendungen laufen, wirklich keine, die man in einer Stunde trifft.

Trotzdem bleibt die Frage, die niemand gern stellt: Warum braucht es einen externen Audit, finanziert von einer deutschen Bundesagentur, damit ein Projekt dieser Reichweite überhaupt in seinen eigenen Speichermanager schaut? Und warum ist nach diesem Audit niemand da, der den Fund zu Ende bringt? Die Antwort steht im Statement. Es gibt zu wenige Leute, und die wenigen werden von zu wenigen bezahlt. Jeder Onlineshop, jede Verwaltung, jede Bank, die auf PHP läuft, hat gestern von der Arbeit einer Handvoll Menschen gelebt, von denen die meisten ihre Namen nie gehört haben.

Und wenn die Foundation von Governments spricht, meint sie auch uns. Die Länder, die gestern ihre Portale abgeschaltet haben, betreiben sie auf PHP. Die Sovereign Tech Agency hat einmal einen Audit bezahlt. Das war gut. Ein Audit ist aber ein Foto, keine Wartung.

Was Sie jetzt tun sollten

Das ist meine Lesart der Hinweise des PHP-Projekts, keine Garantie. Erstens Version prüfen, und zwar nicht im Dashboard, sondern mit php -v auf jedem Host und in jedem Container. Zweitens, wenn die Version nicht 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder ein entsprechendes Distributionspaket ist, updaten und jeden Worker neu starten. Drittens, wer noch auf 8.1 oder älter läuft, hat jetzt keinen Patch, sondern eine Migration vor sich, und die Backport-Branches sind eine Brücke, kein Zuhause.

Wer gar nicht updaten kann, findet im Advisory Maßnahmen, die einzelne Angriffspfade schließen: memory_limit=-1 per php_admin_value, ein niedriges post_max_size, session.upload_progress.enabled=0 in der php.ini oder FPM-Pool-Konfiguration, nicht per ini_set(). Das Projekt sagt ausdrücklich, dass diese Maßnahmen eine Installation nicht sicher machen. Sie machen sie weniger unsicher. Das ist ein Unterschied, den man kennen sollte, bevor man die Seite wieder einschaltet.

Fazit

PHP2Shell war kein Zero-Day im klassischen Sinn. Es war eine Lücke, die 2024 gefunden, zwei Jahre in einem Konsensverfahren geparkt und 2026 von KI-gestützten Researchern wiederentdeckt wurde, bevor ein Leak, ein versehentliches Video und ein Distributor, der nicht warten wollte, aus einem geordneten Release einen Mittwoch machten, an dem Landesregierungen ihre Webseiten abschalteten. Die Entwickler haben am Ende geliefert. Die Struktur um sie herum hat versagt, und sie sagen es selbst.

Wenn Sie in einer Organisation arbeiten, die auf PHP läuft, und das sind fast alle, dann lesen Sie das Statement der Foundation bis zum letzten Absatz. Dort steht ein Link zum Sponsoring. Der Patch gestern war kostenlos. Der nächste ist es vielleicht nicht, wenn niemand bezahlt.

Quellen: