Kaum hatte das PHP-Projekt die Lücken geschlossen, liefen die ersten Angriffe. Eine Auswertung des Sicherheitsanbieters Cato Networks zeigt, wie schnell Angreifer bei PHP2Shell zur Stelle waren und dass sie dabei nicht wählerisch sind.
Telemetrie-Auswertung
Cato Networks: So schnell griffen Angreifer PHP2Shell an
Vier Tage lang herrschte Ruhe, dann ging es los: Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Fixes für zwei kritische Schwachstellen im PHP-Kern, die unter dem Namen PHP2Shell zusammengefasst werden. Noch am selben Tag registrierte Cato Networks die ersten Scans und Angriffsversuche gegen Kunden. Das geht aus einem Bericht der hauseigenen Forschungsabteilung Cato CTRL hervor, der Telemetriedaten vom 17. bis 26. Oktober auswertet.
Lücken im Herzen von PHP
Anders als bei vielen PHP-Sicherheitsproblemen steckt der Fehler diesmal nicht in einem Plugin oder einer einzelnen Webanwendung, sondern in der PHP-Laufzeitumgebung selbst. Betroffen ist damit potenziell jede Installation, die PHP ins Netz stellt.
CVE-2026-109618 betrifft die Behandlung von Out-of-Memory-Situationen: Geht während der Initialisierung eines Requests der Speicher aus, kann das den Vorgang unterbrechen und ungültige Daten hinterlassen, die anschließend beim Aufräumen verarbeitet werden. Bei CVE-2026-109619 handelt es sich um einen klassischen Use-after-free: Zu einem Request gehörender Zustand bleibt erhalten, nachdem der zugehörige Speicher bereits freigegeben wurde, und wird später vom selben Worker-Prozess erneut angefasst.
Beide Lücken können ohne Authentifizierung zur Ausführung von Schadcode führen. Am gefährlichsten ist die Konstellation mit Apache und mod_php: Hier kann ein Angriff erfolgen, bevor überhaupt eine Zeile Anwendungscode ausgeführt wird.
Patch-Tag ist Angriffstag
Zwischen dem 17. und 20. Oktober beobachtete Cato keinerlei externe Anfragen, die dem PHP2Shell-Muster entsprachen. Am Morgen des 21. Oktober tauchte dann der erste Scan- beziehungsweise Exploit-Versuch auf. Allein dieser Tag macht laut Bericht rund 72 Prozent aller PHP2Shell-Anfragen im untersuchten Zeitraum aus, etwa zwei Drittel aller Angreifer-IPs traten an diesem Tag erstmals in Erscheinung.
Der Tagesverlauf zeigt ein typisches Muster: Auf einige frühe Scans am Vormittag folgte am Nachmittag ein massiver Burst von einer einzigen Quelle, der für etwa 80 Prozent der Anfragen des Tages verantwortlich war. Später verteilte sich die Aktivität breiter: Zeitweise waren rund 40 Prozent der Quellen des Tages innerhalb einer einzigen Stunde aktiv. Für die Forscher ein klares Zeichen, dass ein Proof of Concept (PoC) die Runde machte und viele Akteure ihn gleichzeitig ausprobierten. In den Folgetagen kamen fast täglich neue Quellen hinzu.
Das deckt sich mit Erkenntnissen von Amazon Threat Intelligence, die ebenfalls am 21. Oktober zirkulierende PoC-Exploits meldete. Amazon will allerdings schon am 17. Oktober, also vier Tage vor der Veröffentlichung, einen einzelnen Exploit-Versuch gegen eigene Honeypots gesehen haben. Im Kundenverkehr von Cato fand sich keine solche Vorab-Aktivität.
Viel Lärm, wenige Absender
Rund 96 Prozent der blockierten Versuche zielten auf CVE-2026-109618, nur etwa 4 Prozent auf den Use-after-free-Fehler. Etwa 59 Prozent stuft Cato als Scans oder Versuche mit ungültigen PoCs ein, also Exploits, die den verwundbaren Codepfad gar nicht korrekt treffen. Die übrigen 41 Prozent waren echte Versuche, Code aus der Ferne auszuführen. Dabei dominierte die direkte Befehlsausführung, gefolgt von Angriffen über Deserialisierung.
Auffällig ist die Konzentration: Ein Großteil der Versuche ging auf eine Handvoll IP-Adressen zurück, die immer wieder PoC-artige Anfragen schickten. Nach Anzahl der Quellen liegen die USA mit rund 36 Prozent vorn, gefolgt von den Niederlanden und Deutschland mit je etwa 14 Prozent. Gemessen an den blockierten Versuchen entfallen etwa 54 Prozent auf US-Adressen, 18 Prozent auf die Niederlande und 16 Prozent auf Moldau. Cato weist allerdings darauf hin, dass Geolokalisierung keine Zuordnung erlaubt. Häufig handelt es sich um angemietete Cloud- oder VPS-Server.
Eine der von Cato veröffentlichten IP-Adressen wurde unabhängig davon auch auf AbuseIPDB als PHP2Shell-Quelle gemeldet. Mit der Indikatorliste von Amazon gibt es dagegen keine Überschneidungen.
Gesundheitswesen nicht gezielt im Visier
Rund ein Drittel der betroffenen Organisationen stammt aus dem Gesundheits- und Sozialwesen, dahinter folgen Technologie- und Sicherheitsdienstleister sowie unter anderem Beratung, Automobilbranche und Bildung. Eine gezielte Kampagne gegen Kliniken sehen die Forscher darin aber nicht: Dieselben Quellen griffen am selben Tag Organisationen aus völlig unterschiedlichen Branchen und Ländern an. Der hohe Anteil könne an der Zusammensetzung des Kundenstamms liegen oder schlicht daran, dass PHP-basierte Portale und Formulare im Gesundheitswesen weit verbreitet sind.
Updaten, und zwar schnell
„PHP2Shell hat gezeigt, wie kurz das Zeitfenster zwischen Patch und Angriff geworden ist“, bilanzieren die Autoren Guy Waizel und Guy Rav On. Die beobachteten Angriffe waren automatisiert, repetitiv und opportunistisch. „Bei einem Fehler auf Ebene der Laufzeitumgebung ist entscheidend, ob ein Unternehmen PHP exponiert, nicht in welcher Branche es tätig ist“, heißt es in dem Bericht.
Cato selbst hebt hervor, dass die eigenen IPS-Signaturen die Angriffe auf überwachtem Datenverkehr blockiert hätten. Erstellt worden seien sie von einem KI-Agenten des Unternehmens innerhalb von Minuten nach dem Patch, anschließend von Forschern geprüft. Ein solches virtuelles Patchen verschafft allerdings bestenfalls Zeit. Admins sollten alle PHP-Instanzen so schnell wie möglich auf die vom PHP-Projekt veröffentlichte, korrigierte Version aktualisieren.
Einschränkend gilt: Die Zahlen beruhen auf einer Stichprobe des von Cato inspizierten Datenverkehrs und bilden nicht die globale Lage ab. Zudem beschreibt der Bericht nur Angriffsversuche, keine erfolgreichen Kompromittierungen.
(red)
