WordPress 7.1.2 schließt kritische Lücke CVE 2026 87902: Jetzt aktualisieren

Am 22. September 2026 hat das WordPress Team die Version 7.1.2 veröffentlicht. Sie schließt eine Sicherheitslücke, die fast jede Installation der letzten zehn Jahre betrifft. Unter der Kennung CVE 2026 87902 geht es um eine Local File Inclusion im WordPress Core, die sich unter bestimmten Bedingungen bis zur Ausführung von beliebigem Code ausweiten lässt. Die Lücke ist mit einem CVSS Wert von 9,2 als kritisch eingestuft.

Wer ist betroffen?

Betroffen sind alle WordPress Versionen von 4.7.0 bis einschließlich 7.1.1. Für alle noch unterstützten Versionszweige bis zurück zu 4.7 gibt es Korrekturen. Das Gefährliche daran: Ein Angreifer braucht weder ein Benutzerkonto noch Administratorrechte, und niemand muss auf einen Link klicken. Ein präparierter Aufruf der Website genügt.

 Was steckt technisch dahinter?

Der Fehler liegt in der Funktion get_page_template(), die entscheidet, welche Vorlage des Themes für eine Seite geladen wird. Normalerweise prüft WordPress Dateipfade mit validate_file(), damit niemand über Tricks wie ../ aus dem erlaubten Verzeichnis ausbrechen kann. Genau an dieser Stelle fehlte die Prüfung aber für den Parameter pagename, nachdem er ein weiteres Mal URL dekodiert wurde. So ließ sich der Pfad manipulieren und auf fremde PHP Dateien umlenken. Damit ein Angriff klappt, müssen ein paar Bedingungen zusammenkommen:

• Für das Einbinden fremder Dateien braucht das aktive Theme einen Unterordner, dessen Name mit page- beginnt, zum Beispiel page-templates. Das ist bei vielen Themes der Fall. Die Zieldatei muss auf .php enden.
• Für die Ausführung von eigenem Code muss in PHP die Einstellung register_argc_argv aktiv sein. Das ist in den offiziellen PHP Images für Docker und auf cPanel Servern mit PHP unter 8.5 standardmäßig so. Gerade der zweite Punkt macht die Lücke für klassisches Webhosting relevant. Viele Websites erfüllen beide Bedingungen, ohne dass es ihre Betreiber wissen.

Was wurde behoben?

Die Korrektur arbeitet auf zwei Ebenen. Zum einen wurde die fehlende Prüfung mit validate_file() nachgerüstet. Zum anderen prüft WordPress jetzt grundsätzlich, ob ein ermittelter Vorlagenpfad wirklich innerhalb der erlaubten Themeverzeichnisse liegt. Selbst wenn künftig an anderer Stelle eine Prüfung vergessen wird, greift diese zweite Sicherung.

Was sollten Sie jetzt tun?

Sofort aktualisieren. Warten Sie nicht auf das nächste Wartungsfenster. Spielen Sie Version 7.1.2 oder die passende Korrektur für Ihren Versionszweig ein. Wer automatische Hintergrundaktualisierungen aktiviert hat, sollte im Dashboard kontrollieren, ob das Update tatsächlich angekommen ist.
Die eigene Angriffsfläche prüfen. Schauen Sie nach, ob Ihr Theme einen Ordner mit page- am Anfang enthält und ob register_argc_argv in Ihrer PHP Konfiguration eingeschaltet ist.

Nach Spuren suchen.

Wenn Ihre Website vor dem Update längere Zeit erreichbar war, lohnt ein Blick auf folgende Hinweise:

• Einträge im Zugriffsprotokoll mit auffälligen Werten im Parameter pagename, vor allem mit kodierten Verzeichniswechseln wie %2e%2e%2f
• unbekannte PHP Dateien im Theme oder im Uploadordner
• neu angelegte Administratorkonten, die niemand aus Ihrem Team kennt

Finden Sie etwas davon, sollten Sie die Seite nicht einfach nur aktualisieren. Dann gehört eine gründliche Bereinigung dazu, idealerweise mit dem Einspielen einer sauberen Sicherung und dem Wechsel aller Passwörter.

Reicht eine Firewall nicht aus?

Eine Web Application Firewall oder ein Sicherheitsplugin mit Firewallfunktion kann typische Angriffsmuster abfangen, etwa kodierte Verzeichniswechsel im Parameter pagename. Das verschafft Zeit, ersetzt das Update aber nicht. Die eigentliche Schwachstelle im Core bleibt bestehen, bis die neue Version installiert ist, und Angreifer finden oft Varianten, die ein Filter nicht kennt.

Kein Einzelfall

CVE 2026 87902 ist bereits die dritte Lücke im WordPress Core mit Potenzial zur Codeausführung innerhalb weniger Monate. Im Juli sorgte wp2shell für Aufsehen, vor einer Woche folgte Click2Shell. Alle drei Fälle haben etwas gemeinsam: Es handelt sich um altbekannte Fehlerklassen, und die passenden Schutzmechanismen waren im

Code längst vorhanden. Sie wurden an einer einzelnen Stelle nur nicht angewendet.

Für Betreiber heißt das vor allem eines: Aktualisierungen sind keine lästige Pflicht, die man irgendwann erledigt. Sie sind der wichtigste Schutz für Ihre Website.

*Das Hintergrundbild für diesen Blogbeitrag wurde mithilfe einer KI erstellt.