WordPress CVE-2026-87902: Angriffe begannen Stunden nach dem Fix

Angreifer begannen weniger als fünf Stunden nach Veröffentlichung der gepatchten Version, WordPress-Seiten auf eine kritische Schwachstelle namens CVE-2026-87902 zu testen, so ein neuer Bericht von Patchstack. Die Schwachstelle ist ein nicht authentifiziertes Local-File-Inclusion-Problem in der Art und Weise, wie WordPress Seitenvorlagen auflöst, und betrifft WordPress-Core-Versionen von 4.7.0 bis 7.1.1. Eine Local-File-Inclusion-Schwachstelle ermöglicht es einem entfernten Angreifer, eine Website dazu zu bringen, eine Datei zu lesen, die sie nicht lesen sollte, was in diesem Fall unter bestimmten Bedingungen zu Remote-Code-Ausführung führen kann. WordPress hat das Problem in Version 7.1.2 behoben, mit rückportierten Patches für ältere Zweige, darunter 7.0.6, 6.9.9, 6.8.10 und bis zurück zu 4.7.37. Die Schwachstelle erreicht 9,2 auf der CVSS-Skala, ist nicht authentifiziert, und Patchstack listet den Ausnutzungsstatus als aktive Probing-Aktivität beobachtet.

Die Schwachstelle liegt in der Art und Weise, wie WordPress einen Seitenvorlagen-Kandidaten aus einem URL-Parameter namens pagename erstellt. Dave Jong, Leiter der Sicherheitsforschung bei Patchstack, erklärt, dass das Kernproblem ein Path Traversal ist, das zu Local File Inclusion führt. Im normalen Datenverkehr teilt eine URL wie /?page_id=1&pagename=about WordPress mit, welche Seite angezeigt werden soll. Ein Angreifer kann stattdessen einen speziell gestalteten pagename-Wert verwenden, der mit templates%252f beginnt, gefolgt von kodierten Dot-Dot-Slash-Sequenzen. Die doppelte Kodierung ist wichtig: WordPress führt den Slug zuerst durch einen Sanitizer, der wörtliche Punkte entfernt und bei wörtlichen Schrägstrichen abschneidet, aber prozentkodierte Oktette beibehält. Später dekodiert get_page_template() diese Oktette, und das Traversal klettert aus dem Theme-Verzeichnis heraus, um eine beliebige Datei einzubinden. Der Angreifer muss außerdem eine gültige page_id angeben, die zu einer echten Seite führt, da WordPress andernfalls einen 404 zurückgibt, bevor der verwundbare Codepfad erreicht wird.

Patchstack sagt, dass der erste Probing-Versuch seine Protokolle am 22. September 2026 um 17:44 UTC erreichte, weniger als fünf Stunden nach der Veröffentlichung von WordPress 7.1.2. Die Payloads entsprechen genau der Kodierung, die der Patch adressiert, was darauf hindeutet, dass wer auch immer sie erstellt hat, vom Diff aus arbeitete und nicht von einer unabhängigen Entdeckung. Bisher zielt jede beobachtete Anfrage die Einbindung auf eine gewöhnliche WordPress-Core-Datei: wp-links-opml.php, wp-includes/functions.php oder wp-cron.php. Keine dieser Dateien gibt einem Angreifer für sich genommen etwas, aber sie funktionieren als billiger Ja-oder-Nein-Test. Zum Beispiel gibt wp-links-opml.php ein unverwechselbares OPML-Dokument aus, sodass das Sehen dieser Ausgabe von einer normalen Seiten-URL bestätigt, dass die Einbindung erfolgreich war. Patchstack beschreibt dies als Aufklärung, nicht als Payload-Lieferung: Jemand baut eine Liste ausnutzbarer Hosts auf. Der gefährlichere Schritt, denselben Trick auf eine Datei wie pearcmd.php auf einem Server mit aktiviertem register_argc_argv zu richten, ist noch nicht in Patchstacks Daten aufgetaucht, aber das Unternehmen erwartet, dass er folgen wird, sobald die Scan-Ergebnisse zurückkommen.

