Aktuelles

Schon wieder: WordPress 7.1.2 zeigt Angreifern den Weg ins System

WordPress veröffentlicht einen Sicherheitspatch – und noch am selben Tag nutzen Angreifer ihn als Wegbeschreibung. CVE-2026-87902 steckt seit fast zehn Jahren im Core und wird inzwischen massenhaft ausgenutzt. Was dahintersteckt und was Sie jetzt tun müssen.

Dienstag, 22. September, 11:49 Uhr UTC. WordPress hat gerade Version 7.1.2 veröffentlicht, ein Sicherheitsupdate gegen eine kritische Lücke. Bei Patchstack läuft in genau dieser Minute die erste Anfrage auf, die genau diese Lücke abklopft. Drei Stunden und 45 Minuten später versucht jemand, über denselben Weg die erste PHP-Datei auf einen fremden Server zu schreiben. Wer seine Updates am Freitag „in Ruhe“ einspielen wollte, war da längst zu spät dran.

Die Lücke trägt die Kennung CVE-2026-87902. Patchstack bewertet sie mit einem CVSS-Score von 9.2, also kritisch. Sie steckt nicht in irgendeinem Plugin aus der dritten Reihe, sondern im WordPress-Core. Und zwar seit Version 4.7.0 (!) und die erschien im Dezember 2016. Fast zehn Jahre lang hat also ein einziger fehlender Prüfaufruf jede Code-Review, jedes Audit und jedes Release überlebt.

Ein Umweg über den Seitentitel

Worum geht es technisch? Wenn WordPress eine Seite ausliefert, sucht die Funktion get_page_template() nach der passenden Template-Datei. Dafür baut sie aus dem Seitennamen einen Dateinamen nach dem Muster page-{pagename}.php. Genau hier setzen die Angreifer an: Sie schmuggeln doppelt URL-kodierte Pfadangaben (%252e%252e statt ../) in den Parameter pagename. WordPress' eigener Filter lässt die kodierten Zeichen durch, get_page_template() dekodiert sie brav – und schon klettert der Pfad aus dem Theme-Ordner heraus. Laut Analyse fehlte schlicht ein Aufruf von validate_file().

Das Ergebnis ist eine sogenannte Local File Inclusion: Ohne Login bindet WordPress eine beliebige lesbare PHP-Datei vom Server ein und führt sie aus. Entdeckt und verantwortungsvoll gemeldet hat das der Schweizer Sicherheitsforscher Robert Ressl. Er veröffentlichte nach dem Patch auch einen Proof of Concept samt Laborumgebung auf GitHub.

Ganz so simpel ist der Angriff allerdings nicht. Damit aus dem Datei-Einbinden echte Codeausführung wird, müssen drei Dinge zusammenkommen:

• Das aktive Theme (bzw. das Parent-Theme bei einem Child-Theme) hat auf oberster Ebene einen Ordner, dessen Name mit page- beginnt – klassisch page-templates.
• Auf dem Server liegt eine PHP-Datei, die sich beim Einbinden missbrauchen lässt. In der Praxis ist das pearcmd.php aus PEAR, und das funktioniert nur, wenn PHP mit register_argc_argv läuft.
• Die Website hat mindestens eine öffentlich erreichbare Seite. Die Anfrage muss auf eine echte Page zeigen, sonst liefert WordPress eine 404 und der verwundbare Code läuft nie.

Klingt nach vielen Wenns? Leider weniger, als man hofft. Das Advisory nennt die alten Standard-Themes Twenty Twelve und Twenty Fourteen sowie verbreitete Dritt-Themes wie Neve, Hestia und Sydney. Die neueren Twenty Twenty-Three bis Twenty Twenty-Five bringen keinen solchen Ordner mit. Und register_argc_argv ist nach Angaben von cms-admins.de in den offiziellen PHP-Docker-Images und in cPanel-Umgebungen mit PHP unter 8.5 standardmäßig aktiv. Das ist keine exotische Konstellation, das ist ein ganz normaler Dienstag im Shared Hosting.

Wer den Diff liest, braucht keinen Zero-Day

Die eigentliche Geschichte ist die Geschwindigkeit. Patchstack hat die Angriffswelle Schritt für Schritt protokolliert, und die Chronik liest sich wie ein Lehrbuch in Eile:

