PHP2Shell — Millionen Exploit-Versuche von CVE-2026-109618 und CVE-2026-109619 haben bislang zu keinen bestätigten Kompromittierungen geführt

Zwei kritische Schwachstellen im PHP-Kern — CVE-2026-109618 und CVE-2026-109619 (CVSS v4.0 9.2) — lösten innerhalb von Stunden nach der Offenlegung am 21. Oktober 2026 eine Welle von Scans und Exploit-Versuchen aus. Die Schwachstellen ermöglichen nicht authentifizierte Remote Code Execution über speziell gestaltete HTTP-Anfragen und betreffen alle PHP-Versionen vor 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Nach Angaben mehrerer unabhängiger Forschungsgruppen — Sophos, Arctic Wolf und Hunt.io — hat keiner der beobachteten Versuche zu einer bestätigten Kompromittierung geführt. Wir haben bereits über die technischen Details dieser Schwachstellen und Schutzmaßnahmen geschrieben; dieses Material konzentriert sich auf die Analyse der realen Aktivitäten der Angreifer und die Gründe, warum die Ausnutzung schwieriger ist als erwartet.

Art der Schwachstellen und Größe der Angriffsfläche

Laut dem Sicherheitshinweis von CERT/CC (VU#763488) handelt es sich bei CVE-2026-109618 um eine Schwachstelle zur Speicherbeschädigung im PHP-Mechanismus zur Behandlung von Speichermangel (OOM): Unter bestimmten Bedingungen können teilweise initialisierte Anfragedaten während der Speicherbereinigung verfügbar sein. CVE-2026-109619 ist eine Use-after-free-Schwachstelle, bei der veralteter globaler Zustand, der zu einer Anfrage gehört, von der nachfolgenden Anfrage desselben Workers erneut verwendet wird.

Der verwundbare Code ist seit PHP-Version 5.4 (2012) vorhanden, was bedeutet, dass das Problem nicht eine konkrete Anwendung betrifft, sondern die PHP-Engine selbst. Jede Website auf WordPress, Drupal oder Joomla mit sauberem Anwendungscode bleibt verwundbar, solange PHP nicht aktualisiert ist. Betroffen sind Konfigurationen von PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Nach Angaben von CERT/CC stellt Apache mod_php das größte Risiko dar, da die Ausnutzung erfolgen kann, bevor Anwendungscode ausgeführt wird.

Nach Schätzungen von Censys waren zum 23. Oktober 2026 mehr als 34,4 Millionen PHP-Services von insgesamt über 56,6 Millionen Webauftritten, die PHP nutzen, potenziell verwundbar. Organisationen mit PHP 7.4, 8.0 oder 8.1 erhalten keine offiziellen Sicherheitsupdates mehr vom PHP Project und sind auf Backports der Distributionen oder eine Migration auf einen unterstützten Zweig angewiesen.

Aktivität der Angreifer: viel Lärm, null Ergebnisse

Großangelegte Scans und Exploit-Versuche begannen innerhalb von 45 Minuten nach der öffentlichen Offenlegung der Schwachstellen. Nach Angaben von Arctic Wolf reichte die beobachtete Aktivität von einfachen Prüfungen auf verwundbares Verhalten des Mechanismus zur Nachverfolgung des Upload-Fortschritts von PHP-Sessions bis hin zu Versuchen, die Ausführung von Betriebssystembefehlen zu verifizieren.

Ein grundsätzlich wichtiger Punkt: Sophos meldete zunächst eine erfolgreiche Ausnutzung von PHP2Shell bei seinen Kunden, korrigierte diese Einschätzung aber später und gab an, dass die Telemetrie nur Scans und fehlgeschlagene Versuche ohne Nachweis einer erfolgreichen Kompromittierung gezeigt habe. Hunt.io bestätigte dieses Ergebnis unabhängig: Der einzige erkannte Betreiber einer Massen-Exploitation führte zehn Durchläufe über 123 Server aus und bekam keinen einzigen Shell-Zugriff. Dasselbe Bild beobachten Wordfence, Previdian, Beelzebub und Dataminr.

Der Hauptgrund für das Scheitern der Angreifer ist die Notwendigkeit, ASLR (Address Space Layout Randomization) zu umgehen – einen Mechanismus zur Randomisierung des Adressraums, der die Speicherlage von Code unvorhersehbar macht. VulnCheck hat eine Methode entwickelt, die beide Schwachstellen kettet, um ASLR auf x86-64-Systemen mit empfohlenen Produktionseinstellungen von PHP zu umgehen, betonte jedoch, dass die Erstellung eines solchen Exploits „weit davon entfernt ist, trivial zu sein“. Das erklärt die Diskrepanz zwischen umfangreichen Scans und dem Ausbleiben erfolgreicher Angriffe.

Der Botnet Potassium und die Angreiferinfrastruktur

Der beobachtete Exploit-Traffic steht im Zusammenhang mit Potassium — einer Mirai-Variante des Botnets, die von der Plattform Synthient erstmals im März 2026 erfasst wurde. Der Zusammenhang wurde auf Ebene der Infrastruktur und der Malware-Samples von drei unabhängigen Forschungsgruppen (Sophos, Arctic Wolf, Hunt.io) hergestellt; ein konkret verantwortlicher Angreifer wurde jedoch nicht identifiziert. Wichtig ist: Die Beweise verknüpfen PHP2Shell-Anfragen mit der Potassium-Infrastruktur, bestätigen aber nicht, dass die zugehörigen Samples über diese Schwachstellen heruntergeladen und ausgeführt wurden.

Nach Angaben von Sophos stellt ein Potassium-Sample eine TCP-Verbindung zum C2-Server 134.199.154[.]64 her, sendet eine HTTP-Anfrage und erwartet als Antwort ein Linux-ELF-Binary. Der Botnet unterstützt 24 Befehle für DDoS-Angriffe über die Protokolle ICMP, TCP, UDP und OpenVPN. Zu den technischen Besonderheiten gehören die Verwendung von ChaCha20 zur Verschlüsselung der statischen Konfigurationstabelle (erstmals für Mirai-Varianten), ein DNS-Umschalt-Schema mit Vertauschung der beiden 16-Bit-Hälften jedes A-Records sowie eine inaktive, aber integrierte Unterstützung für die Auflösung der C2-Infrastruktur über den Ethereum Name Service (ENS).

SOCRadar entdeckte darüber hinaus auf einem offenen Server des Angreifers (206.188.197[.]105:9999) ein Set an Werkzeugen zur Ausnutzung von PHP2Shell, darunter das Skript aslr_exploit.py — einen Exploit für PHP 8.4.26 unter Apache mod_php, der in drei Phasen arbeitet: Neustart des PHP-Workers, Abgriff von Speicheradressen über ein Session-Cookie zum Umgehen von ASLR und Missbrauch des Mechanismus zur Nachverfolgung des Upload-Fortschritts von Sessions zur Ausführung eines Befehls.

Indikatoren einer Kompromittierung

Wichtige IOC aus den Untersuchungen:

• IP-Adressen der Angriffsquellen: 85.11.167[.]243, 217.60.242[.]76, 45.198.224[.]169
• Download-Infrastruktur: 92.118.112[.]100, 206.188.197[.]105
• C2-Server: 134.199.154[.]64 (TCP-Port 50792)
• Domains: thunder[.]godofthunder[.]st, hackattackkaboom[.]botlesscucks[.]st
• Sample-Hashes: 0c5486f06620e26e316f4b33f318b0d646d5e1133789331aa2fed012360d1486, e2529d4afa39ae4db2eb05d5176317c906289abf09660c75bdeec43e54c55aa3

Praktische Erkennung von Exploit-Versuchen

Nach Angaben von Hunt.io und Arctic Wolf sollte man zur Unterscheidung von Scan-Versuchen und einer tatsächlichen Kompromittierung mehrere Signale korrelieren:

• User-Agent mit Zeichenketten wie php2shell-scan/109618 oder php2shell-109618
• Multipart-POST-Anfragen mit dem Feld PHP_SESSION_UPLOAD_PROGRESS und einem ungewöhnlich großen Body
• Spitzen bei „Allowed memory size exhausted“-Fehlern in den PHP-FPM-Logs
• Anschließende Aktivitäten: Prozess­erzeugung, Änderungen im Root-Verzeichnis des Webservers, ausgehende Netzwerkverbindungen zu den genannten C2-Adressen

Das Vorhandensein der ersten drei Anzeichen weist auf einen Exploit-Versuch hin; das vierte auf eine mögliche Kompromittierung, die eine sofortige Untersuchung erfordert.

Empfehlungen

• Aktualisieren Sie PHP umgehend auf die Versionen 8.2.35, 8.3.36, 8.4.27 oder 8.5.12, wie von CERT/CC empfohlen
• Organisationen mit PHP 8.1 und älter erhalten keine Updates mehr vom PHP Project — erforderlich sind eine Migration auf einen unterstützten Zweig oder Backports durch die Distribution
• Prüfen Sie die Webserver-Logs auf die genannten IOC und Exploit-Muster
• Blockieren Sie Netzwerkverbindungen zu den angegebenen C2-Adressen und Domains auf Perimeter-Ebene
• Ziehen Sie für Apache-mod_php-Konfigurationen einen temporären Wechsel zu PHP-FPM in Betracht, das zusätzliche Prozessisolierung bietet

Die aktuelle Situation mit PHP2Shell erinnert an die frühen Tage von Log4Shell: Verwundbarer Code existiert seit über zehn Jahren, betrifft die Engine und nicht die Anwendung und es gibt keine Patches für veraltete Zweige. Das Fehlen bestätigter Kompromittierungen ist derzeit eine Folge der technischen Komplexität beim Umgehen von ASLR, nicht der Sicherheit der verwundbaren Systeme. VulnCheck hat bereits demonstriert, dass diese Hürde überwindbar ist. Priorität für jede Organisation, die PHP einsetzt, ist ein Update auf eine fehlerbereinigte Version, bevor zuverlässige Exploits einem größeren Kreis von Angreifern zur Verfügung stehen.