Aktuelles

PHP2Shell: Kritische PHP-Lücken, KI und der aktuelle Stand

Charité offline, Mainz offline, Bundesinnenministerium offline - und mit ihnen jede Menge andere Websites: Zwei kritische Lücken im PHP-Kern haben am Mittwoch halb Behörden-Deutschland in den Wartungsmodus geschickt. Gefunden wurden sie mit KI, ausgenutzt wurden sie offenbar auch mit KI. Und das schon, bevor es offiziell überhaupt etwas zu patchen gab. Was hinter „PHP2Shell“ steckt, wie der Stand heute ist und was Betreiber jetzt noch erledigen müssen.

Es gibt Tage, an denen man als Admin lieber Bäcker geworden wäre. Der 21. Oktober 2026 war so einer. Die Website der Landeshauptstadt Mainz: weg. Das Bundesinnenministerium: zwischenzeitlich nicht erreichbar. Die Verfassungsschutzbehörden von Bayern, Hessen und Thüringen: offline. Dazu die Berliner Charité, Universitäten, Verbraucherzentralen, Kommunen in mehreren Bundesländern. Und nicht nur hierzulande: Auch in den Niederlanden, Finnland, Frankreich, Dänemark, Österreich und der Schweiz zogen Behörden und Unternehmen vorsorglich den Stecker.

Der Grund war keine Cyberattacke, sondern die pure Angst vor einer solchen. Und die war ausnahmsweise mal nicht übertrieben.

Was ist PHP2Shell?

Hinter dem griffigen Namen, eine bewusste Anspielung auf das Log4Shell-Desaster von 2021, stecken zwei Schwachstellen im Kern von PHP: CVE-2026-109618 und CVE-2026-109619. Beide werden nach CVSS 4.0 mit 9,2 von 10 Punkten bewertet, beide betreffen die Speicherverwaltung der Laufzeitumgebung, und beide erlauben im schlimmsten Fall das, was Sicherheitsleute am wenigsten hören wollen: Remote Code Execution ohne vorherige Anmeldung.

Vereinfacht gesagt: Bei der ersten Lücke gerät PHP ins Stolpern, wenn genau im falschen Moment während des Request-Aufbaus der Speicher ausgeht. Interne Datenstrukturen bleiben dann halb initialisiert zurück, und der Aufräumcode vertraut diesem kaputten Zustand trotzdem. Bei der zweiten überleben interne Zeiger nach einem fatalen Fehler das Ende eines Requests und ein nachfolgender Request im selben Worker kann sie kapern. In beiden Fällen entsteht ein sogenanntes Use-after-free, also Zugriff auf bereits freigegebenen Speicher. Das klingt akademisch, endet in der Praxis aber mit einer Shell auf dem Server, sprich: Ich kann als Angreifer so ziemlich alles machen, worauf ich Bock habe.

Das Fiese daran: Es geht nicht um ein schlampiges WordPress-Plugin oder ein vergessenes Admin-Passwort. Es geht um die Sprache selbst. Wer PHP-Webanfragen ausliefert, war betroffen -  ganz egal, wie sauber der eigene Code ist. Und PHP läuft, je nach Zählung, unter rund zwei Dritteln bis 70 Prozent aller Websites weltweit. Palo Alto Networks zählte in einer ersten Analyse über 22 Millionen potenziell verwundbare Instanzen. Das ist eine Hausnummer.

Ein Scheunentor, das über ein Jahrzehnt offen stand

Wie lange die Lücke schon existiert, darüber gehen die Angaben leicht auseinander. Das BSI spricht davon, dass sie mindestens bis PHP 5 zurückreicht, OpenAI-Mitgründer Greg Brockman nennt 14 Jahre. Brisanter ist ein anderes Detail: Eine eingeschränkte Variante des Problems war bereits 2024 aufgefallen und galt damals als nicht weiter bedeutsam. Abgehakt, weitergemacht.

