Sophos analysierte eines der eingesetzten Schadprogramme und kam zu dem Schluss, es handle sich um eine aktualisierte und deutlich erweiterte Fassung der Anfang 2026 identifizierten Mirai-Abkömmlings-Botnetzvariante. Das Muster verfüge über Downloader- und Netzwerkstörungsfunktionen. Es löst eine fest einprogrammierte, verschlüsselte Command-and-Control-Adresse auf, baut eine TCP-Verbindung zu 134.199.154[.]64 auf und sendet eine HTTP-Anfrage. Anschließend prüft es auf den Statuscode HTTP 200 und darauf, ob die empfangene Nutzlast mit den ELF-Magic-Bytes 7F 45 4C 46 beginnt – erwartet wird also eine Linux-ELF-Binärdatei als Folgenutzlast.

Eine Auflösungsfunktion unterstützt laut Sophos IPv4-Adressen und Hostnamen, ergänzt um eine Rückfall-Logik mit fest hinterlegten öffentlichen DNS-Servern wie 8.8.8.8, 1.1.1.1 und 1.0.0.1. Wie bei Mirai üblich kann das Muster DDoS-Angriffe ausführen.

Die Angriffe gingen von drei IP-Adressen aus:

  • 85.11.167[.]243
  • 217.60.242[.]76
  • 45.198.224[.]169

Diese Quellen kontaktieren 92.118.112[.]100, um einen Loader zu beziehen, der das Botnetz ausbringt. In einer netzwerkisolierten Sandbox zeigte sich, dass das Botnetz eine DNS-Abfrage für thunder.godofthunder[.]st stellt, diese zu 134.199.154[.]64 auflöst und einen C2-Kanal auf TCP-Port 50792 aufbaut. Ziel sind anhaltende volumetrische Flood-Angriffe gegen zwei benachbarte Hosts in einem einzigen ukrainischen Netz: 45.88.138[.]0 und 45.88.138[.]44. Das Ausbleiben erfolgreicher Angriffe über PHP2Shell deutet nach Einschätzung von Sophos darauf hin, dass die Akteure sich mit zuverlässigen Exploits schwertun.

Potassium wurde erstmals im März 2026 von der Botnetz-Beobachtungsplattform Synthient erfasst. In einer Folgeanalyse beschrieben Forscher von Nokia Deepfield die Schadsoftware als Mirai-Fork, der ChaCha20 für die statische Konfigurationstabelle nutzt – nach ihren Angaben der erste beobachtete Einsatz von ChaCha20 in dieser Form in einer Mirai-Variante –, dazu ein einzelnes statisches Byte (0xED) für alles auf der Leitung, ein benanntes Reverse-Shell-Protokoll (SHELL / SHOUT) auf demselben Kanal wie die Angriffsbefehle sowie ein DNS-Täuschungsverfahren, das die beiden 16-Bit-Hälften jedes aufgelösten A-Records vor dem connect() vertauscht.

Arctic Wolf, das denselben Ausnutzungsversuch ebenfalls dokumentierte, zählte 24 unterstützte Befehle für Flood-Angriffe über ICMP, TCP, UDP und das OpenVPN-Protokoll. Sowohl die ARM- als auch die x86-Builds enthalten eine Konfiguration zur Auflösung der C2-Infrastruktur über den Ethereum Name Service (ENS). “Die ENS-Auflösung war in beiden Mustern deaktiviert, was darauf hindeutet, dass die Fähigkeit vorhanden, aber inaktiv war”, so das Unternehmen. Würde sie in künftigen Varianten aktiviert, könnte dies eine Abschaltung erschweren, da die Abhängigkeit von Registraren und DNS-Anbietern sinkt und Verteidiger ENS-Namen, RPC-Infrastruktur und die aufgelösten C2-Adressen blockieren müssten.

SOCRadar fand auf einem offen zugänglichen, vom Angreifer kontrollierten Server (206.188.197[.]105:9999) PHP2Shell-Exploit-Werkzeuge für PHP 8.4.26 sowie drei Prüfskripte, die Live-Websites auf die Voraussetzungen der PHP2Shell-Kette testen. Die Skripte prüften rund 20 öffentliche Websites auf PHP-Version, Server-Konfiguration und Session-Einstellungen; die Seiten verteilen sich auf Kanada, China, Finnland, Frankreich, Polen, das Vereinigte Königreich und die USA.

