TL;DRAm 21. Oktober hat das PHP-Projekt eine kritische Lücke geschlossen, über die Angreifer ohne Anmeldung Code auf dem Server ausführen können. Inzwischen wird sie aktiv ausgenutzt, und Node.js hatte am selben Tag eine ähnliche Lücke. Wir beschreiben, wie wir die von uns betreuten Seiten abgesichert haben und was Betreiber jetzt tun sollten.
Heute vor einer Woche veröffentlichte das PHP-Projekt vier Sicherheits-Releases auf einmal. Dahinter steckte CVE-2026-109618, inzwischen als „PHP2Shell“ bekannt: eine Lücke im PHP-Kern, die Angreifern ohne Anmeldung das Ausführen von Code erlaubt. Im Bewertungssystem CVSS erhielt sie 9,2 von 10 Punkten. Betroffen waren alle aktuellen PHP-Versionen. Da PHP auf rund 70 % aller Websites läuft, traf das einen Großteil des Internets, darunter viele Websites mit WordPress, TYPO3 oder Drupal und viele Anwendungen auf Basis von Laravel oder anderen PHP-Frameworks. Auch das BSI stufte die Lücke als kritisch ein.
Wiz Research entdeckte die Lücke am 19. August 2026 mit der eigenen Plattform Wiz Atlas und den KI-Modellen Gemini 4 Argon und GPT-5.6 Sol, bestätigte zwei Tage später die Codeausführung gegen WordPress und meldete sie am 24. August an das PHP-Sicherheitsteam. OpenAI berichtet, dass GPT-5.6 Sol dieselbe Lücke unabhängig im Programm „Patch the Planet“ aufgespürt hat. Es folgten zwei Monate koordinierter Vorbereitung mit dem PHP-Team und großen Infrastruktur-Anbietern, bevor die Patches am 21. Oktober erschienen. Betroffen war Code, der seit PHP 5.4 unverändert mitlief.
KI-Modelle finden inzwischen viele alte Fehler in verbreiteter Software. Die Tabelle zeigt eine Auswahl aus den vergangenen drei Monaten. Alle Einträge sind als kritisch oder hoch eingestuft, meist handelt es sich um Speicherfehler, Codeausführung oder Dienstausfall, oft ohne Anmeldung erreichbar.
Der Schweregrad ist der CVSS-Wert der schwersten Lücke laut CVE-Eintrag oder Hersteller-Advisory. Elf der 16 Einträge betreffen C-Code, zwei weitere C++. Meist trifft es Code, der Daten von außen verarbeitet: HTTP/2, TLS, DNS, Bilder, Kompression. Bei vier Einträgen, PHP2Shell eingeschlossen, waren KI-Modelle an der Suche beteiligt.
Was bedeutet die aktuelle Lücke für meine Seite oder App?
„PHP2Shell“ betraf den PHP-Interpreter selbst, also eine Schicht unter jeder Anwendung. Ein Angreifer braucht keinen Login und kein fehlerhaftes Plugin. Er sendet eine präparierte Anfrage an einen verwundbaren Server, und PHP verarbeitet sie, bevor WordPress zum Zug kommt. Ein Wartungsmodus hilft deshalb nicht. Am stärksten betroffen war PHP als Apache-Modul, und so läuft es auch im offiziellen WordPress-Image.
Am selben Tag schloss Node.js eine ähnliche Lücke. Über „Node2Shell“ ließ sich mit präparierten, Brotli-komprimierten Daten Code auf dem Server ausführen. Das betrifft auch Next.js, mit dem wir selbst arbeiten. Unsere Next.js-Anwendungen laufen seither auf einer gepatchten Node.js-Version.
Plugin-Updates hätten in beiden Fällen nicht geholfen. Aktualisiert werden muss die Laufzeitumgebung selbst, also PHP oder Node.js.
Wie sich das Internet vorbereitet hat
In den zwei Monaten bis zum Patch wussten nur wenige von der Lücke: das PHP-Team, die Entdecker und eine Reihe großer Infrastruktur-Anbieter, darunter Cloudflare, Akamai, AWS, Fastly und Google. Die Geheimhaltung soll verhindern, dass Angreifer von einer Lücke erfahren, bevor es einen Schutz gibt.
Die Anbieter waren eingeweiht, weil sie vor einem großen Teil aller Websites stehen. Ihre Web Application Firewalls (WAF) prüfen jede Anfrage, bevor sie den eigentlichen Server erreicht. Cloudflare entwickelte ab Anfang Oktober Regeln, die präparierte Anfragen erkennen, und schaltete sie am frühen Morgen des 21. Oktober für alle Kunden ein, auch im kostenlosen Tarif. Das war Stunden vor dem Patch. Laut Cloudflare war die Lücke vorab durchgesickert, und erste Angriffe liefen bereits.
Öffentlich gab es nur einen knappen Vorlauf. Am 20. Oktober kündigte das PHP-Projekt ein kritisches Sicherheitsupdate für den Folgetag an, ohne Details. Wer diese Ankündigung nicht verfolgt hat, erfuhr erst aus den Nachrichten davon.
Wie haben wir reagiert?
Wir haben am 21. Oktober aus den Nachrichten von der Lücke erfahren und sind in drei Schritten vorgegangen:
Neu bauen. Sobald die offiziellen PHP- und WordPress-Images aktualisiert waren, haben wir die Images unserer Kundenseiten neu gebaut.
Ausrollen. Am Morgen nach dem Release liefen alle Seiten mit dem gepatchten PHP 8.5.12.
Berichten. Die Kunden bekamen am selben Morgen unseren Bericht.
Das Update selbst war wenig Aufwand, weil die Seiten als Container auf dem offiziellen WordPress-Image aufbauen. Bei klassischem Webhosting hätten wir je nach Anbieter auf dessen Update warten müssen.
Warum uns unsere eigenen Scanner nicht gewarnt haben
Wir betreiben Dependency-Track, ein Open-Source-Werkzeug, das Stücklisten von Software (SBOM, Software Bill of Materials) gegen Schwachstellen-Datenbanken abgleicht. Die Stücklisten entstehen bei uns auf drei Wegen:
Automatisiert in der Build-Pipeline
Im laufenden Cluster, direkt aus den Containern
Bei Bedarf mit weiteren Werkzeugen wie syft
Während des Rollouts haben wir uns gewundert, warum keiner unserer Scanner die Lücke anzeigte. Dependency-Track bezieht seine Daten vor allem aus der National Vulnerability Database (NVD), der Schwachstellen-Datenbank des US-Standardinstituts NIST. Sie ergänzt gemeldete Lücken um das, was Scanner für den Abgleich brauchen: Schweregrad, betroffene Produkte und Versionsbereiche. Für PHP2Shell hat sie die Versionsbereiche drei Stunden nach der Veröffentlichung eingetragen.
Bei uns sind diese Daten trotzdem nicht angekommen. Unser Dependency-Track lädt die NVD-Daten einmal täglich als Jahresdatei, und die NVD erneuert diese Datei nur einmal pro Nacht. Die Datei, die unser Server am Abend des 21. Oktober geladen hat, enthielt die Lücke deshalb noch nicht. Die vom 22. Oktober konnte unser Server nicht mehr herunterladen, weil der NVD-Server nur wenige Kilobyte pro Sekunde lieferte und die Verbindung sechsmal hintereinander abbrach. Dependency-Track kannte die Lücke nur aus der Debian-Datenbank. Die gilt aber nur für PHP aus Debian-Paketen, und das offizielle Image baut PHP aus dem Quellcode.
Stand heute: Die Lücke wird ausgenutzt
Inzwischen kennt auch unser Dependency-Track die Lücke. Für ein Test-Image mit dem alten PHP 8.5.11 zeigt es die beiden CVE-Einträge, unter denen PHP2Shell geführt wird. Die Werte in zwei Spalten zeigen, dass die Lücke angegriffen wird.
KEV: Yes. Die US-Cybersicherheitsbehörde CISA führt einen Katalog der Lücken, die nachweislich angegriffen werden. Am 26. Oktober hat sie beide PHP2Shell-Lücken aufgenommen. US-Bundesbehörden müssen sie bis zum 29. Oktober schließen.
EPSS: nahe 1. Das Exploit Prediction Scoring System schätzt, wie wahrscheinlich eine Lücke in den nächsten 30 Tagen angegriffen wird. Ein Wert nahe 1 bedeutet, dass ein Angriff so gut wie sicher ist.
Kurz nach dem Patch zählte Cloudflare Millionen Angriffsversuche, einen erfolgreichen Einbruch konnte aber niemand belegen. Das BSI hielt die Lücke am 22. Oktober für schwerer auszunutzen als erwartet. Am 24. Oktober dokumentierte dann ein Sicherheitsforscher 35 erfolgreiche Angriffe auf Köder-Server, die mit PHP als Apache-Modul liefen, also so wie das offizielle WordPress-Image. Die TU Delft zählt über 50.000 Angriffsanfragen aus 70 Ländern. In Deutschland melden laut heise noch immer über vier Millionen Dienste eine verwundbare PHP-Version.
Wer noch nicht aktualisiert hat, sollte das heute tun. Wer schon aktualisiert hat, sollte trotzdem prüfen, ob vorher jemand eingedrungen ist, denn Amazon sah erste Angriffsversuche bereits am 17. Oktober, vier Tage vor dem Patch.
Was sich jetzt ändert
Aus dem Vorfall haben wir fünf Aufgaben für unseren Betrieb abgeleitet:
Alle Kundenimages in Dependency-Track aufnehmen. Jedes gebaute Image lädt seine Stückliste hoch. Dependency-Track meldet dann auch Lücken in Images, die wir länger nicht neu gebaut haben.
Benachrichtigung einschalten. Neue kritische Treffer schickt Dependency-Track per E-Mail oder Chat an uns. Läuft der Abgleich mit der NVD länger als 24 Stunden nicht durch, kommt ebenfalls eine Meldung.
Die NVD-Daten über einen eigenen Spiegel beziehen. Dann hängt der Abgleich nicht an der Erreichbarkeit eines einzelnen Servers in den USA.
Die Sicherheitsmeldungen der Hersteller abonnieren. Das PHP-Projekt zum Beispiel kündigt solche Releases einen Tag vorher an.
Versionen festschreiben. Für jedes Image steht im Repository, welche PHP-Version es enthält. Bei der nächsten PHP-Lücke sehen wir dort sofort, welche Seiten betroffen sind.