Das ist kein spezielles PHP-Versagen, sondern ein Muster, das man aus der Open-Source-Welt kennt: Ein Bug, der theoretisch existiert, aber praktisch kaum ausnutzbar scheint, wandert ganz nach unten auf die Prioritätenliste. Bei einem Projekt, das von einer vergleichsweise kleinen Foundation getragen wird und auf dem trotzdem ein Großteil des Webs aufsetzt, ist das nachvollziehbar. Gefährlich ist es trotzdem. Denn „schwer auszunutzen“ ist keine Eigenschaft eines Bugs, sondern eine Momentaufnahme der Werkzeuge, die gerade verfügbar sind.

Die Rolle der KI: Finder und Brandbeschleuniger zugleich

Und genau diese Werkzeuge haben sich geändert. Die Geschichte der Entdeckung liest sich wie ein Lehrstück über den aktuellen Stand der Dinge: Das kalifornische Red-Teaming-Unternehmen Calif nahm PHP im Rahmen der OpenAI-Initiative „Patch the Planet“ unter die Lupe - auf Bitten der PHP Foundation und eigentlich ohne die Erwartung, im seit Jahren durchleuchteten Code noch etwas Kritisches zu finden. Am 1. August fand Calif mit OpenAIs Modell GPT-5.6 Sol die erste ausnutzbare Schwachstelle. OpenAI grub daraufhin selbst weiter und stieß auf zusätzliche Bestandteile des Problems.

Parallel und unabhängig davon war auch Wiz fündig geworden, die zu Google gehörende Sicherheitsfirma. Deren Team identifizierte am 19. August das erste Problem – mit einer Kombination aus Googles Gemini 4 Argon, GPT-5.6 Sol und dem hauseigenen Tool Wiz Atlas. Zusammen mit der PHP Foundation, Cloudflare, dem französischen Sicherheitsunternehmen Quarkslab und mehreren US-Behörden wurde dann über Wochen eine koordinierte Veröffentlichung vorbereitet.

Wiz bringt den Kern der Sache auf den Punkt: Der verwundbare Code war seit über einem Jahrzehnt da. Neu ist, dass KI-Modelle die Schwäche verstehen und daraus einen funktionierenden Exploit bauen können. Die Hürde, die die Lücke jahrelang harmlos erscheinen ließ, haben moderne Modelle schlichtweg eingerissen.

Das Problem: Dieselbe Fähigkeit steht auch der Gegenseite zur Verfügung. Das BSI warnte ausdrücklich, dass Angreifer Sicherheitsupdates heute mit KI-gestützten Werkzeugen in kürzester Zeit analysieren und daraus Exploits generieren können. Eine großflächige Ausnutzung innerhalb weniger Stunden nach dem Patch hielt die Behörde für wahrscheinlich. Früher hatte man nach einem Update ein paar Tage Luft. Diese Schonfrist ist nun offiziell abgeschafft.

Ein Leak, ein Notfall-Patch und ein Rennen gegen die Uhr

Geplant war die koordinierte Veröffentlichung für den 22. Oktober um 14 Uhr UTC. Daraus wurde nichts: Details zu den CVEs und ein Proof of Concept sickerten am 20. Oktober vorzeitig über soziale Medien durch. Die PHP Foundation zog die Veröffentlichung daraufhin um einen Tag vor. Kurz vor 16 Uhr deutscher Zeit standen am 21. Oktober die korrigierten Versionen bereit.

Und ob das Geheimnis überhaupt bis zum Leak eines war, ist fraglich. Amazons Threat-Intelligence-Team registrierte auf seinen Honeypots bereits am 17. Oktober einen Ausnutzungsversuch, vier Tage vor der öffentlichen Bekanntgabe! Cloudflare zählte nach dem Leak binnen 45 Minuten Zehntausende Angriffsversuche, nach zwei Stunden Hunderttausende und bis zum Abend des 21. Oktober Millionen.

Eine kurze Geschichte der Zeit

