Amazon sah PHP2Shell-Angriffsversuche vier Tage vor der Offenlegung

Jemand hat versucht, PHP2Shell auszunutzen, vier Tage bevor die meisten Verteidiger davon wussten. Laut Amazon hat sein Honeypot-Netz MadPot am 17. Oktober 2026 einen Angriffsversuch auf die beiden PHP-Lücken protokolliert. Die Korrekturen und die öffentliche Offenlegung kamen erst am 21. Oktober um 14:00 Uhr UTC. Inzwischen sagt Amazon, dass die Lücken breit ausgenutzt werden.

PHP hat die beiden Lücken, CVE-2026-109618 und CVE-2026-109619, am Mittwoch in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Beide sind mit 9.2 bewertet und können einem Angreifer erlauben, ohne Anmeldung Code auf einem Webserver auszuführen. Nach Amazons Zeitleiste kann ein Server, der am Mittwoch gepatcht wurde, schon vorher angegriffen worden sein.

Was Amazon gesehen hat

MadPot ist Amazons Netz aus Honeypots, also Köderservern, die Angreifer anlocken und protokollieren, was sie tun. Im Beitrag im AWS Security Blog beschreibt Amazon, was seine Sensoren aufgezeichnet haben.

Zeit (UTC)	Was geschah
17. Oktober	MadPot protokolliert den ersten Versuch, von einer Adresse eines kommerziellen Anonymisierungsnetzes
20. Oktober	Die CVE-Nummern kursieren auf Hacker News und in sozialen Medien, berichtet Tenable
21. Oktober, gegen 02:00	Der erste Proof-of-Concept-Exploit taucht auf, etwa 12 Stunden vor den Korrekturen
21. Oktober, 02:00 bis 08:00	Weitere Versuche kommen von anderer anonymisierter Infrastruktur
21. Oktober, 14:00	Das Embargo endet und die Korrekturen erscheinen

Die Versuche am 21. Oktober nutzten unterschiedliche Payloads und Infrastruktur, was laut Amazon auf mehr als einen Angreifer hindeutet. Nach der Veröffentlichung tauchten binnen Stunden weitere Exploits auf, die fast sofort Amazons Sensoren erreichten.

Amazon ist vorsichtig bei dem, was es nicht weiß. Die Sensoren sind Köder, also kann Amazon nicht sagen, ob die frühen Versuche auf echten Systemen funktioniert hätten. Amazon schreibt außerdem, es sei „weiterhin unklar, wie der Akteur vor der Offenlegung an Exploit-Informationen gelangte“. Der Versuch vom 17. Oktober kam drei Tage bevor die CVE-Nummern durchsickerten.

Wie das Embargo zerbrach

Ein Embargo ist die stille Phase, in der ein Projekt und seine Partner Korrekturen vorbereiten, bevor jemand einen Fehler ankündigt. Das Embargo für PHP2Shell hielt nicht.

Laut Tenable und The Hacker News plante die PHP Foundation das Release zuerst für den 22. Oktober. Nachdem die CVE-Nummern durchgesickert waren, zog sie es um einen Tag vor. The Register berichtet, dass die Foundation außerdem Chainguard, das Container-Images veröffentlicht, vorwarf, gepatchte Builds vor der vereinbarten Frist herausgegeben zu haben. „Jeder Angreifer konnte nun die Korrektur in Binärform studieren, während alle anderen PHP-Nutzer noch auf das Release warteten“, sagte die Foundation laut The Hacker News. Eine Antwort von Chainguard enthalten die Berichte nicht.

Wie groß die Angriffswelle ist

Matthew Prince, CEO von Cloudflare, hat auf X Zahlen genannt. Cloudflare sah in den 10 Stunden vor der Ankündigung Tausende Versuche. In den 45 Minuten danach stieg das auf Zehntausende, binnen zwei Stunden auf Hunderttausende. Inzwischen spricht Prince von „Millionen“.

Der Hosting-Anbieter Pantheon hat mehr als 60.000 verdächtige Anfragen blockiert, berichtet The Hacker News. Cloudflare sagt, dass Angreifer ihre Payloads ständig ändern, um an den Firewall-Regeln vorbeizukommen. Keine dieser Zahlen belegt einen erfolgreichen Einbruch. Sie zeigen Versuche, die blockiert oder aufgezeichnet wurden.

The Hacker News zitiert CJ Moses, CISO von Amazon Integrated Security, dazu, warum das immer wieder passiert: „KI-gestützte Analyse macht es billiger, aus einem Patch-Diff oder einer Sicherheitsmeldung einen funktionierenden Exploit zu machen.“

Was das für Entwickler bedeutet

Wer PHP betreibt, muss ab dem 17. Oktober nachforschen, nicht erst ab dem Tag des Patches. Amazon sagt es deutlich: „Beginnen Sie Untersuchungen bei der frühesten bekannten Ausnutzung, nicht beim Datum der Offenlegung.“

• Zuerst patchen. Installieren Sie 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und starten Sie danach jeden PHP-Worker neu, damit der neue Code wirklich läuft. Laut Amazon behebt nur ein Upgrade beide Lücken vollständig.
• Die Logs nach dem bekannten Muster durchsuchen. Amazon rät, nach POST-Anfragen zu suchen, die in Formular-Uploads die Zeichenkette PHP_SESSION_UPLOAD_PROGRESS enthalten. Die Sicherheitsfirma Hadrian sagt, dass die meisten Angriffe, die sie sieht, diesen Pfad für den Upload-Fortschritt von Sessions missbrauchen.
• Nach Spuren ausgeführten Codes suchen. Prüfen Sie Server auf unerwartete Prozesse und geänderte Dateien. Das FBI rät, auf PHP-Prozesse zu achten, die Kommandozeilen starten oder Dateien herunterladen.
• Notlösungen nur bis zum Patch nutzen. PHPs eigene Liste nennt die Einstellung session.upload_progress.enabled=0 und einen Neustart der Worker. Amazon schlägt außerdem vor, Multipart-Datei-Uploads zu blockieren, wenn Ihre App ohne sie auskommt.
• Öffentlichem Exploit-Code nicht trauen. JFrog meldet gefälschte PHP2Shell-Exploits und Scherz-Malware auf GitHub. Tenable warnt, dass kursierender Code Malware enthalten kann.
• Die genannten IP-Adressen prüfen, aber nicht allein auf Sperren setzen. Amazon veröffentlicht sechs davon, rät aber eher zum Untersuchen als zum Sperren, weil sie zu gemeinsam genutzten Anonymisierungsdiensten gehören.