Stufe	Was die Angreifer tun	Was sie damit herausfinden
1. Sondieren	Harmlose Core-Dateien wie wp-links-opml.php oder feed-rss2.php einbinden	Ob die Inclusion auf dem Server überhaupt funktioniert
2. PEAR suchen	pearcmd.php in drei typischen Verzeichnissen ansprechen, dazu +config-show anhängen	Ob PEAR vorhanden ist und der argv-Trick greift
3. Schreiben	Mit +config-create eigene PHP-Dateien nach /tmp oder /var/tmp schreiben	Nichts mehr – ab hier gehört der Server ihnen

Die Payloads der ersten Stunden passten exakt zur Kodierung, die der Patch abfängt. Patchstack folgert daraus: Die Angreifer haben keine eigene Lücke gefunden, sie haben den Diff gelesen. Das ist die bittere Ironie jedes Sicherheitsupdates. In dem Moment, in dem der Fix öffentlich wird, liegt auch die Bauanleitung auf dem Tisch. Wer den Unterschied zwischen 7.1.1 und 7.1.2 versteht, weiß, wo er klopfen muss.

Am Mittwoch, 23. September, kippte die Lage endgültig. Der Traffic lag laut Patchstack beim Zehnfachen des ersten Abends und erreichte gegen Mittag UTC seinen bisherigen Höhepunkt. Ein fertiges Nuclei-Template für die Lücke kursiert öffentlich, die Anfragen kommen inzwischen von mehreren Hundert IP-Adressen. Einzelne Adressen zu blocken, bringt also nichts mehr. Auch der User-Agent taugt kaum als Filter: Die meisten Anfragen tarnen sich als ganz normaler Browser.

Interessant ist, was die Angreifer schreiben. Ein Teil der Dateien enthält nur eine Markierung wie CVE-2026-87902-POC-OK – hier legt jemand eine Liste verwundbarer Hosts an, vermutlich zum Weiterverkauf oder für später. Der andere Teil schreibt kleine Schnipsel, die beim Aufruf Shell-Befehle ausführen. Patchstack formuliert es trocken: Das sei keine Forschung mehr. Beobachtete Dateinamen sind unter anderem wp-pear-rce-flag.php, poc87902.php, luci_<zufall>.php und zeta_<zufall>.php.

Eine Datei in /tmp ist in der Regel nicht per Web erreichbar. Sie ist also erst mal ein Beweis, dass Code lief, noch keine dauerhafte Hintertür. Beruhigend ist das trotzdem nicht: Wer nach /tmp schreiben kann, kann auch woanders hinschreiben. Wie viele Websites tatsächlich übernommen wurden, hat bislang niemand belastbar beziffert. Wer heute eine konkrete Zahl nennt, rät.

Drei Lücken, zwei Monate, ein Muster

CVE-2026-87902 kommt nicht allein. Erst am 17. September erschien WordPress 7.1.1 mit elf Sicherheitskorrekturen, darunter die Kette „Click2Shell“: Ein präparierter Link reichte, damit ein eingeloggter Admin unbemerkt ein Theme installierte, das sich mit einer weiteren Schwäche zur Codeausführung verketten ließ. Dazu kam „Comment2Shell“ (CVE-2026-93485), bei dem ein manipulierter Kommentar im Browser des Admins zu JavaScript wurde. Im Sommer sorgte bereits XSS2Shell für Schlagzeilen. Und nebenbei brachte der Supply-Chain-Angriff auf Brevo Berichten zufolge Malware auf mehr als 100.000 Websites.

Das Muster ist immer dasselbe: Einzelne, fast harmlose Schwächen werden zu einer Kette verbunden, bis am Ende eine Shell steht. Und die Zeit zwischen Patch und Angriff schrumpft gegen null. Ein IDC-Analyst sagte gegenüber CSO Online sinngemäß, die durchschnittliche Zeit bis zum Exploit sei bei kritischen Lücken inzwischen teils negativ – der Angriffscode existiert also schon, bevor oder während das Update ausgerollt wird.

Was Sie jetzt konkret tun sollten

