PHP2Shell-Angriffe dauern an, keine bestätigten WordPress-Fälle
PHP2Shell-Exploit-Versuche dauern an, doch laut Wordfence waren bis zum 28. Oktober 2026 keine bestätigten Kompromittierungen von WordPress durch die beiden kritischen PHP-Schwachstellen bekannt. PHP ist die Programmiersprache, auf der WordPress läuft. Das Fehlen eines bestätigten Falls bedeutet nicht, dass ein ungepatchter Server sicher ist: Erforderlich sind die Installation von PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 beziehungsweise eines Anbieterpakets, das nachweislich beide Korrekturen enthält, und anschließend ein Neustart von PHP.
PHP2Shell ist der Spitzname für CVE-2026-109618 und CVE-2026-109619. Beide erhielten nach CVSS v4.0, einer Standardskala zur Bewertung des Schweregrads von Schwachstellen, 9,2 von 10 Punkten. Beide Schwachstellen können nicht authentifizierte remote code execution ermöglichen. Das bedeutet, dass jemand, der nicht angemeldet ist, möglicherweise eigenen Code auf dem Server ausführen kann. Eine Schwachstelle betrifft den Umgang von PHP mit einem Request, der den verfügbaren Speicher vollständig ausschöpft. Bei der anderen behält ein PHP-Prozess Daten aus einem abgeschlossenen Request bei, die ein späterer Request missbrauchen kann. Dies sind Schwachstellen in PHP selbst, nicht in WordPress, einem Theme oder einem Plugin.
Wordfence analysierte Logs von mehr als 5 Millionen geschützten Websites und erklärte, dass seine Teams für Website-Bereinigung und Incident Response keinen WordPress-Sicherheitsvorfall bearbeitet hätten, der einer der beiden Schwachstellen zugeschrieben wurde. Eine spezielle Überwachungsregel registrierte zwischen dem 23. und 27. Oktober etwa 77.600 zugehörige Requests von mehr als 2.000 IP-Adressen. Wordfence überprüfte jeden Treffer und fand Anzeichen für Angriffe, selbstidentifizierte Scanning-Tools oder andere automatisierte Tests statt normaler Besucher- oder Website-Aktivitäten. Das Unternehmen beobachtete außerdem am 22. Oktober 27 koordiniert handelnde IP-Adressen, von denen 26 ihre Requests innerhalb eines Zeitraums von 13 Minuten begannen.
Mit den Requests wurde versucht, Befehle auszuführen, die zeigen sollten, ob die Ausnutzung funktioniert hatte, Datenbankpasswörter und andere geheime Daten aus den Konfigurationsdateien wp-config.php und .env zu extrahieren und backdoors in Upload-, Plugin- oder Theme-Verzeichnissen anzulegen. Eine backdoor ist eine versteckte Datei oder ein verborgener Mechanismus, über den ein Eindringling später zurückkehren kann. Seltener wurde mit Requests versucht, weiteren Schadcode herunterzuladen und auszuführen. Diese Aufzeichnungen belegen die Absicht der Angreifer, nicht die erfolgreiche Ausführung. Amazon meldete ebenfalls Versuche gegen honeypots, also Täuschsysteme zur Beobachtung von Angriffen, und zwar noch vor der öffentlichen Bekanntgabe am 21. Oktober. Wordfence entdeckte etwa vier Stunden vor dieser Bekanntgabe Tools, die für die Schwachstellen entwickelt worden waren.
Berichte außerhalb von WordPress bleiben wichtig, enthalten jedoch ungeklärte Fragen. Dream erklärte, ein Angreifer habe PHP2Shell an eine nicht genannte firewall-Plattform angepasst und anschließend eine Schwachstelle zur privilege escalation im Linux-Kernel genutzt, um die vollständige Kontrolle über 24 mit dem Internet verbundene firewalls und einen internen Management-Server zu übernehmen. Laut Dream extrahierte der Angreifer das Passwort eines LDAP-Servicekontos, das für den Zugriff auf ein zentrales Benutzerverzeichnis verwendet wurde, und erfasste Benutzer und Gruppen in einer Umgebung mit Verbindungen zur US-Regierung. Der öffentliche Bericht nannte weder den Anbieter noch stellte er sichergestellte Artefakte bereit, und Wordfence erklärte, die Angaben nicht unabhängig verifiziert zu haben. Palo Alto Networks berichtete separat über aktive Exploit-Versuche gegen über das Internet erreichbare PAN-OS-Management-Interfaces, ohne diese Aktivitäten mit dem Bericht von Dream in Verbindung zu bringen.
Wiz berichtete am 27. Oktober, dass keiner der beobachteten Versuche erfolgreich abgeschlossen worden sei. Die stärksten öffentlich zugänglichen Belege, die das Unternehmen geprüft habe, beträfen die erfolgreiche Ausnutzung von honeypots. Am 28. Oktober meldete Morphisec code execution auf dem Windows-Server eines Kunden, auf dem IIS, Microsofts Webserver-Software, und PHP-CGI, eine Methode zur Ausführung von PHP für Web-Requests, eingesetzt wurden. Der öffentliche Bericht betraf weder WordPress noch enthielt er genügend technische Details, damit Wordfence unabhängig überprüfen konnte, ob PHP2Shell den Vorfall verursacht hatte.
Eine zuverlässige Ausnutzung scheint stark von der Konfiguration des Zielsystems abzuhängen. Wordfence stellte fest, dass ein Test-Exploit in einem speziell konfigurierten PHP-Build Code ausführte, während er einen normalen optimierten Build derselben Version lediglich zum Absturz brachte. Wiz meldete bei unterschiedlichen Serverkonfigurationen Fehlschläge in verschiedenen Phasen, während Hacktron feststellte, dass ein in einer Umgebung funktionierender Exploit für eine andere erheblich angepasst werden musste. Zu den Einflussfaktoren gehören der PHP-Build, installierte Extensions, Speicherlimits, die Request-Verarbeitung und ASLR, also Address Space Layout Randomization. Dabei wird verändert, wo ein Programm Daten im Speicher ablegt, damit ein Angreifer schwerer vorhersagen kann, welches Ziel er anvisieren muss. Unter Linux können Administratoren cat /proc/sys/kernel/randomize_va_space ausführen; das Ergebnis 2 zeigt eine vollständige Randomisierung an. Diese Hindernisse können eine breit angelegte Ausnutzung erschweren, ersetzen jedoch nicht das Patchen.
Laut dem PHP-Sicherheitshinweis ist jede PHP-Installation gefährdet, die Web-Requests verarbeitet, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Eine aktuelle WordPress-Installation kann daher weiterhin gefährdet sein, denn ein Update von WordPress aktualisiert PHP nicht. In WordPress zeigt Werkzeuge, Website-Zustand, Bericht, Server die Version an, die tatsächlich für die Website verwendet wird. Diese kann vom Ergebnis von php -v in einer Befehlszeile abweichen. Eine scheinbar ältere Version ist nicht immer ein eindeutiger Beleg, da Linux-Distributionen und Long-Term-Support-Anbieter mitunter Sicherheitskorrekturen hinzufügen, ohne die Hauptversionsnummer zu ändern. In diesem Fall muss der Hosting-Anbieter oder Hersteller bestätigen, dass sein Paket beide Korrekturen enthält.
Bei Managed Hosting oder Shared Hosting sollten Website-Betreiber nachfragen, ob der PHP-Dienst für ihr konkretes Konto gegen beide CVEs gepatcht und danach neu gestartet wurde. Administratoren eines eigenen Servers oder Virtual Private Servers, also einer gemieteten Serverumgebung, sollten zunächst ein Backup erstellen, die aktualisierten Pakete installieren und Apache, PHP-FPM oder den betreffenden PHP-Dienst neu starten, damit alte Prozesse keinen verwundbaren Code behalten. Container müssen auf Grundlage eines aktualisierten Images neu erstellt und bereitgestellt werden. Agenturen sollten öffentliche, Staging- und ältere Umgebungen prüfen, statt nur die Hauptwebsite zu untersuchen.
PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine Updates mehr. Benutzer benötigen daher entweder eine vom Anbieter bereitgestellte Korrektur oder ein Upgrade. Einige Linux-Distributionen und Long-Term-Support-Anbieter haben ältere Releases mit Korrekturen versehen, und das PHP-Sicherheitsteam veröffentlichte minimale Source-Patches für PHP 7.4, 8.0 und 8.1. Ein unterstütztes Release ist langfristig die bessere Wahl. PHP 8.2 erreicht am 31. Dezember 2026 sein End of Life, sodass mit PHP 8.3 oder neuer eine weitere kurzfristige Migration vermieden werden kann.
Website-Betreiber sollten in wp-content/uploads sowie in Plugin- oder Theme-Ordnern nach unbekannten PHP-Dateien suchen, insbesondere nach Dateien, die am oder nach dem 17. Oktober erstellt wurden. Weitere Warnzeichen sind unbekannte Administratorkonten, geänderte Konfigurationsdateien, unerwartete cron jobs, also automatisch nach einem Zeitplan ausgeführte Aufgaben, unerklärliche ausgehende Verbindungen, wiederholte PHP-Abstürze, ungewöhnlich große Formular-Uploads oder ein Webprozess, der eine Command Shell startet. Backups sowie Webserver-, PHP-, firewall- und System-Logs sollten mindestens für den Zeitraum vom 17. Oktober bis zum Neustart des gepatchten PHP-Dienstes aufbewahrt werden. Ein unauffälliges Log beweist nicht, dass nichts geschehen ist.
Wenn verdächtige Anzeichen auftauchen, sollte zunächst ein Backup des aktuellen Zustands der Website erstellt werden, um Beweismittel zu sichern.