Der koordinierte PHP-Release für CVE-2026-109618 und CVE-2026-109619 war für den 21. Oktober um 14:00 Uhr UTC geplant. In der Telemetrie unserer Next-Gen WAF scannten bereits mehr als neun Stunden zuvor Tools, die nach der Sicherheitslücke benannt waren. Bis zur Veröffentlichung des Releases waren von mehr als 100 Quell-IP-Adressen aus Tools mit PHP2Shell-Bezug unter mehr als zwei Dutzend Tool-Namen eingesetzt worden. Eines dieser Tools war ein Exploit-Kit, dessen User Agent die Common Vulnerability and Exposure-Nummer enthielt.

Dieser Post zeigt, wie der frühe Traffic aussah, wie sich echter PHP2Shell-Traffic von zwei gleichzeitig laufenden Kampagnen mit ähnlichem Muster unterscheiden lässt und was Sie für Apps in Ihrem Unternehmen tun sollten, auf denen PHP läuft.

Anatomie der Fehler

PHP2Shell ist der Spitzname für zwei kritische PHP-Sicherheitslücken. Beide sind mit CVSS 9,2 bewertet und können Remote-Codeausführung ohne Authentifizierung ermöglichen:

• CVE-2026-109618: Ein Speichermangel kann PHP unterbrechen, während die internen Anfragedaten erst teilweise eingerichtet sind. Bei der anschließenden Bereinigung der Anfrage wird dann auf diese fehlerhaften Daten vertraut.

• CVE-2026-109619: Ein interner Zustand kann über die Lebensdauer des zugrunde liegenden Speichers hinaus bestehen bleiben, und eine spätere Anfrage auf demselben Worker greift ihn auf.

Wer PHP2shell erkennen möchte, sollte beachten, dass es keinen Payload-String gibt, auf den man prüfen könnte. Der Exploit besteht in einer Bedingung: Die Anfrage muss genau im falschen Moment fehlschlagen. 

Laut PHP ist jede Installation gefährdet, die Webanfragen verarbeitet, darunter PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP stuft das Risiko für mod_php am höchsten ein. 

Die Releases mit Fehlerbehebung sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und ältere Versionen gibt es keine Fehlerbehebung von upstream.

Zeitlicher Ablauf

Wie die Offenlegung verlief und wann die ersten PHP2shell-Tools auftauchten. Alle Zeiten in UTC. Die Ereignisse rund um die Offenlegung entsprechen der Darstellung im Postmortem der PHP Foundation und in den Sicherheitshinweisen von GitHub.

Die IDs der PHP2shell-CVEs (2026-109618 & 109619) gelangten ohne technische Details an die Öffentlichkeit, und Tools mit der Bezeichnung PHP2shell tauchten etwa acht Stunden nach dem Exploit-Video in unserer Telemetrie auf. Sowohl das erste Tool mit dieser Bezeichnung als auch das erste Exploit-Kit, das wir beobachteten, tauchten vor dem frühzeitigen Release gepatchter Images auf. Wir spekulieren nicht darüber, was zur Entstehung einzelner Tools geführt hat. Als das koordinierte Release erschien, waren die Scan-Aktivitäten jedoch bereits in vollem Gange.

Der Heuhaufen

Vom ersten Auftreten eines Tools mit PHP2shell im Namen bis zum Mittag des 22. Oktober haben wir etwa 250.000 Anfragen von Tools mit PHP2shell im Namen gespeichert. Sie stammten von rund 3.200 öffentlichen IP-Adressen.

Natürlich verfolgen nicht alle Scanner Angriffsabsichten. Etwa ein Drittel dieses Traffics bezeichnet sich selbst als defensiv: "autorisierte Prüfung auf Exponierung", "Prüfung des Patch-Status", "ohne Ausnutzung". Viele Organisationen überprüften ihre eigenen Umgebungen, und das ist gut so. Diese Selbstbezeichnungen sind unbelegte Behauptungen, passen aber zum Verhalten der betreffenden Anfragen: kleine, harmlose Testanfragen.

Anfragen von Tools mit PHP2shell im Namen, nach Tool-Typ (21. Okt., 03:59 Uhr UTC, bis zum Mittag des 22. Okt.; gerundet). 

Der Rest war ein Mix, und alles ging schnell. Ein Tool zur Erfassung von PHP-Versionen arbeitete sich in etwa elf Stunden von Version 4.0 bis Version 7.2 vor.

Tools, die so schnell iterieren, sorgen dafür, dass Signaturen auf Basis von User Agent-String innerhalb eines Tages veraltet.

The Needles