Die wichtigste Maßnahme ist so banal wie dringend: aktualisieren. Betroffen sind alle Versionen von 4.7.0 bis einschließlich 7.1.1. Der Fix wurde bis in alte Zweige zurückportiert, niemand muss also für den Patch einen großen Versionssprung machen:

Installierter Zweig	Gepatchte Version
7.1.x	7.1.2
7.0.x	7.0.6
6.9.x	6.9.9
6.8.x	6.8.10
4.7.x bis 6.7.x	jeweilige Sicherheitsversion des Zweigs (bis hinunter zu 4.7.37)

Automatische Hintergrund-Updates spielen den Fix selbst ein. Verlassen Sie sich aber nicht blind darauf. Das Auto-Update startet nicht immer zuverlässig, etwa bei falschen Dateirechten, gesperrten Cronjobs oder deaktiviertem WP-Cron. Also: Dashboard öffnen, unter „Aktualisierungen“ nachsehen. Wer viele Instanzen betreut, fragt per WP-CLI ab:

wp core version

Danach lohnt sich ein Blick auf die zweite Verteidigungslinie. Die folgenden Schritte brechen die bekannte Angriffskette auch unabhängig vom Update und machen künftige LFI-Lücken gleich mit harmloser:

• Theme prüfen: Hat das aktive Theme (oder Parent-Theme) einen page--Ordner auf oberster Ebene? ls -d wp-content/themes/*/page-*/ verrät es.
• register_argc_argv abschalten: Die Einstellung hat auf einem Webserver praktisch keinen Nutzen. php -i | grep register_argc_argv zeigt den Status, in der php.ini setzt du sie auf Off.
• PEAR loswerden: Wird PEAR nicht gebraucht, pearcmd.php entfernen oder dem Webserver-Benutzer die Leserechte entziehen.
• open_basedir setzen: PHP darf nur auf die Verzeichnisse zugreifen, die die Website tatsächlich braucht.
• Übergangsweise per WAF filtern: Ein echter Seiten-Slug enthält nie Traversal-Sequenzen. Anfragen mit %2e%2e oder %252e%252e im Parameter pagename kannst du ohne Nebenwirkungen blocken.

Wer schon Besuch hatte, merkt es an den Logs

Gepatcht heißt nicht sauber. Wer zwischen dem 22. September und dem eigenen Update verwundbar war, sollte nachsehen, ob jemand vorbeigeschaut hat. Die aussagekräftigsten Spuren laut Patchstack:

• Der Parameter pagename enthält %2e%2e oder %252e%252e – im Query-String oder im POST-Body. POST hat GET inzwischen als häufigste Methode überholt.
• pagename beginnt mit templates%2f oder einem anderen page--Ordnernamen.
• pagename und page_id tauchen gemeinsam auf, an der Startseite oder an /index.php.
• Anfragen mit pearcmd, +config-show oder +config-create.
• Eine normale Seiten-URL liefert mit Status 200 plötzlich OPML- oder RSS-Inhalt aus. Dann lief die Inclusion bei dir tatsächlich.

Auf dem Server selbst gehört ein Blick nach /tmp, /var/tmp und ins Document-Root dazu:

find /tmp /var/tmp -name "*.php" -newermt "2026-09-22"

Finden Sie dort PHP-Dateien, die niemand angelegt hat, ist die Sache klar: Der Server gilt als kompromittiert, nicht bloß als gescannt. Dann heißt es Logs und Dateien sichern, prüfen, was ausgeführt wurde, und sämtliche Zugangsdaten rotieren, die vom Server aus erreichbar sind: Datenbank, API-Keys, Salts, SSH, Admin-Konten.

Das Update ist die Nachricht

Man kann aus dieser Woche eine unbequeme Lehre ziehen: Ein Sicherheitsupdate ist heute keine Einladung, sondern ein Startschuss. Und zwar für beide Seiten. Der Patch verrät den Verteidigern, was sie schließen müssen und den Angreifern, wo das Scheunentor noch offen steht. Wer als Betreiber erst mal eine Woche abwartet, „ob das Update stabil ist“, lässt eben dieses Scheunentor sieben Tage lang weit offen. Die Angreifer brauchten diesmal knapp vier Stunden. Die Frage ist also nicht mehr, ob Sie zeitnah patchen. Die Frage ist, ob Ihr Server schneller ist als ein Nuclei-Template.

28.09.2026