Amazon zufolge zeichnete MadPot am 17. Oktober 2026 einen PHP2Shell-Angriffsversuch gegen einen Honeypot auf, vier Tage vor der öffentlichen Offenlegung der beiden PHP-Sicherheitslücken. PHP veröffentlichte am 21. Oktober die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
Was Amazon vor der Offenlegung registrierte
Amazon datierte den Versuch gegen seinen Honeypot auf den 17. Oktober. Für den 21. Oktober meldete das Unternehmen erste Proof-of-Concept-Exploits gegen etwa 02:00 UTC sowie weitere Versuche gegen MadPot zwischen 02:00 und 08:00 UTC. PHP hob die Sperrfrist um 14:00 UTC auf. Innerhalb weniger Stunden registrierte Amazon weitere Proofs of Concept und Angriffsversuche an seinen Sensoren. Amazon schilderte die MadPot-Beobachtungen in einem eigenen Bericht.
Die Beobachtungen betrafen Amazons Honeypot und Sensoren. Amazon konnte nicht feststellen, ob die Versuche gegen reale Systeme erfolgreich gewesen wären. Das Unternehmen wusste auch nicht, wie der Akteur vor der öffentlichen Offenlegung von der Sicherheitslücke erfahren hatte.
Welche Systeme PHP2Shell betrifft
PHP2Shell ist die Sammelbezeichnung für zwei kritische Schwachstellen im PHP-Kern: CVE-2026-109618 und CVE-2026-109619. Beide können laut PHP unauthentisierte Remote Code Execution ermöglichen, also das Ausführen von Code auf einem Server aus der Ferne. PHP bewertete beide Lücken mit CVSS 4.0 jeweils mit 9,2 von 10.
CVE-2026-109618 betrifft die Speicherverwaltung nach einem Speichermangel: Dabei können Anfragedaten unvollständig initialisiert bleiben und beim Beenden der Anfrage verarbeitet werden. Bei CVE-2026-109619 kann ein Worker veralteten globalen Zustand weiterverwenden, obwohl der Speicher, auf den er verweist, bereits freigegeben wurde. Ein späterer Request kann auf diesen Zustand zugreifen, bevor PHP ihn neu initialisiert. Die PHP-Sicherheitsmeldungen zu CVE-2026-109618 und CVE-2026-109619 beschreiben die beiden Fehler im Detail.
PHP nennt alle Installationen, die Webanfragen verarbeiten, als betroffen. Dazu gehören PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Apache mod_php stuft PHP als Konfiguration mit dem höchsten Risiko ein.
Welche PHP-Versionen die Lücken schließen
Die von PHP veröffentlichten korrigierten Upstream-Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Upstream gelten Versionen unterhalb der jeweils passenden korrigierten Versionsnummer als betroffen. Bei Distributionspaketen können Anbieter die Sicherheitskorrekturen zurückportieren, daher muss der Status des konkreten Pakets berücksichtigt werden.
PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine regulären Updates mehr. PHP zufolge können Distributionen und Anbieter mit Langzeitunterstützung trotzdem Korrekturen zurückportieren. Für PHP 7.4, 8.0 und 8.1 stellte das PHP-Team außerdem Backports auf Quelltextebene bereit.
Ein WAF oder eine Konfigurationsänderung ersetzt das Update nicht. PHP bezeichnet ein korrigiertes Release als einzige vollständige Abhilfe. Konfigurationsmaßnahmen können einzelne Angriffswege reduzieren, machen eine Installation aber nicht sicher.