“Die zentrale Datei, aslr_exploit.py, ist ein Python-Exploit, den der Betreiber als ‘Ein-Klick’-PHP2Shell-Exploit für PHP 8.4.26 unter Apache mod_php bezeichnet”, erklärte SOCRadar. Er arbeite vollständig über gewöhnliche HTTP-Anfragen in drei groben Schritten: Er erneuert den PHP-Worker des Ziels, leckt über das Session-Cookie Speicheradressen, um die Adressraum-Zufallsanordnung (ASLR) auszuhebeln, und missbraucht anschließend PHPs Behandlung des Session-Upload-Fortschritts, um einen Shell-Befehl auszuführen. ASLR randomisiert die Speicherorte von Systemdateien und Programmen bei jedem Start und erschwert so Angreifern die Vorhersage, wo Code geladen wird; der Mechanismus schützt gegen speicherbasierte Angriffe wie Pufferüberläufe.

Die drei Begleitskripte:

  • php2shell_fp.py liest PHP-Version und Server-Konfiguration von rund 20 Seiten aus
  • deep_probe.py untersucht 11 dieser Seiten auf sichtbare Fehlermeldungen, phpinfo-Seiten, File Inclusion und Session Injection, um die Exploit-Voraussetzungen zu prüfen
  • wp_attack.py nimmt fünf WordPress-Seiten ins Visier und zählt Benutzer und Plugins auf

Belege für Shell-Zugriff auf einer der geprüften Seiten gab es mit Stand 22. Oktober 2026 nicht; die Ziele erfüllten die Voraussetzungen des Exploits offenbar nicht. Das Werkzeugset gehört nach Einschätzung von SOCRadar zu einer größeren Operation, bei der der Angreifer API-Schlüssel und Backend-URLs aus clientseitigem JavaScript von Websites extrahiert, systematisch Web- und API-Routen auf unauthentifizierten Zugang abklopft und einen Pool rotierender Proxys nutzt, um den Verkehr zu streuen und Ratenbegrenzungen sowie Sperren zu umgehen. Weitere Artefakte auf dem Server deuten laut SOCRadar auf Aufklärung über Webarchive und automatisiertes Lösen von CAPTCHAs hin. In der Gesamtschau verweise das Werkzeugset auf einen finanziell motivierten Akteur mit Fokus auf Kryptowährungs- und Web3-Ziele.

Denselben Server hat auch Hunt.io erfasst. Demnach nahm der dahinterstehende Akteur 123 Server in Cloud-, Shared-Hosting- und ISP-Netzen ins Visier. “Etwa 57 laufen mit PHP, viele davon auf nicht mehr unterstützten 5.x- bis 7.x-Versionen”, so das Unternehmen. Zehn wiesen die Anfrage direkt ab, darunter drei der fünf hinter Cloudflare liegenden Systeme. Keines wurde erfolgreich kompromittiert. Insgesamt beherbergen zehn offene Verzeichnisse PHP2Shell-Werkzeuge:

  • 206.188.197[.]105
  • 102.210.149[.]166
  • 122.10.110[.]72, 122.10.17[.]49
  • 58.221.60[.]160:8000
  • 41.223.30[.]7, 157.230.117[.]70
  • 104.219.251[.]31
  • 107.150.31[.]151
  • 217.160.132[.]82
  • 47.100.125[.]108, 54.169.109[.]7, 139.162.165[.]136

Parallel dazu hat VulnCheck einen Exploit entwickelt, der auf ASLR-geschützten x86-64-Systemen mit der von PHP empfohlenen Produktionskonfiguration Codeausführung erreicht. “Eines der größten Hindernisse war die Adressraum-Zufallsanordnung (ASLR), ein Schutz, der die Ausnutzung von Speicherfehlern deutlich erschweren soll”, sagte Spencer McIntyre, Director of Exploit Development bei VulnCheck. “Unser Team hat eine neuartige Technik entwickelt, die die beiden Schwachstellen verkettet und über ein Speicherleck ASLR umgeht, um auf x86-64-Systemen Codeausführung zu erreichen – selbst mit der von PHP empfohlenen Einstellung zur Fehleranzeige im Produktivbetrieb.” Man habe keinen anderen öffentlichen oder kommerziellen Exploit gefunden, der dies unter denselben Bedingungen schafft; die Entwicklung sei alles andere als trivial gewesen, zeige aber, dass eine wesentliche Hürde überwindbar sei.

Die Folgen einer erfolgreichen Ausnutzung sind laut VulnCheck gravierend: Angreifer können Code mit den Rechten der Webanwendung ausführen und so an API-Schlüssel, Datenbankverbindungen und weitere interne Dienste gelangen, die die Anwendung erreicht. “Ein Angreifer braucht nicht zwingend Administrator- oder Root-Rechte, um erheblichen Schaden anzurichten”, sagte McIntyre. “Der Zugriff auf eine verwundbare Webanwendung kann ein Einfallstor in andere Teile der Infrastruktur einer Organisation sein.”