Bisher lässt sich tatsächlicher Exploit-Traffic am zuverlässigsten anhand des Multipart-Boundary-Strings vom übrigen Traffic unterscheiden. Jedes von uns gefundene Exploit-Kit verwendet im Content-Type -Header einen festen oder nach einem Muster aufgebauten Boundary-Wert. Auf diese Weise identifizierten wir mehr als zehn potenzielle Kits, von denen fünf anhand ihres Namens, ihres User Agents oder ihres Verhaltens direkt mit PHP2shell in Verbindung gebracht werden konnten.

Das am weitesten verbreitete Exploit-Kit sieht so aus:

• POST /index.php (oder /), User Agent php2shell-109618

• Content-Type: multipart/form-data; boundary=B7kQpoc618

• ein Multipart-Body mit fester Größe und ein minimaler Satz an Headern

Es adressiert seine Ziele zudem direkt über ihre IP-Adresse statt über ihren Hostname und sendet pro Host eine oder zwei Anfragen. Es handelt sich also um ein massenhaftes Scannen von IP-Adressbereichen und nicht um eine Kampagne gegen bestimmte Websites. 

Die Größe des Anfrage-Bodys variiert von Kit zu Kit stark. Verlassen Sie sich daher bei der Erkennung dieses Traffics nicht allein auf Größenschwellenwerte.

Zwei ähnliche Fälle, die zuerst ausgeschlossen werden sollten

Wenn Sie in Ihren eigenen Logs nach PHP2shell suchen, erschweren Ihnen zwei weitere Kampagnen die Suche.

React2Shell (CVE-2025-55182). Zwei für PHP2shell kursierende Signaturen sind Multipart-Anfragen mit Chunked-Übertragung und ohne Content-Length sowie Anfrage-Bodys, die mit langen Folgen des Buchstabens A aufgefüllt sind. In der von uns untersuchten Stunde entfielen 98,6 % bzw. 99,9 % der Treffer auf React2Shell. Die Padding-Signatur war bereits am Tag vor dem Release fast ausschließlich auf React2Shell zurückzuführen. React2Shell sendet Anfragen an jeden Pfad, einschließlich /xmlrpc.php und /wp-login.php. Ein einfaches Unterscheidungsmerkmal ist der Anfrage-Header Next-Action, den Next.js Server Actions verwenden, PHP hingegen nie.

Anteil jeder kursierenden "PHP2shell"-Signatur, der tatsächlich auf React2Shell entfällt, gemessen anhand des Next-Action-Headers bei POST-Anfragen an PHP-Endpunkte am 21. Oktober von 21:00 bis 22:00 Uhr UTC. Zur gleichen Stunde am Tag vor dem Release: Die Padding-Signatur war bereits zu 99,7 % React2Shell.

wp2shell. Dabei handelt es sich um eine völlig andere Sicherheitslücke: eine im Juli 2026 bekannt gegebene Sicherheitslücke im WordPress-Kern, die Remote-Codeausführung ohne Authentifizierung ermöglicht. Das zugehörige Kit sendet große Multipart-Bodys an index.php von WordPress, mit einer Boundary, die mit ----wp2shell beginnt. Es war schon lange vor der öffentlichen Bekanntgabe von PHP2shell aktiv. Wer es mitzählt, erzeugt fälschlicherweise den Eindruck, es habe bereits "vor der Veröffentlichung" Aktivitäten rund um php2shell gegeben.

Eine allgemeine Erkenntnis aus beiden Fällen lautet: Eine Signatur, die auf der Struktur einer Anfrage basiert, beschreibt eine Art von Anfrage, nicht einen Angreifer. Vergleichen Sie die Daten mit einem Referenzwert aus der Zeit vor der Offenlegung und schlüsseln Sie jeden Anstieg anhand eines identifizierenden Headers oder einer Boundary auf, bevor Sie ihn einer Quelle zuschreiben.

Was von der Edge aus sichtbar ist – und was nicht

Versuche zu instrumentalisieren sind auf der Edge sichtbar, ihr Erfolg jedoch nicht. PHP2shell bringt einen PHP-Worker zum Absturz oder beschädigt ihn. Deshalb können ein erfolgreicher und ein fehlgeschlagener Versuch von außen gleich aussehen. Wenn Sie vermuten, dass Sie Ziel eines Angriffs waren, finden Sie die Bestätigung auf dem Origin-Server:

• PHP-FPM-Fehler-Logs

• Apache-Fehler-Logs, die Abstürze von Worker-Prozessen zeigen (beispielsweise Einträge wie AH00051 "child pid … exit signal")

