Mehr als 74.000 PHP2Shell-Versuche ohne bestätigte Kompromittierung
PHP2Shell-Angriffe haben laut Wordfence zu mehr als 74.000 Exploit- oder reconnaissance-Versuchen geführt, obwohl das Unternehmen nicht bestätigt hat, dass eine Website über die beiden zugrunde liegenden PHP-Sicherheitslücken kompromittiert wurde. Das PHP-Projekt veröffentlichte am 21. Oktober 2026 Notfallupdates für die kritischen Sicherheitslücken CVE-2026-109618 und CVE-2026-109619. Wordfence stützt seine Einschätzung auf Telemetriedaten von mehr als 5.000.000 geschützten WordPress-Websites und gibt an, seine Überwachung auszuweiten. Zur Behebung sind PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder ein Anbieterpaket erforderlich, für das ausdrücklich bestätigt wurde, dass es beide Korrekturen enthält. Administratoren müssen anschließend jeden PHP worker neu starten, also jeden laufenden Prozess, der Websiteanfragen verarbeitet. Ein Update von WordPress aktualisiert nicht automatisch die separate PHP-Software, die im Hintergrund ausgeführt wird.
Ein großer Angriffscluster sendete multipart/form-data-Anfragen, also Anfragen in einem Webformat, das einen Upload in mehrere benannte Abschnitte unterteilt. Die Anfragen enthielten einen Session-Identifier, die Funktion PHP_SESSION_UPLOAD_PROGRESS und wiederholte Felder mit den Namen t[0] bis mindestens t[136]. Wordfence ließ bei der Veröffentlichung seines Beispiels 134 dieser Felder aus. Ihre wiederholten Daten schienen darauf ausgelegt zu sein, den Speicher unter Druck zu setzen und zu beeinflussen, wie PHP die Anfrage im Speicher ablegte. Eingebettete Zeichenfolgen enthielten den Marker P2S_OK für command execution, den Namen der Funktion system sowie Befehle, die Serverdetails ausgeben und die ersten 200 Byte von .env, ../.env, ../../.env und wp-config.php lesen sollten. Diese Dateien können environment variables enthalten, also einer Anwendung bereitgestellte Konfigurationswerte, sowie Datenbankzugangsdaten und andere Geheimnisse. Die Anfrage belegt eine entsprechende Absicht, kann für sich genommen jedoch nicht zeigen, dass Speicher beschädigt oder ein Befehl erfolgreich ausgeführt wurde.
Wordfence untersuchte außerdem 10.000 Ereignisse, die vom 20. bis zum 22. Oktober erfasst wurden. Die Stichprobe wurde bewusst anhand von Anfragen ausgewählt, in denen PHP_SESSION_UPLOAD_PROGRESS erwähnt wurde, und ist daher nicht repräsentativ für den gesamten schädlichen Webverkehr. Sie enthielt 3.752 mutmaßliche PHP2Shell-Versuche, durch memory pressure oder state corruption command execution und den Diebstahl von Konfigurationsdaten zu erreichen. Weitere 1.139 verwendeten Laravel serialized-object gadget chains, also Abfolgen, die versuchen, bereits in einer Anwendung installierte Klassen zur Ausführung eines shell command zu missbrauchen. Weitere 2.534 versuchten es mit serialized objects, die mit Monolog, Symfony, Guzzle, WordPress, ThinkPHP und anderen Klassen in Verbindung stehen. Diese Kategorien beschreiben Merkmale der Payloads und können sich überschneiden.
Dieselbe Stichprobe umfasste 512 Versuche mit NxSP session-file poisoning. Dabei wird versucht, schädliche Inhalte in einer temporären Session-Datei abzulegen und dies mit einem separaten local-file-inclusion flaw zu kombinieren, also einer Schwachstelle, durch die eine Anwendung eine lokale Datei laden kann, die sie nicht zugänglich machen sollte. Dreißig Anfragen enthielten out-of-band PHP upload canaries, also Tests, die auf einen separaten Internet-Callback warten, um festzustellen, ob eine andere Upload- oder Ausführungsmethode funktioniert hat. Wordfence weist darauf hin, dass der NxSP- und canary-Verkehr denselben multipart- oder upload-progress-Bereich nutzt, jedoch von separaten Sicherheitslücken oder dem Verhalten einer Anwendung abhängt. Er sollte daher nicht als bestätigte Ausnutzung einer der beiden neuen CVE behandelt werden. Der Datensatz enthält Anfragen und keine Antworten oder direkten Belege von den angegriffenen Servern. Daher erfasst jede Zahl Versuche und keine erfolgreichen Einbrüche.
In den beobachteten Payloads versuchten Angreifer, eine erfolgreiche Ausführung mit P2S_OK, NxSP gefolgt von Ziffern sowie SHL_OK zu bestätigen. Befehle wie id, uname -a und hostname sollten ein Profil des Servers erstellen. Andere Aktionen zielten auf Geheimnisse in environment variables, .env und wp-config.php, durchsuchten gängige Verzeichnisse von Content-Management-Systemen und versuchten, persistente Befehlsdateien mit dem Namen wp2s.php in beschreibbaren Upload-, Plugin- oder Theme-Speicherorten anzulegen. Einige Anfragen versuchten, mit curl, wget und einem shell interpreter eine weitere Payload herunterzuladen und auszuführen. Andere verwendeten eindeutige Hostnamen unter oast.pro, oast.fun und oast.online für einen out-of-band callback, also eine Verbindung vom angegriffenen Server zu einem externen Dienst. Zu den weiteren Indikatoren für die Abwehr gehören ADV618BOUNDARY, ----P2SB, php2shell.php, axiom_*.php sowie die Klassennamen Illuminate\Broadcasting\PendingBroadcast, Monolog\Handler\BufferHandler und Requests_Utility_FilteredIterator.
Die 20 aktivsten Quelladressen waren 87.121.84.174 mit 8.525 blockierten Versuchen, 181.215.186.252 mit 7.856, 185.196.220.132 mit 7.146, 185.161.210.29 mit 5.796, 152.233.51.69 mit 5.317, 45.134.225.16 mit 3.623, 107.189.14.87 mit 2.365, 193.47.62.24 mit 2.263, 2409:40d2:204e:4be:2a1f:f9c9:a055:e00b mit 1.953 und 103.147.220.17 mit 1.860. Die übrigen Adressen waren 143.246.223.124 mit 1.791, 52.74.54.75 mit 1.260, 65.49.200.56 mit 836, 193.142.147.111 mit 775, 85.137.56.188 mit 672, 85.137.53.26 mit 664, 167.254.242.130 mit 648, 217.112.152.168 mit 619, 203.78.119.133 mit 616 und 140.245.32.169 mit 616.
Ob eine Ausnutzung funktioniert, hängt weiterhin von der PHP-Konfiguration, der Server Application Programming Interface (SAPI), die PHP mit dem Webserver verbindet, den installierten Erweiterungen, den verfügbaren Anwendungsklassen und dem aktuellen Zustand eines PHP worker ab. Wordfence hatte zuvor beim Testen von CVE-2026-109619 in einem speziell konfigurierten Apache-Labor mit PHP 8.5.11 code execution erreicht. Derselbe proof of concept brachte dagegen einen normal optimierten Build von PHP 8.5.11 zum Absturz, während PHP 8.5.12 stabil blieb. Bei CVE-2026-109618 konnte Wordfence in seinen Tests unterschiedliches Verhalten zwischen anfälligen und korrigierten Versionen reproduzieren, erreichte jedoch nicht unabhängig davon code execution. Der neu analysierte Produktionsverkehr ändert weder diese Laborergebnisse noch belegt er einen erfolgreichen Exploit unter realen Bedingungen.
Die Bestätigung einer Kompromittierung würde Belege aus Antworten, Dateien, Prozessen, abgestürzten PHP worker, Domain Name System-Anfragen oder ausgehenden Webverbindungen auf dem angegriffenen Server erfordern. Wordfence betont, dass ein ungepatchtes System durch das Fehlen einer solchen Bestätigung in seinen Telemetriedaten nicht sicher wird, da Fehler und Callbacks außerhalb von WordPress und dessen Logs auftreten können. Websitebetreiber, die eine Kompromittierung vermuten, sollten relevante Beweise aufbewahren; Wordfence bat außerdem um Einsendungen an samples@wordfence.com. Kunden von Wordfence Care und Wordfence Response können das Incident-Response-Team des Unternehmens kontaktieren. Nach Angaben des Unternehmens ist Response rund um die Uhr an 365 Tagen im Jahr verfügbar und reagiert innerhalb einer Stunde. Für Websitebetreiber, die prüfen, wie die Hosting-Ebene in ihr Schutzkonzept passt, bietet AEU Hosting vollständig abgesichertes Managed WordPress Hosting. Unabhängig vom Hosting-Modell besteht die unmittelbare Aufgabe darin, den PHP-Dienst hinter jeder Website zu überprüfen, eine Version mit beiden Korrekturen zu installieren und die zugehörigen PHP worker neu zu starten.