CVE-2026-87902: WordPress 7.1.2 schließt kritische LFI-Lücke im Core, ohne Login ausnutzbar bis zur Codeausführung

Veröffentlicht: 22.09.2026 · Letzte Aktualisierung: 22.09.2026

Was ist passiert

WordPress hat am 22.09.2026 die Version 7.1.2 veröffentlicht, nur fünf Tage nach 7.1.1. Diesmal handelt es sich um ein reines Sicherheitsrelease mit einem einzigen Fix, und dieser eine Fix hat es in sich: eine unauthentifizierte Local File Inclusion in der Template-Auflösung des Core, die unter verbreiteten Hosting-Bedingungen bis zur Remote Code Execution reicht. Die Lücke trägt die Kennung CVE-2026-87902 und wurde von Robert Ressl gemeldet, die technische Analyse stammt von Patchstack, die offizielle Ankündigung kommt von WordPress selbst.

Zwei Punkte heben diese Lücke von den meisten Core-Fixes der letzten Jahre ab. Erstens der Versionsbereich: Betroffen ist jede WordPress-Version von 4.7.0 bis einschließlich 7.1.1, das sind fast zehn Jahre an Releases. Zweitens die Zugangshürde: Es gibt keine. Der Angreifer braucht kein Konto, keinen eingeloggten Administrator und keinen Klick von irgendjemandem, ein präparierter Seitenaufruf genügt. Bei Click2Shell vor einer Woche musste immerhin noch ein Administrator einen Link öffnen. Hier entfällt auch das.

Die Schwachstelle im Detail

Wenn WordPress eine Seite rendert, baut die Funktion get_page_template() eine Liste von Template-Dateinamen zusammen, die der Reihe nach ausprobiert werden. Einer dieser Kandidaten wird direkt aus dem URL-Parameter pagename gebildet, also aus einem Wert, den der Besucher der Website selbst bestimmt.

Der Fehler ist von der unangenehm banalen Sorte: WordPress prüft Template-Kandidaten eigentlich mit der hauseigenen Funktion validate_file() auf Verzeichniswechsel-Tricks. Beim Kandidaten aus dem pagename-Parameter fehlte genau diese Prüfung, und zwar nur bei der URL-dekodierten Variante des Werts. Der Schutz stand im Code drei Zeilen über der Stelle, an der er gefehlt hat. Ein zusätzlicher urldecode()-Aufruf macht aus einem harmlos aussehenden Seitennamen einen echten Pfad mit Verzeichniswechseln, und schon bindet WordPress eine Datei ein, die der Angreifer bestimmt.

Zwei Einschränkungen begrenzen den Spielraum. Der Dateiname wird als page-{pagename}.php zusammengesetzt, der Angriffspfad muss also in einem Verzeichnis beginnen, das tatsächlich mit page- anfängt, und die Zieldatei muss auf .php enden. In der Praxis heißt das: Das aktive Theme braucht ein Verzeichnis wie page-templates auf oberster Ebene. Genau so ein Verzeichnis bringen ältere WordPress-Standard-Themes und eine ganze Reihe populärer Dritt-Themes mit.

Vom Datei-Einbinden zur Codeausführung

Eine Local File Inclusion führt zunächst nur den Code aus, der in der eingebundenen Datei steht. Für eine echte Übernahme braucht der Angreifer eine PHP-Datei auf dem Server, die sich beim Einbinden nützlich verhält. Der bekannte Kandidat dafür ist pearcmd.php aus der PEAR-Distribution, und der funktioniert immer dann, wenn PHP mit der Einstellung register_argc_argv läuft. Diese Einstellung ist in den offiziellen PHP-Docker-Images und in cPanel-Umgebungen mit PHP unter 8.5 standardmäßig aktiv. Von einer exotischen Konfiguration kann also keine Rede sein.