• Unerwartete ausgehende Verbindungen von PHP-Worker-Prozessen, da eine Connect-back-Shell ausgehenden Datenverkehr vom Origin erzeugt

Was PHP2Shell über KI aussagt

KI hilft zweifellos bei der Entdeckung von Schwachstellen – und das deutlich schneller als früher. Innerhalb von etwa einem Tag nach dem Auftauchen des ersten Tools beobachteten wir Dutzende Tools mit eigenen Namen, die von rund 3.200 IP-Adressen aus eingesetzt wurden. Eines dieser Tools wurde in etwa elf Stunden von Version 4.0 auf 7.2 weiterentwickelt. 

Wir können nicht mit Sicherheit sagen, ob eines dieser Kits mithilfe von KI erstellt wurde. Was wir jedoch beobachten, ist, dass der Traffic selbst unauffällig ist: Die Kits senden einen festgelegten Multipart-Body an direkte IP-Adressen, mit einer oder zwei Anfragen pro Host, und nutzen dabei dieselben Arten von VPN- und Hosting-Infrastruktur, über die auch die meisten Scans laufen. Unabhängig davon, wie stark KI dabei zum Einsatz kommt, beobachten wir eine Bedrohungslandschaft, die immer größer wird und sich immer schneller verändert.

Und bislang ist die Abwehr vor allem eine Frage menschlichen Handelns. Die Verteidiger überprüften ihre eigenen Systeme und kennzeichneten den Traffic. Threat Hunter teilten Signaturen, die sich fast ausschließlich einer anderen Kampagne zuordnen ließen. Das Einspielen von Patches, das Festlegen von Baselines und das Durchsuchen von Origin-Logs sind nach wie vor weitgehend Aufgaben, die von Menschen erledigt werden, auch wenn KI sie dabei unterstützt. Menschen müssen strategisch planen, welche mehrschichtigen Schutzmaßnahmen an welchen Stellen die richtigen sind.

Nächste Schritte

1. Patch. Führen Sie ein Upgrade auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf das gepatchte Paket Ihrer Distribution durch. Wenn Sie Version 8.1 oder eine ältere Version verwenden, wenden Sie sich wegen Backports an Ihren Paketdistributor oder führen Sie ein Upgrade durch.

2. Verfolgen Sie keine falschen Fährten. User Agent, IP-Adresse und Body-Größen können Sie bei der Bedrohungssuche allesamt in die Irre führen. Der entscheidende Hinweis liegt im Multipart-Boundary-String.

3. Schließen Sie React2Shell und wp2shell aus, bevor Sie etwas als PHP2shell werten.

4. Gehen Sie mit IP-Blocklisten vorsichtig um. Mehrere IP-Adressen auf Listen, die im Zusammenhang mit dieser Sicherheitslücke kursieren, gehören zu VPN- oder Tor-Exit-Nodes oder zu privaten und mobilen Anschlüssen, über die gewöhnlicher Traffic läuft. Eine Sperrung dieser IP-Adressen beeinträchtigt echte Nutzer.

5. Kunden von Fastly Next-Gen WAF: Aktivieren Sie für Apps, die durch Next-Gen WAF geschützt sind, das Signal, das sowohl CVE-2026-109618 als auch CVE-2026-109619 abdeckt. Es handelt sich um eine CVE-spezifische Templated Rule, die als virtueller Patch fungiert und nach strukturellen Anzeichen für Exploit-Versuche sucht.
   Weitere Einzelheiten finden Sie in Fastlys Post zum proaktiven Schutz.
   

Hinweis: Wir empfehlen außerdem, den unten gezeigten Schalter „Automatic Common Vulnerability and Exposure Virtual Patching“ unter „Workspace Konfiguration“ in Betracht zu ziehen:

Indikatoren

Wie wir das gemessen haben

Diese Zahlen stammen aus der Telemetrie zu Anfragen der Fastly Next-Gen WAF vom 20. bis 22. Oktober 2026. Die Zeitpunkte der Offenlegung stammen aus dem Nachbericht der PHP Foundation und den Sicherheitshinweisen von GitHub. Die Zahlen sind Untergrenzen: Wir können nur Anfragen erfassen, die unsere WAF gesehen und aufgezeichnet hat, und einige Zahlen auf Header-Ebene beruhen auf abgeglichenen Stichproben einzelner Stunden statt auf vollständigen Tagen.

Aktuellere Informationen finden Sie unter Proaktiver Schutz von Fastly für PHP2Shell, kritische PHP RCE CVE-2026-109618 und CVE-2026-109619.