WordPress CVE-2026-87902: Angriffe laufen bereits
Kritische Lücke im WordPress-Kern: CVE-2026-87902 wird seit dem Tag des Patches ausgenutzt. Was hinter dem Angriff steckt und was jetzt zu tun ist.
WordPress hat mit Version 7.1.2 eine kritische Lücke im Kern geschlossen, und schon wenige Stunden später liefen die ersten Angriffe. CVE-2026-87902 steckt in der Art, wie WordPress das Template für eine Seite heraussucht. Ein Angreifer kann ohne Anmeldung dafür sorgen, dass WordPress eine beliebige lesbare PHP-Datei vom Server einbindet, die gar nicht zum Theme gehört. Unter bestimmten Bedingungen wird daraus Codeausführung. Patchstack bewertet das mit 9.2 von 10 Punkten. Betroffen ist alles von 4.7.0 bis 7.1.1, also praktisch jede Installation der letzten neun Jahre.
CVE-2026-87902: vom Patch zum Exploit an einem Tag
Die ersten Anfragen trafen laut Patchstack am 22. September um 11:49 UTC ein, am selben Tag, an dem das Update auf 7.1.2 erschien. Die Angreifer haben die Lücke nicht selbst gefunden, sondern aus dem Unterschied zwischen alter und neuer Version herausgelesen. Der Trick: WordPress filtert ../ aus dem Seitennamen, lässt aber die prozentkodierte Variante %2e%2e durch.
Die Angriffe laufen in drei Stufen. Zuerst wird eine harmlose Kerndatei wie wp-links-opml.php eingebunden, nur um zu sehen, ob die Seite verwundbar ist. Dann zielt die Anfrage auf pearcmd.php aus dem PEAR-Paket von PHP. Ist in der PHP-Konfiguration register_argc_argv aktiv, landet der Rest der URL als Befehl bei diesem Skript. In der dritten Stufe schreibt config-create damit eine PHP-Datei mit beliebigem Inhalt auf die Platte. Bisher landen die Dateien in /tmp und /var/tmp, sind also meist nicht übers Web erreichbar. Kompromittiert ist der Server trotzdem. Seit ein fertiges Nuclei-Template kursiert, kommt der Traffic von mehreren Hundert Adressen, mit gefälschten Browser-Kennungen.
Was WordPress-Betreiber jetzt tun sollten
Das Wichtigste zuerst: Version prüfen. Wer automatische Hintergrund-Updates aktiv hat, dürfte längst auf 7.1.2 sein. Wer sie abgedreht hat, weil ein Update einmal ein Plugin zerlegt hat, sollte jetzt von Hand nachziehen. Der Fix wurde bis 4.7.37 zurückportiert, auch alte Zweige kommen also ohne großen Versionssprung davon. Wer nicht sofort aktualisieren kann, blockt im Reverse Proxy Anfragen mit %2e%2e im Parameter pagename und schaltet register_argc_argv in der php.ini ab.
Danach lohnt ein Blick in die Access-Logs: Anfragen, die pagename und page_id kombinieren, und kodierte Pfade mit %2e%2e. Liegen in /tmp oder /var/tmp PHP-Dateien mit Namen wie poc87902.php, luci_… oder zeta_…, hat jemand Code ausgeführt. Dann reicht das Update nicht mehr, dann ist das ein Vorfall, und die Installation gehört neu aufgesetzt statt geflickt. Bei Docker-Images lohnt die Frage, ob PEAR überhaupt drin sein muss. Viele offizielle PHP-Images bringen es mit, und genau diese Pfade probieren die Angreifer durch.
Das Muster dahinter ist nicht neu, nur viel schneller. Früher lag zwischen Patch und Massenangriff eine Woche, heute liest ein Werkzeug den Diff und baut daraus bis Mittag einen Scanner. Die Frist, in der ein Update „demnächst“ eingespielt werden kann, gibt es nicht mehr. Im April waren es noch mindestens 30 kompromittierte WordPress-Plugins, bei denen man sich damit trösten konnte, dass es halt nur die Plugins sind. Diesmal ist es der Kern, und diesmal hilft nur automatische Updates die adhoc durchlaufen.