Die ehrliche Einordnung lautet damit: Die Dateieinbindung ohne Login funktioniert auf jeder betroffenen Installation mit passendem Theme, die Codeausführung zusätzlich überall dort, wo der Hosting-Stack mitspielt. Und das tut er häufig. Wer seinen eigenen Stack nicht im Detail geprüft hat, behandelt die Lücke besser als das, was ihre Bewertung sagt: kritisch.

Was WordPress geändert hat

Der Patch besteht aus zwei Teilen, und der zweite ist der interessantere. Zunächst bekommt der betroffene Codezweig dieselbe validate_file()-Prüfung, die der Nachbarzweig schon immer hatte, damit ist die gemeldete Lücke geschlossen. Zusätzlich führt 7.1.2 aber eine neue Sicherung ein: Jeder aufgelöste Template-Pfad muss künftig innerhalb der erlaubten Theme-Verzeichnisse liegen, egal über welchen Codepfad er zustande kam.

Diese zweite Änderung sagt mehr, als in der Sicherheitsmeldung steht. Für den gemeldeten Fehler hätte die Ein-Zeilen-Korrektur gereicht. Dass das Sicherheitsteam die Template-Auflösung stattdessen als ganze Problemklasse absichert, ist die richtige Entscheidung, und sie deutet an, dass man dort nicht darauf wetten wollte, dass der gemeldete Pfad der einzige verwundbare war.

Wer ist betroffen

Betroffen ist praktisch jede WordPress-Installation, die nicht bereits auf 7.1.2 oder einem gepatchten Backport-Release läuft. Ob aus der Lücke im Einzelfall mehr als eine Dateieinbindung wird, hängt an zwei Fragen: Hat das aktive Theme ein Verzeichnis, dessen Name mit page- beginnt, etwa page-templates? Und läuft PHP mit register_argc_argv? Zwei Mal Ja bedeutet: Der Weg bis zur Codeausführung ist frei.

Wichtig für ältere Installationen: WordPress hat Backport-Fixes für alle noch unterstützten Versionszweige bis hinunter zu 4.7 veröffentlicht. Auch eine Website, die aus guten oder schlechten Gründen noch auf einem alten Zweig läuft, kann den Fix ohne Major-Update einspielen. Offiziell unterstützt bleibt trotzdem nur die jeweils aktuelle Version, und die heißt seit heute 7.1.2.

Was Sie jetzt tun sollten

1. Sofort auf 7.1.2 aktualisieren. Das Update steht im Dashboard unter Aktualisierungen bereit. Websites mit aktivierten automatischen Hintergrund-Updates sollten es bereits erhalten haben, verlassen Sie sich darauf aber nicht, sondern prüfen Sie die installierte Version.

2. Wenn Sie nicht sofort updaten können, prüfen Sie Ihre Exponierung. Schauen Sie nach, ob Ihr aktives Theme ein Verzeichnis mit dem Namensanfang page- enthält, und ob PHP bei Ihrem Hoster mit register_argc_argv läuft. Beides ersetzt kein Update, aber es sagt Ihnen, wie nah Ihre Website am Worst Case steht.

3. Bei Verdacht auf Kompromittierung nicht abwarten. Die Lücke ist seit heute öffentlich dokumentiert, mit Scans auf verwundbare Installationen ist erfahrungsgemäß binnen Tagen zu rechnen. Auffällige Dateien im Theme-Verzeichnis, unerklärliche PHP-Dateien oder seltsame Einträge im Access-Log sind ein Fall für eine professionelle Bereinigung.

Für unsere Wartungskunden gilt wie immer: Wir spielen das Update zeitnah auf allen betreuten Websites ein und prüfen die Installationen auf die genannten Risikofaktoren. Wenn Sie Ihre WordPress-Website noch selbst aktualisieren, ist heute ein guter Tag, das zu ändern: Unsere WordPress-Wartung gibt es ab 9,50 € im Monat, inklusive Updates, 60-Tage-Backups und Sicherheits-Monitoring auf Servern in Deutschland.

