Amazon Web Services (AWS) zufolge registrierte das Honeypot-Netzwerk MadPot am 17. Oktober 2026 einen PHP2Shell-Exploitversuch, vier Tage vor der öffentlichen Offenlegung der beiden Sicherheitslücken. Der Versuch richtete sich gegen einen Honeypot. AWS kann nicht sagen, ob die beobachteten Angriffe auf realen Systemen erfolgreich gewesen wären.

Was AWS vor der Offenlegung registrierte

MadPot erfasste den Versuch laut AWS von einer IP-Adresse, die einem kommerziellen Anonymisierungsnetzwerk zugeordnet war. Wie der Absender vor der Offenlegung an Informationen über den Exploit gelangte, ist AWS zufolge unklar. Der Bericht beschreibt einen Versuch gegen das AWS-Sensornetzwerk, keinen bestätigten Angriffserfolg auf einem Produktivserver.

Am 21. Oktober beobachtete Amazon Threat Intelligence laut AWS weitere Proof-of-Concept-Exploits und Versuche gegen MadPot. Unterschiedliche Nutzlasten und Anonymisierungsinfrastruktur deuteten auf mehrere Akteure hin; die technische Analyse lief noch.

Welche PHP-Fehler betroffen sind

PHP bezeichnet PHP2Shell als zwei kritische Fehler im PHP-Kern, die unauthentisierte Remotecodeausführung ermöglichen können. Remotecodeausführung bedeutet, dass ein Angreifer über eine Anfrage Code auf einem Server ausführen kann. PHP bewertete beide Schwachstellen mit 9,2 nach CVSS 4.0.

  • CVE-2026-109618 betrifft die Speicherverwaltung: Bei einem Speichermangel kann PHP interne Anfragedaten nur teilweise initialisieren. Die anschließende Bereinigung kann diese Daten dennoch als gültig behandeln.
  • CVE-2026-109619 betrifft veraltete interne Zustände: Ein späterer Request desselben Workers kann auf Daten zugreifen, deren Speicher bereits freigegeben wurde.

Nach Angaben von PHP sind alle PHP-Installationen betroffen, die Webanfragen verarbeiten. Dazu zählen PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP stuft mod_php als besonders gefährdet ein, weil eine nicht authentisierte Anfrage den Fehler auslösen kann, bevor Anwendungscode läuft.

Die von PHP genannten korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Linux-Distributionen und Anbieter mit Langzeitunterstützung können Korrekturen zurückportieren und dabei andere Versionsnummern verwenden. PHP veröffentlichte außerdem minimale Quellcode-Backports für PHP 7.4, 8.0 und 8.1; diese PHP-Zweige erhalten vom PHP-Projekt keine regulären Updates mehr. Die offizielle PHP-Sicherheitsmeldung führt die betroffenen Integrationen und Korrekturen auf.

Was ein separates Honeypot-Netzwerk beobachtete

Telekom Security meldete für seine eigenen Sensoren vor dem Auftauchen der Advisories um 13:34 UTC am 21. Oktober keine exploitartigen Nutzlasten. Die ersten exploitähnlichen serialisierten Payloads registrierte das Unternehmen dort um 14:18 UTC. Diese Beobachtungen stammen aus einem anderen Sensornetz als AWS MadPot und betreffen einen anderen Zeitraum als den von AWS gemeldeten Versuch vom 17. Oktober.

Was PHP-Betreiber prüfen sollten

PHP nennt ein Update auf eine korrigierte Version die vollständige Behebung der Schwachstellen. Konfigurationsänderungen können laut PHP einzelne Angriffswege einschränken, ersetzen das Update aber nicht. Entscheidend ist deshalb, die installierte PHP-Laufzeit und die verwendete Webintegration zu prüfen; ein Update der Website oder des CMS allein ersetzt keine korrigierte PHP-Version.

AWS empfiehlt, POST-Anfragen mit PHP_SESSION_UPLOAD_PROGRESS zu untersuchen, Webserverprotokolle zu prüfen und nach unerwarteten Prozessen oder Dateiänderungen auf Webservern zu suchen. Die sechs von AWS genannten IP-Adressen umfassen gemeinsam genutzte Anonymisierungsinfrastruktur und sind nicht ausschließlich mit dieser Aktivität verbunden. AWS rät daher, Treffer zu untersuchen, statt die Adressen automatisch zu blockieren: 103.216.220.92 wurde am 17. Oktober beobachtet; 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188 und 95.217.98.37 am 21. Oktober.