Die beobachteten Anfragen teilen zwei verräterische Details. Erstens sind sie auf der HTTP-Ebene doppelt kodiert, weshalb %252e%252e in den Protokollen erscheint statt einer einfachen ../-Sequenz. Patchstack sagt, dass dies %252e%252e zu einer rauscharmen Zeichenfolge macht, nach der man suchen kann. Zweitens kombiniert jede Anfrage pagename mit page_id, weil das Traversal allein nicht ausreicht, um den verwundbaren Code zu erreichen. Der pagename-Wert beginnt mit templates%252f und setzt ein echtes Verzeichnis fort, das mit page- beginnt, bevor er aus dem Theme heraus klettert. Patchstack hat gesehen, dass die Traversal-Tiefe von drei bis sieben Ebenen reicht, wahrscheinlich um verschiedene Installationslayouts zu bewältigen, und sowohl Groß- als auch Kleinschreibung der Hex-Kodierung. Anfragen kommen über GET und POST, weil WordPress pagename aus dem POST-Body bevorzugt vor der Query-Zeichenfolge liest. Sie gehen auch direkt an /index.php sowie an die Site-Wurzel. Die Aktivität kam von einem kleinen Cluster von Quelladressen, die mehrere geschützte Sites trafen, wobei sich das meiste Volumen auf zwei benachbarte IPv4-Adressen konzentrierte, 169.58.48.193 und 169.58.48.195, und etwas IPv6-Verkehr von 2001:df1:e8c0::106b. Die meisten Anfragen trugen einen Go-http-client/1.1-User-Agent, ein kleinerer Teil verwendete gefälschte Browser-Strings. Die Aktivität erreichte in der ersten Stunde ihren Höhepunkt und flachte danach ab, was laut Patchstack die übliche Form für einen opportunistischen Sweep durch eine vorbereitete Host-Liste ist und nicht für eine gezielte Kampagne.

Patchstack sagt, dass seine Kunden durch eine RapidMitigate-Regel geschützt sind, eine Sicherheitsregel, die bekannte Angriffsmuster für geschützte Sites automatisch blockiert, aber für alle anderen besteht die Lösung darin, auf WordPress 7.1.2 oder die gepatchte Version Ihres Zweigs zu aktualisieren. WordPress hat den Fix bis 4.7.37 zurückportiert, sodass jeder betroffene Zweig eine gepatchte Version hat und eine ältere Site sie ohne einen großen Versionssprung übernehmen kann. Site-Besitzer können zwei Voraussetzungen aus dem ursprünglichen Write-up prüfen, bevor sie aktualisieren: ob das aktive Theme ein Top-Level-page--Verzeichnis hat und ob PHP register_argc_argv aktiviert hat. Wenn ein sofortiges Update nicht möglich ist, ist das Ablehnen von Traversal-Sequenzen im pagename-Parameter ein wirksamer Notbehelf, weil ein echter Seiten-Slug niemals eine enthält. Für die Suche in vorhandenen Protokollen listet Patchstack die aussagekräftigsten Indikatoren auf: ein pagename-Parameter, der %252e%252e in der Query-Zeichenfolge oder im POST-Body enthält, ein pagename-Wert, der mit templates%252f oder einem anderen page--Verzeichnisnamen beginnt, pagename und page_id, die zusammen auf der Site-Wurzel oder /index.php erscheinen, und OPML-Ausgabe oder eine andere unerwartete Core-Dateiausgabe, die von einer normalen Seiten-URL zurückgegeben wird. Der letzte Punkt sagt Ihnen, ob eine Probe erfolgreich war: Eine 200-Antwort mit OPML, wo eine Seite hätte sein sollen, bedeutet, dass die Einbindung auf diesem Host funktioniert hat, und die Site sollte dies als bestätigtes verwundbares Fenster behandeln und nicht als blockierten Versuch. Sites, die vor dem Patchen oder der Mitigation exponiert waren, sollten historische Protokolle auf dieser Grundlage überprüfen und nach unerwarteten oder geänderten Dateien suchen.

Patchstacks Zeitlinie zeigt, dass WordPress 7.1.2 und die Advisory GHSA-7hp8-65ch-5whp am 22. September 2026 veröffentlicht wurden. Die Schwachstelle wurde in die Patchstack-Datenbank aufgenommen und eine RapidMitigate-Regel am selben Tag für geschützte Sites bereitgestellt. Der erste Ausnutzungsversuch wurde um 17:44 UTC beobachtet und blockiert, und die jüngste Aktivität zum Zeitpunkt des Schreibens war 19:51 UTC. Patchstack überwacht weiterhin eine Verschiebung von Core-Datei-Proben zu Einbindungszielen, die tatsächlich etwas bewirken, und sagt, es werde aktualisieren, wenn sich das ändert. Für Website-Besitzer auf Managed-WordPress-Hosting wie AEU Hosting können Core-Updates und serverseitige Sicherheitsüberwachung das Fenster zwischen der Veröffentlichung eines Patches und seiner Anwendung verkürzen, was genau die Exposition gegenüber schnelllebigen Proben wie dieser reduziert.