Einordnung: dritte Core-Lücke mit RCE-Potenzial in diesem Jahr

Nach wp2shell im Juli und Click2Shell vor einer Woche ist dies bereits die dritte Schwachstelle im WordPress Core innerhalb weniger Monate, die bis zur Codeausführung reicht. Das ist ungewöhnlich, denn der Core gehört zu den am besten geprüften Komponenten des Ökosystems, die große Mehrheit aller Sicherheitsvorfälle geht auf Plugins und Themes zurück.

Ein Muster verbindet die drei Fälle: Es sind keine spektakulären neuen Angriffstechniken, sondern alte, gut verstandene Fehlerklassen an Stellen, an denen die vorhandenen Schutzmechanismen schlicht nicht angewendet wurden. Die aktuelle Lücke existierte fast zehn Jahre lang neben der Funktion, die sie verhindert hätte. Für Website-Betreiber folgt daraus eine unbequeme, aber praktische Konsequenz: Die Frage ist nicht, ob die nächste Core-Lücke kommt, sondern wie schnell die eigene Website gepatcht wird, wenn sie kommt. Genau diese Reaktionszeit ist der Unterschied zwischen einer Randnotiz und einem Sicherheitsvorfall.

Häufige Fragen

Woran erkenne ich, ob meine Website betroffen ist?

Prüfen Sie die installierte WordPress-Version im Dashboard unter Aktualisierungen. Jede Version von 4.7.0 bis 7.1.1 ist verwundbar, sicher sind 7.1.2 und die offiziellen Backport-Releases der älteren Zweige. Ob aus der Dateieinbindung im Einzelfall Codeausführung wird, hängt zusätzlich am aktiven Theme (Verzeichnis mit Namensanfang page-) und an der PHP-Einstellung register_argc_argv.

Reicht das automatische Hintergrund-Update von WordPress?

In den meisten Fällen ja, denn Sicherheitsreleases wie 7.1.2 werden standardmäßig automatisch verteilt. Verlassen Sie sich aber nicht darauf: Auf manchen Installationen sind automatische Updates deaktiviert, etwa durch Hoster-Einstellungen oder Konstanten in der wp-config.php. Kontrollieren Sie die Versionsnummer nach dem angeblichen Update selbst.

Ich kann nicht sofort updaten, was kann ich übergangsweise tun?

Prüfen Sie zuerst Ihre Exponierung: Enthält das aktive Theme ein Verzeichnis, dessen Name mit page- beginnt, und läuft PHP mit register_argc_argv? Wenn ja, sollte das Update Vorrang vor allem anderen haben. Eine Web Application Firewall kann typische Angriffsmuster mit Verzeichniswechseln im pagename-Parameter abfangen, ersetzt das Update aber nicht.

Woran merke ich, ob meine Website bereits angegriffen wurde?

Suchen Sie im Access-Log nach Aufrufen mit auffälligen pagename-Parametern, insbesondere mit kodierten Verzeichniswechseln wie %2e%2e%2f. Weitere Warnzeichen sind unbekannte PHP-Dateien im Theme- oder Upload-Verzeichnis und neu angelegte Administrator-Konten. Bei konkretem Verdacht hilft unsere Notfall-Bereinigung für gehackte WordPress-Websites.

Schützt mich ein Security-Plugin vor dieser Lücke?

Nur bedingt. Security-Plugins mit Firewall-Funktion können bekannte Angriffsmuster blockieren, sobald deren Regeln aktualisiert sind. Die Schwachstelle selbst liegt aber im WordPress Core und verschwindet erst mit dem Update auf 7.1.2. Behandeln Sie Firewall-Regeln als Zeitpuffer, nicht als Lösung.

Quellen

• WordPress.org: WordPress 7.1.2 Security Release (22.09.2026)
• Patchstack: Technische Analyse der LFI-zu-RCE-Kette in CVE-2026-87902
• GitHub Security Advisory GHSA-7hp8-65ch-5whp