Die php2shell-Lücken sind keine Warnung mehr.
Am Wochenende bestätigten Forscher, dass Angreifer die beiden am 21. Oktober gepatchten kritischen PHP-Schwachstellen nicht nur ausprobiert, sondern Code zur Ausführung gebracht haben. Adel Karimishiraz, Leiter Detection and Response bei Perplexity und Betreiber eigener PHP-Honeypots, veröffentlichte auf GitHub eine Analyse, die zeigt: Schadcode erreichte seine Sensoren und lief. Seine Zählung: 35 Shells auf drei Honeypots mit PHP 8.4.26, die Angriffe kamen von zwei IP-Adressen.
Die Spur war vorher schon sichtbar. In den ersten 26 Stunden nach den Patches protokollierte er dutzende Versuche, 30 Out-of-Memory-Ereignisse und 11 abgestürzte Worker-Prozesse — laut, aber kein Beweis für Ausführung. Am Samstagabend schrieb er, er habe möglicherweise Code laufen sehen. Der technische Bericht entschied die Frage.
Am Montag nahm CISA das Paar in den Katalog der bekanntlich ausgenutzten Schwachstellen (KEV) auf: die formale Bestätigung der US-Regierung, dass die Ausnutzung in freier Wildbahn stattfindet — und eine Patch-Frist für Bundesbehörden.
Es handelt sich um CVE-2026-109618 und CVE-2026-109619: unauthentifizierte Remotecodeausführung im PHP-Kern, von PHP 5 bis PHP 8. Das PHP-Team bewertet beide mit 9,2 nach CVSS 4.0, die Forscher, die sie reproduzierten, mit 10,0. Der Unterschied ist akademisch. Entscheidend ist: Es gibt keinen Workaround. PHP-Kernentwickler haben erklärt, die kursierenden Maßnahmen — session.upload_progress abschalten, multipart/form-data blockieren — verhinderten die Ausnutzung nicht zuverlässig. Der Patch ist die Lösung.
Am Volumen bestand nie Zweifel. Cloudflares CTO meldete am Tag der Patches Angriffsversuche und erklärte, WAF-Regeln seien aktiv; Amazons Infrastruktur sah Versuche in Millionenhöhe. Viele Organisationen nahmen ihre Seiten in der vergangenen Woche vorsorglich offline, um zu patchen; die meisten sind wieder erreichbar.
Das Problem ist jetzt der lange Schwanz. Censys zählte am Freitag in Deutschland rund 4,2 Millionen PHP-Versionsstrings, die verwundbaren Releases entsprechen. Am Dienstagmorgen waren es weiterhin über vier Millionen. Censys relativiert die eigene Zahl: Mehrere Linux-Distributionen portieren die Fixes auf ältere Versionsnummern zurück, ein Dienst kann also einen verwundbaren Banner zeigen und trotzdem gepatcht laufen. Die Zahl ist ein Indiz, keine Volkszählung — aber ein großes Indiz.
Für alle, die PHP betreiben, gilt dieselbe Reihenfolge. Erst patchen, überall: jedes Container-Image, jede Build-Pipeline, jeder Staging- und Demo-Host, den seit 2019 niemand geöffnet hat. Der betroffene Bereich beginnt bei PHP 5; die Exposition betrifft also mindestens so sehr vergessene Infrastruktur wie die aktuelle Produktion.
Dann die Logs lesen. Die Sondierungen begannen am Tag der Patches. Jede Anfrage in den Zugriffslogs der letzten Woche, die bekannten Ausnutzungsmustern entspricht, verdient einen zweiten Blick — und jeder Host, der in diesem Fenster ungepatcht erreichbar war, mehr als das.
Unangenehm ist das Tempo. Fünf Tage trennten „Millionen Versuche, keiner erfolgreich“ von „bestätigte Shells, von CISA katalogisiert“. Das ist die normale Form einer breit verteilten, unauthentifizierten RCE in einer Sprache, auf der ein großer Teil des Webs läuft — und der Grund, warum „wir patchen im nächsten Wartungsfenster“ seit Dienstag keine akzeptable Antwort mehr ist.
