Angriffe auf WordPress CVE-2026-87902 erreichen Codeausführung
WordPress CVE-2026-87902, eine kritische Schwachstelle in WordPress Core, wird laut Patchstack inzwischen aktiv über einfache Sondierungen hinaus ausgenutzt. Die Schwachstelle betrifft WordPress-Versionen von 4.7.0 bis 7.1.1 und wurde in WordPress 7.1.2 behoben; gepatchte Versionen werden außerdem als 7.0.6, 6.9.9, 6.8.10 sowie als Backports bis zurück zu 4.7.37 aufgeführt. Patchstack meldet einen CVSS-Wert von 9.2, womit die Schwachstelle in den kritischen Bereich fällt, und gibt an, dass für die Ausnutzung keine Anmeldung erforderlich ist.
Das Problem ist ein path traversal, der zu local file inclusion und bedingter remote code execution führt. Path traversal bedeutet, dass ein Angreifer versucht, eine Website dazu zu bringen, Dateien außerhalb des Ordners zu öffnen, den sie eigentlich verwenden sollte. Local file inclusion bedeutet, dass die Website dazu gebracht wird, eine Datei zu laden, die bereits auf dem Server vorhanden ist. Remote code execution, oft zu RCE abgekürzt, bedeutet, dass ein Angreifer den Server dazu bringen kann, seine Befehle oder seinen Code auszuführen. In diesem Fall liegt die Schwachstelle laut Patchstack in der Auflösung von WordPress-Seitenvorlagen, und der erste beobachtete Ausnutzungsversuch traf am 22. September 2026 um 11:49 UTC ein, am selben Tag, an dem WordPress 7.1.2 veröffentlicht wurde.
Patchstack zufolge änderte sich die Kampagne schnell. Zunächst waren die Anfragen Aufklärung gegen harmlose WordPress-Core-Dateien, das heißt, die Angreifer prüften, ob Websites verwundbar waren. Bis zum 23. September war das Verkehrsaufkommen auf mehr als das Zehnfache des Niveaus des ersten Abends angewachsen, hatte eine größere Streuung von Websites erreicht und sich durch drei Phasen bewegt: prüfen, ob die Einbindung funktionierte, prüfen, ob PEARs pearcmd.php erreichbar war, und anschließend versuchen, Dateien auf die Festplatte zu schreiben.
In der ersten Phase wurde die verwundbare Vorlageneinbindung auf gewöhnliche Core-Dateien gerichtet. Laut Patchstack blieb wp-links-opml.php das häufigste Ziel; wp-includes/feed-rss2.php trat ebenfalls in größerem Umfang auf, zusammen mit wp-cron.php, wp-includes/functions.php, wp-login.php und install.php. Eine erfolgreiche Antwort von einer dieser Dateien sagt einem Angreifer, dass der verwundbare Codepfad erreichbar ist.
Die zweite Phase zielte auf PEARs pearcmd.php. PEAR ist ein PHP-Paketsystem, und pearcmd.php ist ein damit verbundenes Befehlsskript. Patchstack zufolge verwendeten Angreifer Anfragen mit einer gültigen page_id, einem pagename-Wert mit Traversal-Codierung und +config-show in der Abfragezeichenfolge. Wenn PHP mit aktiviertem register_argc_argv läuft, kann die Abfragezeichenfolge dem eingebundenen Skript als Befehlszeilen-ähnliche Argumente zugänglich gemacht werden, sodass +config-show an pearcmd übergeben wird. Das bestätigt sowohl, dass PEAR auf dem Host existiert, als auch, dass der Argument-Trick funktioniert. Patchstack sagt, dass Angreifer drei Speicherorte versuchten: /usr/local/lib/php/pearcmd.php, /usr/share/php/pearcmd.php und /usr/share/pear/pearcmd.php.
In der dritten Phase wurde config-show durch config-create ersetzt. Laut Patchstack kann pearcmd damit eine Datei an einen vorgegebenen Ort schreiben, mit von Angreifern kontrolliertem Inhalt. Die beobachteten Anfragen versuchten, PHP-Dateien zu schreiben, wodurch das Problem bei erfolgreicher Kette zu Codeausführung wird. Patchstack beschreibt zwei große Gruppen von Payloads: Einige schreiben Markierungszeichenfolgen wie CVE-2026-87902-POC-OK oder ein verschleiertes LUCIFER-RCE-OK, das aus chr()-Aufrufen aufgebaut wird, ein Verhalten, das zum Erstellen von Listen verwundbarer Hosts passt; andere schreiben ein kurzes PHP-Tag, das beim Aufruf einen Shell-Befehl ausführt. Patchstack erklärt, dass die zweite Gruppe keine Forschung ist.
Die von Patchstack gesehenen Dateien wurden in /tmp und /var/tmp abgelegt. Zu den Dateinamen gehörten wp-pear-rce-flag.php, poc87902.php, luci_.php und zeta_.php. Eine PHP-Datei in /tmp ist normalerweise nicht direkt über das Web erreichbar, weshalb Patchstack dies als Nachweis der Ausführung beschreibt und nicht als eigenständige persistente Backdoor. Dennoch kann dieselbe Fähigkeit, eine Datei zu schreiben, an nützlicheren Orten eingesetzt werden, und ein Host, bei dem dies gelingt, sollte als kompromittiert behandelt werden.
Patchstack sagt außerdem, dass die Ausnutzung zur Massenware geworden ist. Beobachtet wurden die User Agents cve-2026-87902-poc/1.0 und nuclei-cve-2026-87902/1.0, einschließlich einer benannten Nuclei-Vorlage. Nuclei ist ein Scan-Tool, das verwendet wird, um viele Ziele mithilfe von Vorlagen zu testen. Laut Patchstack bedeutet dies, dass die Aktivität nicht mehr auf einige wenige Akteure beschränkt ist, die aus dem Patch-Diff arbeiten. Außerdem wird gewarnt, dass der meiste verbleibende Datenverkehr gefälschte Browser-User-Agents verwendet, sodass eine Filterung nur nach User Agent nicht zuverlässig ist.
Die frühen Anfragen zeigen, warum dies kein allgemeiner Scan ist. Patchstack zufolge stimmen die Payloads mit der durch den Patch behandelten Codierung überein, was darauf hindeutet, dass die ersten Akteure anhand des Codeunterschieds arbeiteten und nicht auf Basis einer unabhängigen Entdeckung. Die WordPress-Bereinigung bewahrte maskierte Oktette, während sie wörtliche Punkte umschrieb und bei wörtlichen Schrägstrichen abschnitt; eine einfache Traversal-Zeichenfolge hätte daher nicht überlebt, eine codierte Traversal-Zeichenfolge jedoch schon. Das macht %2e%2e und %252e%252e zu nützlichen Indikatoren in Protokollen. Die Anfragen enthielten außerdem meist page_id zusammen mit pagename. Laut Patchstack ist eine echte Seiten-ID erforderlich, weil WordPress sonst eine 404 zurückgibt und der Pfad zur Seitenvorlage nicht erreicht wird.
Die Kampagne ist nicht auf ein einziges exaktes Anfragemuster beschränkt. Patchstack beobachtete Traversal-Tiefen von einer bis zwölf Ebenen, groß- und kleingeschriebene codierte Zeichen, einfache und doppelte Codierung, GET- und POST-Anfragen sowie Datenverkehr sowohl an das Stammverzeichnis der Website als auch an /index.php. POST wurde später häufiger als GET, und das ist wichtig, weil WordPress pagename aus dem POST-Body vor der Abfragezeichenfolge liest. Viele Payloads begannen mit templates%2f, weil das Traversal ein echtes Verzeichnis fortsetzen muss, das mit page- beginnt, bevor es aus dem Theme herausklettert. Patchstack sah außerdem template und ein fehlerhaftes page-templates-Präfix.
Das Blockieren von Quell-IP-Adressen dürfte nicht ausreichen. Patchstack sagt, dass der erste Abend von einem kleinen Cluster von Adressen ausging, der Datenverkehr sich später jedoch auf einige Hundert verteilte. Die aktivsten Sender, die genannt wurden, waren 43.250.53.42, 180.251.159.243, 195.178.110.247, 107.189.14.87, 45.61.184.170 und 92.246.130.76. Laut Patchstack kamen Datei-Schreibversuche von einer kleineren Teilmenge, ein Muster, das als einige wenige Akteure beschrieben wird, die auf Ergebnissen handeln, die von einer größeren Scan-Population erzeugt wurden.
Die praktische Priorität ist das Patchen. Patchstack sagt, dass WordPress 7.1.2 oder die gepatchte Version für den jeweiligen Zweig weiterhin die Lösung ist, und dass die Existenz von Datei-Schreibversuchen der dritten Phase das Aktualisieren dringend macht. Da die Korrektur bis zurück zu 4.7.37 portiert wurde, können betroffene Websites eine gepatchte Version erhalten, ohne einen großen Versionssprung zu machen. Patchstack sagt, dass Website-Betreiber bei der Bewertung ihrer Gefährdung berücksichtigen sollten, ob das aktive Theme ein page--Verzeichnis auf oberster Ebene hat und ob PHP register_argc_argv aktiviert hat.
Wenn eine sofortige Aktualisierung nicht möglich ist, ist laut Patchstack das Zurückweisen von Traversal-Sequenzen im Parameter pagename eine wirksame vorübergehende Maßnahme, weil ein normaler Seiten-Slug solche Sequenzen nicht enthält. Das Deaktivieren von register_argc_argv behebt die Dateieinbindung selbst nicht, unterbricht aber die pearcmd-Kette, was laut Patchstack den Unterschied zwischen einem Informationsleck und Codeausführung ausmachen kann.