Zu den beobachteten Versuchen zählt auch eine in China verortete IP-Adresse, die eine Web-Shell über eine serverseitige Session-Datei abzulegen versuchte. Cloudflare registrierte 45 Minuten nach der öffentlichen Bekanntgabe Zehntausende Ausnutzungsversuche, innerhalb von zwei Stunden Hunderttausende und bis zum frühen 22. Oktober 2026 Millionen. “Bislang handelt es sich überwiegend um Scanning, dazu einige unkoordinierte Versuche, verschiedene Nutzlasten auszuliefern”, so Cisco Talos. “Das ist zu erwarten: Scannen oder einfache Ausnutzung mit öffentlichem Proof-of-Concept-Code kostet deutlich weniger Aufwand, als eine Schwachstelle in das eigene Werkzeugset zu integrieren.”

Die Telemetrie von Previdian verzeichnete bislang Hunderte Ausnutzungsversuche gegen CVE-2026-109618 von Dutzenden IP-Adressen und in geringerem Umfang gegen CVE-2026-109619. Das erste Exploit-Ereignis gegen CVE-2026-109618 wurde am 21. Oktober 2026 um 13:05 Uhr UTC erfasst. “Wir haben in unseren Honeypots zahlreiche PHP2Shell-Sondierungen und Ausnutzungsversuche gesehen”, so Previdian. “Zum Zeitpunkt der Erstellung haben wir keine erfolgreiche Codeausführung und keine abgelegten PHP-Dateien beobachtet. Zuverlässige RCE ist womöglich schwerer zu erreichen als zunächst erwartet.”

Diese Einschätzung teilen auch Beelzebub, Dataminr und Wordfence. Die beobachtete Aktivität beschränkt sich bislang auf Scanning, Fingerprinting sowie Versuche, Befehlsausführung zu bestätigen, Zugangsdaten und Geheimnisse aus Umgebungsvariablen zu stehlen, dauerhaften Zugang einzurichten und eine Zweitstufen-Nutzlast nachzuladen und auszuführen. Wordfence nennt unter anderem folgende angreifende IP-Adressen:

  • 87.121.84[.]174
  • 181.215.186[.]252
  • 185.196.220[.]132
  • 185.161.210[.]29
  • 152.233.51[.]69
  • 45.134.225[.]16
  • 107.189.14[.]87
  • 193.47.62[.]24
  • 2409:40d2:204e:4be:2a1f:f9c9:a055:e00b
  • 103.147.220[.]17

Wegen der Schwere der Lücken gingen in Asien, Europa und Nordamerika vorsorglich mehrere Websites von Behörden, Schulen und Krankenhäusern vom Netz. Die britische Regierung bestätigte, dass 32 digitale Dienste nicht und vier teilweise nicht verfügbar sind – überwiegend infolge vorsorglicher Abschaltungen, während Sicherheitsupdates und Gegenmaßnahmen eingespielt wurden. Das National Cyber Security Centre (NCSC) verschickte rund 50.000 Warnungen an Unternehmen und andere Organisationen.

“Der verwundbare Code reicht bis PHP 5.4 aus dem Jahr 2012 zurück”, erklärte das Sysdig Threat Research Team. “Die Fehler stecken in der PHP-Engine, nicht in einer Anwendung. Deshalb ist jede WordPress-, Drupal- oder Joomla-Seite auch mit sauberem Anwendungscode weiterhin angreifbar.”

Da für ältere PHP-Versionen keine Korrekturen bereitstehen, dürfte PHP2Shell ähnlich wie Log4Shell einen langen Nachlauf haben. Nach Schätzungen des zu Google gehörenden Dienstes VirusTotal laufen rund 272.000 Hosts auf einem unterstützten PHP-Zweig (8.2 bis 8.5). Organisationen mit PHP 7.4, 8.0 oder 8.1 wird geraten, auf einen unterstützten Zweig zu wechseln oder einen Distributions-Backport einzusetzen.

Die Angriffsflächen-Plattform Censys erfasst derzeit über 3,08 Millionen Hosts und 56,6 Millionen Web-Properties mit PHP; davon gelten mit Stand 23. Oktober 2026 mehr als 34,4 Millionen PHP-Dienste weiterhin als verwundbar. “Viele Anwendungen mit Webservern und Ähnlichem werden wahrscheinlich verwundbar bleiben, bis die jeweiligen Hersteller diese Komponenten patchen”, so Dataminr. Damit blieben viele Organisationen deutlich länger angreifbar, als wenn Patches direkt auf eigene, selbst verwaltete Anwendungen angewendet würden.