Datum	Ereignis
2024	Eingeschränkte Variante des Fehlers fällt auf, wird als unbedeutend eingestuft
1. August 2026	Calif findet mit GPT-5.6 Sol die erste ausnutzbare Schwachstelle
19. August 2026	Wiz findet unabhängig davon das erste Problem
17. Oktober 2026	Amazon registriert ersten Ausnutzungsversuch auf Honeypots
20. Oktober 2026	Details und Proof of Concept leaken vorzeitig
21. Oktober 2026, 05:02 Uhr (MESZ)	Cloudflare-WAF-Regeln für alle Kunden aktiv, auch im Free-Tarif
21. Oktober 2026, ca. 16 Uhr (MESZ)	PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35
21./22. Oktober 2026	Behörden, Kliniken und Kommunen nehmen Seiten offline, die meisten kehren nach dem Patch zurück
23. Oktober 2026	PHP warnt vor weiterer, noch ungepatchter Lücke CVE-2026-115560

Der Stand heute: Fast alles wieder online aber noch keine Entwarnung

Die gute Nachricht zuerst: Nahezu alle vorsorglich abgeschalteten Seiten in Deutschland sind inzwischen wieder erreichbar, darunter Ministerien, Polizeibehörden und medizinische Einrichtungen. Die Verbraucherzentralen etwa waren schon am Mittwochabend kurz vor 18 Uhr mit gepatchten Servern zurück. Das BSI und das Digitalministerium haben nach eigenen Angaben bislang keine Meldungen über erfolgreiche Angriffe auf die Bundesverwaltung oder die regulierte Wirtschaft. Digitalminister Karsten Wildberger erklärte, es gebe keine Hinweise darauf, dass Systeme des Bundes betroffen seien.

Die weniger gute Nachricht: „Bislang keine Meldungen“ ist eine Momentaufnahme, kein Freispruch. Das BSI selbst betont, dass erfolgreiche Angriffe derzeit nicht ausgeschlossen werden können, und stuft die Lage weiter mit der Warnstufe Orange ein. International sieht es durchwachsen aus: Sicherheitsfirmen wie watchTowr bestätigen Ausnutzung in freier Wildbahn, Sophos meldete mindestens einen erfolgreichen Angriff, Cisco Talos beobachtet bislang vor allem Scans und verstreute Versuche, erwartet aber, dass die Angriffe raffinierter werden, sobald fähigere Gruppen ihre Werkzeuge angepasst haben. Ein Startup-Gründer berichtete öffentlich, Angreifer hätten über die Lücke seinen Quellcode und interne Dokumente erbeutet.

Und als wäre das nicht genug, legte PHP heute, am 23. Oktober, nach: Mit CVE-2026-115560 gibt es eine weitere mögliche Codeausführung, die von den Mittwochs-Patches nicht abgedeckt ist. Die gute Nachricht hier: Sie betrifft nur Anwendungen, die zur Laufzeit auf eine ziemlich ungewöhnliche Art den Session-Serialisierer umstellen. PHP stuft das Risiko als gering ein, es sind keine Angriffe bekannt, und der Fix kommt mit dem regulären nächsten Release. Bis dahin lautet die Empfehlung: session.upload_progress.enabled=0 in der php.ini setzen – was ohnehin schon für CVE-2026-109619 empfohlen war.

Welche Versionen sind sicher?

PHP-Zweig	Sichere Version (PHP2Shell)	Hinweis
PHP 8.5	8.5.12	Offizieller Fix vom 21.10.2026
PHP 8.4	8.4.27	Offizieller Fix vom 21.10.2026
PHP 8.3	8.3.36	Offizieller Fix vom 21.10.2026
PHP 8.2	8.2.35	Offizieller Fix vom 21.10.2026
PHP 8.1 und älter	kein offizieller Fix	Nur über Backports der Linux-Distribution oder durch Migration auf einen unterstützten Zweig

Was Betreiber jetzt tun sollten

Wer seine Seite am Mittwoch gepatcht hat und seitdem gut schläft, sollte vielleicht noch eine Tasse Kaffee mehr trinken. Denn zwischen Leak und Patch lagen Stunden, in denen Millionen Angriffsversuche durchs Netz liefen. Die Frage ist also nicht nur „Bin ich gepatcht?“, sondern auch „Was ist passiert, bevor ich gepatcht war?“.

