PHP2Shell: Die Angriffe begannen vier Tage vor dem Patch

Vier Tage bevor PHP die beiden Lücken öffentlich machte, lief der erste Angriffsversuch. Amazon Threat Intelligence fand ihn in der Telemetrie seines Honeypot-Netzwerks MadPot, datiert auf den 17. Oktober 2026. Wer PHP2Shell abschließt, sobald die Versionsnummer stimmt, prüft damit vier Tage zu wenig.

Was Amazon vor der Offenlegung gesehen hat

Amazon Threat Intelligence hat am 21. Oktober 2026 veröffentlicht, dass der früheste Ausnutzungsversuch von PHP2Shell in seiner MadPot-Telemetrie auf den 17. Oktober 2026 datiert – vier Tage vor der Offenlegung, drei Tage vor dem Leak. Die Anfrage kam aus einem kommerziellen Anonymisierungsnetz und traf einen Honeypot, für Amazon ein Hinweis auf einen Angreifer und nicht auf Forschung. Wie der Akteur vorab an Exploit-Informationen kam, ist offen.

Ab 02:00 UTC am 21. Oktober, zwölf Stunden vor dem Release um 14:00 UTC, sah MadPot mehrere Proof-of-Concept-Exploits von weiterer anonymisierter Infrastruktur. Payloads und Herkunft unterschieden sich, was auf mehrere unabhängige Akteure deutet; ob einer gegen echte Systeme funktioniert hätte, lässt Amazon offen. CJ Moses, CISO von Amazon Integrated Security, fasst den Stand nach dem Release in einem Satz zusammen: „PHP2Shell is now being broadly exploited in the wild.“ Mechanismus, Patch-Stände und Sofortmaßnahmen stehen im Beitrag von gestern.

Wie die Exploits vor den Patch kamen

Der 17. Oktober bleibt unerklärt, die zwölf Stunden vor dem Release nicht. Die PHP Foundation hat diese Kette in ihrem Postmortem vom 21. Oktober offengelegt:

An Chainguards Alleingang stört die Foundation nicht die frühe Verfügbarkeit des Fixes, sondern seine Vergleichbarkeit: „Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release.“ Chainguards CEO Dan Lorenc bestreitet den Zeitpunkt nicht, wohl aber die Bewertung: „I made the call to get these out early when exploits hit in the wild.“ Das Sicherheitsteam der Foundation selbst hatte zum Release keinen funktionsfähigen öffentlichen Exploit identifiziert und nennt die Verzögerung seit dem ersten Hinweis von 2024 „a structural failure“.

Stand 22. Oktober: Millionen Versuche, keine bestätigte Übernahme

Bestätigt ist bis heute kein erfolgreicher Einbruch über PHP2Shell – bestätigt ist die Zahl der Versuche. Cloudflare-Chef Matthew Prince nennt für das eigene Netz Tausende Versuche in den zehn Stunden vor der Ankündigung, Zehntausende in den 45 Minuten danach, Hunderttausende binnen zwei Stunden und inzwischen Millionen. Cloudflare beobachtet außerdem, dass Angreifer ihre Payloads variieren und dabei auswerten, welche Anfragen die Web Application Firewall blockt.

Gegen die Masse steht die Qualität. Jake Knott von watchTowr sagt, keiner der kursierenden Proof-of-Concepts erreiche Code-Ausführung: Sie scheitern, messen Zeitunterschiede oder bringen den Zielprozess zum Absturz. VulnCheck sah mindestens eine Adresse, die erfolglos versuchte, eine Webshell abzulegen. Das BSI schreibt in Version 1.1 seiner Warnung vom 21. Oktober: „Zum aktuellen Zeitpunkt sind noch keine bestätigten Ausnutzungen der Schwachstellen bekannt.“ Im CISA-KEV-Katalog stehen beide Nummern am 22. Oktober weiterhin nicht. JFrog fand in öffentlichen Repositories außerdem gefälschte Exploits und Scherz-Malware – wer solchen Code gegen eigene Systeme testet, prüft womöglich etwas anderes als die Lücke.

Was das für Ihre Untersuchung bedeutet

Amazon empfiehlt, den Untersuchungszeitraum am 17. Oktober zu beginnen, nicht am Patch-Tag. Praktisch heißt das zuerst, Beweise zu sichern, bevor die Rotation sie löscht: Webserver-Logs sowie Prozess- und Dateizustände aller erreichbaren PHP-Systeme ab dem 16. Oktober.

• Anfragen: POST-Anfragen, die in multipart/form-data-Körpern die Zeichenfolge PHP_SESSION_UPLOAD_PROGRESS tragen; dazu Häufungen von HTTP 500 und abgestürzte PHP-Worker.
• Prozesse: jede Shell, jeder Interpreter und jedes Download-Werkzeug, das php-fpm, php-cgi, httpd oder apache2 gestartet hat, dazu neue Dateien im Webroot.
• Erkennung ohne Signatur: Amazon empfiehlt Detektionen, die nicht an CVE-spezifischen Signaturen hängen – die erste Ausnutzung liegt regelmäßig vor der ersten Signatur.
• Indikatoren: Amazon veröffentlicht sechs Adressen aus seiner Telemetrie. Sie gehören zu gemeinsam genutzter Anonymisierungsinfrastruktur und sind nicht exklusiv für diese Aktivität – als Suchanlass taugen sie, als Blockliste nicht.

103.216.220.92     17.10.2026
31.223.184.166     21.10.2026
37.19.200.5        21.10.2026
134.209.159.64     21.10.2026
103.114.163.188    21.10.2026
95.217.98.37       21.10.2026

Für die Frist, die solche Fälle setzen, ist Amazons nüchternster Satz der wichtigste: „A 7-day or 30-day SLA assumes a delay that no longer exists.“ Der Grund ist strukturell und nicht auf PHP beschränkt: KI-gestützte Analyse macht es billiger, aus einem Patch-Diff oder einem Advisory einen funktionierenden Exploit zu bauen.

Was hilft – und warum Sichtbarkeit entscheidet

Eine Frist in Stunden setzt voraus, dass das Inventar vorliegt, wenn das Advisory erscheint – zwischen dem 17. und dem 21. Oktober war genau das die einzige nutzbare Information.

blacklens.io erfasst über Attack Surface Management laufend, welche Dienste und Webanwendungen von außen erreichbar sind und welche Technologien darauf laufen; interne Systeme deckt der Sentry Agent ab. Das Threat Center gleicht neue CVEs mit diesem Inventar ab und zeigt je Treffer EPSS-Wert, KEV-Eintrag, verfügbare Exploits und ob die Zuordnung auf der exakten Version oder nur auf dem Produkt beruht. Die Spurensuche auf dem Host selbst deckt das nicht ab; dafür bleiben Logs und Überwachung auf dem System zuständig.