WordPress 7.1.2 schließt kritische Path-Traversal-Schwachstelle
WordPress 7.1.2, veröffentlicht am 22. September 2026, behebt eine kritische nicht authentifizierte Path-Traversal-Schwachstelle in WordPress Core, die als CVE-2026-87902 verfolgt wird. Die Schwachstelle, die einen CVSS-v4.0-Wert von 9,2 (kritisch) aufweist, kann es einem Angreifer ohne WordPress-Konto ermöglichen, eine Website dazu zu zwingen, eine lesbare PHP-Datei von außerhalb des aktiven Theme-Verzeichnisses einzubinden. Auf Websites, deren Theme und Server bestimmte Bedingungen erfüllen, kann dies zu Remote Code Execution und einer vollständigen Übernahme der Website führen. Das WordPress-Sicherheitsteam hat außerdem Sicherheits-Backports für jeden Zweig bis zurück zu WordPress 4.7 veröffentlicht. Eine Wordfence-Intelligence-Zusammenfassungstabelle listete die Schwachstelle unter einer Bewertungskonvention als CVSS 8,1 (hoch), während die Hauptwarnung und der Patch-Hinweis CVSS v4.0 9,2 (kritisch) verwenden.
Eine Path-Traversal-Schwachstelle ist eine Möglichkeit, Software dazu zu bringen, eine Datei außerhalb des Ordners zu lesen, in dem sie arbeiten soll, oft durch die Verwendung von '..' in einem Dateipfad. In diesem Fall hat WordPress Core nicht ordnungsgemäß überprüft, ob ein Template-Name zu einer Datei innerhalb des aktiven Theme-Verzeichnisses aufgelöst wurde. Ein Angreifer, der eine speziell gestaltete Anfrage an eine anfällige Website sendet, kann WordPress dazu bringen, eine vom Angreifer gewählte lokale PHP-Datei einzubinden. Dies wird als Local File Inclusion bezeichnet. Wenn die eingebundene Datei beispielsweise pearcmd.php ist, ein Befehlszeilentool, das in einigen PHP-Installationen enthalten ist, und der Server register_argc_argv aktiviert hat, kann die Einbindung zu Remote Code Execution werden, was bedeutet, dass der Angreifer eigene Befehle auf dem Server ausführen kann. Die WordPress-Warnung weist darauf hin, dass das offizielle PHP-Docker-Image und Standard-cPanel-Konfigurationen bei PHP vor 8.5 genau diese Kombination aufweisen können.
Die Ausnutzung erfolgt nicht automatisch auf jeder ungepatchten Website. Die WordPress-Warnung nennt zwei Hauptbedingungen. Erstens muss das aktive Parent- oder Child-Theme ein Verzeichnis auf oberster Ebene enthalten, dessen Name mit page- beginnt, zum Beispiel den page-templates-Ordner, der in den älteren Themes Twenty Twelve und Twenty Fourteen sowie in den Themes Neve, Hestia und Sydney zu finden ist. Zweitens muss der Server eine lesbare PHP-Datei haben, die bei Einbindung nützliches Verhalten erzeugt, wie pearcmd.php mit aktiviertem register_argc_argv. Websites, die nicht beide Bedingungen erfüllen, sind möglicherweise nicht sofort für Remote Code Execution ausnutzbar, aber die zugrunde liegende Path-Traversal-Schwachstelle bleibt in WordPress Core vorhanden, bis das Update angewendet wird. Allein die Theme-Namen reichen nicht aus, um die Gefährdung zu beurteilen, da die Warnung keine betroffenen Theme-Versionsbereiche auflistet; Administratoren sollten die Verzeichnisstruktur ihres installierten Themes und die Serverdateien direkt überprüfen.
Die technische Ursache liegt in der Art und Weise, wie WordPress Seiten-Templates auflöst. In anfälligen Versionen liest die Funktion get_page_template() die öffentliche Query-Variable pagename und wendet vor dem Erstellen eines Template-Kandidaten namens page-{$pagename}.php eine zusätzliche urldecode()-Funktion darauf an. Da WordPress Anfrageparameter bereits einmal URL-dekodiert, kann ein Angreifer Traversal-Zeichen wie '..' doppelt kodieren, sodass sie erst später bei der Template-Auflösung dekodiert werden. Der resultierende Kandidat wird dann an locate_template() übergeben, das den Kandidaten mit dem aktiven Theme-Pfad verband und prüfte, ob die Datei existierte, aber nicht verifizierte, dass der endgültige Pfad innerhalb eines genehmigten Theme-Verzeichnisses blieb. Diese Kombination ermöglichte es einer gestalteten Seitenanfrage, aus einem kompatiblen page-*-Verzeichnis auszubrechen und WordPress auf eine PHP-Datei an anderer Stelle auf dem Server zu lenken. Wordfence würdigte Robert Ressl für die Entdeckung und verantwortungsvolle Offenlegung der Schwachstelle und reproduzierte das Verhalten auf WordPress 7.1.
Der Fix fügt zwei Schutzebenen hinzu. get_page_template() validiert nun den dekodierten Seitennamen mit der Funktion validate_file() von WordPress, bevor ein Template-Kandidat erstellt wird, und weist die im Angriff verwendete Traversal-Syntax zurück. Darüber hinaus führt locate_template() nun vorhandene Kandidaten durch eine neue Prüfung namens _wp_is_template_path_allowed(). Wenn ein Pfad Traversal-Komponenten enthält, löst WordPress seinen kanonischen Speicherort auf und bestätigt, dass er innerhalb eines genehmigten Theme- oder Theme-Kompatibilitätsverzeichnisses bleibt, bevor er geladen wird. Die erste Kontrolle schließt den spezifischen Anfragepfad, während die zweite eine mehrschichtige Verteidigung für andere Kernfunktionen und Filter bietet, die Template-Namen liefern können.
Da die Sicherheitsveröffentlichung vom 22. September viele ältere Zweige abdeckt, sind die betroffenen Versionsbereiche zweigspezifisch. Eine pauschale Aussage wie „WordPress 7.1.1 und früher“ wäre falsch, da Backports für ältere Zweige existieren, obwohl ihre Versionsnummern unter 7.1.1 liegen. Die gepatchten Versionen sind: 7.1.2 für die 7.1-Serie, 7.0.6, 6.9.9, 6.8.10, 6.7.9, 6.6.9, 6.5.12, 6.4.12, 6.3.12, 6.2.13, 6.1.14, 6.0.16, 5.9.18, 5.8.17, 5.7.19, 5.6.21, 5.5.22, 5.4.23, 5.3.25, 5.2.28, 5.1.26, 5.0.29, 4.9.33, 4.8.32 und 4.7.37. WordPress.org gibt an, dass nur die neueste Version der 7.1-Serie aktiv gewartet wird; die älteren Fixes sind freiwillige Sicherheits-Backports. Websites auf einem älteren Zweig sollten das verfügbare Update sofort anwenden und ein Upgrade auf eine derzeit gewartete Version planen.
Wordfence Premium-, Wordfence Care- und Wordfence Response-Kunden erhielten am 22. September 2026, demselben Tag, an dem die Schwachstelle und Updates veröffentlicht wurden, Firewall-Schutz gegen CVE-2026-87902. Wordfence Free-Benutzer erhalten dieselbe Regel am 22. Oktober 2026, nach der üblichen 30-tägigen Verzögerung. Die Firewall-Regel erkennt Traversal-Syntax in der pagename-Eingabe, einschließlich der kodierten Form, die nach dem ersten Dekodierungsdurchgang der Firewall verbleibt. Firewall-Schutz verringert die Gefährdung, ist aber kein Ersatz für die Aktualisierung von WordPress Core.
Website-Besitzer sollten die WordPress-Version auf jeder von ihnen verwalteten Website überprüfen, auf 7.1.2 oder die feste Version für ihren Zweig aktualisieren und dann bestätigen, dass das Update tatsächlich abgeschlossen wurde. Automatische Hintergrund-Updates sind nicht immer erfolgreich. Wenn eine sofortige Aktualisierung nicht möglich ist, bestätigen Sie, dass eine geeignete Firewall-Regel aktiv ist, und planen Sie das Core-Update so bald wie möglich. Überprüfen Sie Webserver- und Firewall-Protokolle auf verdächtige Anfragen mit Traversal-ähnlichen Werten im pagename-Parameter. Wenn eine Anfrage den anfälligen Template-Pfad erreicht hat, behandeln Sie die Website als potenziell kompromittiert und beginnen Sie eine vollständige Incident-Response: Überprüfen Sie Administratorkonten, kürzlich installierte oder geänderte Plugins, geplante Aufgaben und unerwartete PHP-Dateien. Primärquellen sind die WordPress-Core-Sicherheitswarnung GHSA-7hp8-65ch-5whp, der WordPress-Core-Changeset 63792 und das WordPress-Release-Archiv. Für Website-Besitzer, die zeitnahe WordPress-Core-Updates, gehärtete Serverkonfiguration und automatische Backups lieber von einem Anbieter erledigen lassen möchten, ist Managed WordPress Hosting wie AEU Hosting (albhosting.eu) eine Möglichkeit, das Zeitfenster zwischen einer Sicherheitsveröffentlichung und einer gepatchten Website zu verkürzen, aber die Verantwortung, das Update zu überprüfen, liegt weiterhin beim Website-Besitzer.