1. Version prüfen – und zwar die, die wirklich läuft. php -v auf der Kommandozeile zeigt die CLI-Version, nicht zwingend die des Webservers. Wer mehrere PHP-Versionen parallel betreibt, prüft jeden Pool einzeln, etwa über eine kurzzeitig abgelegte phpinfo()-Seite, die danach sofort wieder verschwindet.
2. Nach dem Update neu starten. PHP-FPM-Worker und mod_php laufen mit dem alten Code weiter, bis sie neu gestartet werden. Ein installiertes Paket ist noch kein geschlossenes Loch.
3. Docker-Images nicht vergessen. Container bringen ihr eigenes PHP mit. Das Update auf dem Host hilft ihnen exakt gar nicht. Images neu bauen, deployen, fertig.
4. Altlasten ehrlich bewerten. Wer noch PHP 8.1, 7.x oder gar 5.x betreibt, bekommt vom PHP-Projekt keinen Fix. Einige Linux-Distributionen liefern für ihre eigenen Pakete Backports – das muss man im Security-Tracker der jeweiligen Distribution konkret nachprüfen. Wo das nicht greift, rät das BSI unmissverständlich, den Server bis zur Migration vom Netz zu nehmen. Unbequem, aber alternativlos.
5. Konfiguration nachschärfen. session.upload_progress.enabled=0 in der php.ini bzw. im FPM-Pool setzen. Wichtig: ini_set() im Anwendungscode oder eine .user.ini reichen dafür nach Angaben des PHP-Projekts nicht.
6. WAF ist eine Brücke, kein Ersatz. Cloudflare hat Schutzregeln für alle WAF-Kunden ausgerollt, auch im kostenlosen Tarif, und nach eigenen Angaben dafür sogar eine neue Erkennungsmethode entwickelt, die Anfrage und Serverantwort gemeinsam auswertet. Cloudflare selbst bezeichnet das aber ausdrücklich als Notlösung. Und wer seinen Origin-Server direkt erreichbar lässt, umgeht die WAF ohnehin komplett.
7. Spuren suchen. Neue oder kürzlich veränderte PHP-Dateien in Upload- und Cache-Verzeichnissen, unbekannte Admin-Accounts im CMS, neue Cronjobs, ungewöhnliche ausgehende Verbindungen, auffällige Einträge in den Access-Logs ab dem 17. Oktober. Wer Hinweise auf eine Kompromittierung findet, behandelt den Server als verloren: sauber neu aufsetzen, Zugangsdaten und API-Schlüssel rotieren, Datenbank-Passwörter inklusive.

Was bleibt: Die Schonfrist ist vorbei

PHP2Shell ist in gewisser Weise eine Erfolgsgeschichte. Die Lücke wurde von den Guten gefunden, über Wochen koordiniert, mit Patches, WAF-Regeln und Behördenwarnungen vorbereitet. Dass am Ende trotzdem halb Behörden-Deutschland offline ging, lag an einem Leak und daran, dass ein erschreckend großer Teil der öffentlichen IT offenbar keinen Plan B hat außer „Stecker ziehen“.

Gleichzeitig zeigt der Fall ziemlich schonungslos, wohin die Reise geht. Wenn KI-Modelle jahrzehntealten Code nach Schwachstellen durchkämmen können, die menschliche Auditoren übersehen oder als harmlos abgetan haben, dann werden wir noch einige solcher Mittwoche erleben. Für die Verteidiger ist das eine Chance, wenn Projekte wie PHP die Ressourcen bekommen, die ihrer Bedeutung entsprechen. Für alle, die ihre Server nach dem Prinzip „läuft doch“ betreiben, ist es eine Drohung. Die Zeit zwischen Patch und Exploit wird nicht mehr in Tagen gemessen, sondern in Stunden. Wer heute noch PHP 7.4 auf einem vergessenen Microsite-Server laufen hat, sollte das als persönliche Einladung verstehen, genau diesen Server jetzt zu suchen. Wir helfen gern beim Finden.

23.10.2026