PHP-Sicherheitslücke PHP2Shell: Ein Patch ist nicht genug

Zwei 14 Jahre alte PHP-Sicherheitslücken galten bis vor kurzem als ungefährlich. Bis KI-Modelle die komplexe Exploit-Kette umsetzten und Angreifern ermöglichten, eingeschleusten Code auf Webservern auszuführen. Inzwischen stehen Patches zur Verfügung. Doch nur weil ein System gepatcht wurde, heißt das noch lange nicht, dass es nicht kompromittiert wurde. Worauf Unternehmen jetzt achten müssen und wie sich Kompromittierungen aufspüren lassen.

Eine alte Schwachstelle wird zur akuten Gefahr

Die kürzlich bekannt gewordenen kritischen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619, die gemeinsam als PHP2Shell bezeichnet werden, erfüllen alle Kriterien eines ernsten Sicherheitsvorfalls. Angreifer können Befehle auf betroffenen Webservern ausführen, ohne autorisiert zu sein. Zwar waren die Sicherheitslücken, die ursprünglich aus der PHP-Version 5.4 aus dem Jahr 2012 stammen, bereits 2024 entdeckt worden, zunächst gab es aber keine Hinweise auf funktionierende Exploits. 

Im Oktober diesen Jahres, noch bevor die Schwachstellen offiziell bekannt gegeben wurden, registrierten sogenannte Honeypots (Köderserver, die Cyberkriminelle anlocken und ablenken sollen) von Amazon entsprechende Angriffsversuche. Die technischen Details gelangten an die Öffentlichkeit, bevor die Fixes fertiggestellt worden waren. 

PHP ist eine der am weitesten verbreiteten Skriptsprachen im Web, CMS-Systeme wie WordPress, Drupal oder Typo3 sowie zahlreiche weitere E-Commerce-Anwendungen und Webmail-Oberflächen basieren darauf. Zwar stellte die PHP Foundation zeitnah Patches bereit. Trotzdem bleibt für viele Unternehmen, die PHP einsetzen, die Frage offen, ob sie Ziel eines Angriffs wurden und ob sich möglicherweise Schadcode auf den eigenen Servern befindet.

KI fand die Lücke. Und baute den Exploit.

Warum die Sicherheitslücken gerade jetzt entdeckt und so schnell ausgenutzt werden konnten, liegt an der rasanten Entwicklung der KI-gestützten Cybersecurity. Gleich zwei Teams von KI-Sicherheitsfirmen entdeckten die PHP-Sicherheitslücken unabhängig voneinander innerhalb weniger Wochen und koordinierten anschließend die Offenlegung und die Patch-Verifizierung.

Auch auf der Seite der Kriminellen lieferte KI die entscheidende Unterstützung. Die Sicherheitslücken existieren seit 14 Jahren, galten ohne funktionierenden Exploit aber als nicht ausnutzbar. Die notwendige Folge von Schritten, die Exploit-Kette, war hier zu komplex, um mit klassischen Programmiertechniken aufgebaut zu werden. Leistungsfähige KI-Modelle der aktuellen Generation (hier im Einsatz: OpenAIs GPT-5.6, Googles Gemini 4 Argon, Wiz Atlas) machten diese Komplexität beherrschbar. Der iterative Prozess, der hier notwendig war, um den Exploit zu programmieren, gehört zu den Kernkompetenzen von LLMs.

Ein gepatchtes System ist nicht automatisch ein unberührtes System

Die Patches für PHP2Shell stehen zur Verfügung und sollten so schnell wie möglich eingespielt werden. Der technische Ablauf der Angriffsversuche zeigt aber zugleich, dass das möglicherweise noch nicht ausreicht. Ein Angreifer, der über PHP Code ausführen kann, benötigt in der Regel keine Schadsoftware. Der Webserver selbst verfügt über eine Shell, eine Netzwerkverbindung und den Zugriff auf Dateien. Angreifer nutzen daher vorhandene Systemwerkzeuge, um nach Zugangsdaten zu suchen, Informationen zu sammeln oder sich im Netzwerk zu bewegen. Dabei hinterlassen sie kaum offensichtliche Spuren, denn der Webserver verhält sich weiterhin wie ein Webserver.

Dagegen liefert eine Analyse der Netzwerkkommunikation verlässliche Verdachtsmomente. Ein System, das jahrelang ein gleichmäßiges Anwenderprofil aufwies, kontaktiert plötzlich bisher unbekannte Adressen oder kommuniziert mit internen Systemen, mit denen es bisher keine Berührungspunkte hatte. Solche Auffälligkeiten zeigen sich weder im Patch-Status noch bei einer Virenprüfung.

Ein weiterer Punkt kommt erschwerend hinzu: In vielen Infrastrukturen läuft PHP in Anwendungen, die nirgends als solche gekennzeichnet sind. Dazu kommen historisch gewachsene Systeme und Shadow IT, die in keinem Asset-Inventar auftauchen. Diese Systeme werden deshalb möglicherweise gar nicht gepatcht oder überwacht. So bleiben Sicherheitslücken bestehen, ohne dass jemand davon etwas weiß.

Was jetzt konkret zu tun ist

Vier Maßnahmen, die Unternehmen jetzt umsetzen sollten:

• Sofort patchen: Für PHP 8.2 bis 8.5 stehen Fixes zur Verfügung, die so schnell wie möglich eingespielt werden sollten. Für PHP 8.1 und ältere Versionen gibt es keine oder nur eingeschränkte Updates. Für diese Systeme wird eine Migration erforderlich.

• Folgeaktivitäten prüfen: Nach dem Patch sollte gezielt untersucht werden, ob betroffene Systeme bereits kompromittiert wurden. EDR- (Endpoint Detection and Response) und NDR-Lösungen (Network Detection and Response) liefern dabei unterschiedliche Hinweise: EDR kann Aktivitäten auf Endgeräten und Servern erfassen. NDR ergänzt diese Sicht um beobachtbare Netzwerkkommunikation, etwa ungewöhnliche Verbindungen eines Webservers. Für ein vollständigeres Bild sollten Netzwerkdaten mit EDR-, Webserver- und WAF-Logs (Web Application Firewall) korreliert werden.

• Unbekannte Systeme aufspüren: Um die eigene Exposition realistisch einschätzen zu können, müssen unbekannte und nicht verwaltete PHP-Systeme im eigenen Netz aufgespürt werden. Indikatoren im Netzwerkverkehr wie .php-Endpunkte oder PHPSESSID-Cookies verraten PHP-Anwendungen auch dann, wenn sie sonst nirgends dokumentiert sind.

• Spuren sichern: Besteht der Verdacht einer Kompromittierung, sollten Logs und Arbeitsspeicher-Snapshots gesichert werden, bevor das System neu gestartet wird.

Um wirklich sicher zu sein, dass kein System kompromittiert wurde, genügen die Patches allein nicht. Gemeinsam mit unserem Partner Vectra AI bieten wir Unternehmen an, ihre IT-Infrastruktur gezielt auf PHP-Expositionen und mögliche Folgeaktivitäten zu untersuchen.

Sprechen Sie uns an, wenn Sie mögliche PHP-Sicherheitslücken und eine bereits erfolgte Ausnutzung in Ihrer Umgebung analysieren möchten.

Mehr zur Einordnung von Vectra AI: A patched PHP server can still be a compromised one und zu unseren gemeinsamen Lösungen.