WordPress 7.1.2 behebt kritische Schwachstelle in Template-Dateien
WordPress 7.1.2 wurde am 22. September 2026 als reines Sicherheitsupdate für eine einzelne Core-Schwachstelle veröffentlicht, doch das Problem ist schwerwiegend: eine nicht authentifizierte lokale Dateieinbindung bei der Auflösung von Seiten-Templates, die in manchen Hosting-Konfigurationen bis zur Remote Code Execution führen kann. Nicht authentifiziert bedeutet, dass ein Angreifer kein WordPress-Konto benötigt. Lokale Dateieinbindung bedeutet, die Website dazu zu bringen, eine Datei zu laden, die sich bereits auf dem Server befindet. Remote Code Execution bedeutet, den Server dazu zu bringen, vom Angreifer ausgewählte Befehle oder Code auszuführen.
Laut Patchstack betrifft die Schwachstelle WordPress Core ab 4.7.0 bis einschließlich 7.1.1. Sie hat einen CVSS-4.0-Score von 9.2 mit dem Vektor AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. CVSS, das Common Vulnerability Scoring System, ist ein Standardverfahren zur Bewertung des Schweregrads von Sicherheitsfehlern. Die Schwachstelle ist als CWE-98 klassifiziert, unsachgemäße Kontrolle eines Dateinamens für eine Include-Anweisung, und wurde CVE-2026-87902 zugewiesen.
Das Risiko ist breiter als bei einem normalen Fehler in einer einzelnen Version, weil jeder Zweig zurück bis WordPress 4.7 betroffen ist, was Patchstack als nahezu ein Jahrzehnt an Veröffentlichungen beschreibt. Für einen Ausnutzungsversuch ist kein Login erforderlich. Diese Kombination ist für Website-Betreiber wichtig, weil öffentlich erreichbare WordPress-Seiten von jedem im Internet erreicht werden können und Schwachstellen, die kein Konto benötigen, in großem Maßstab leichter getestet werden können.
Der anfällige Pfad liegt in der Art, wie WordPress Seiten-Templates auswählt. Wenn WordPress eine Seite rendert, erstellt get_page_template() in wp-includes/template.php mögliche Template-Dateinamen und übergibt sie an den Template-Loader. Ein Kandidat stammte aus der Abfragevariablen pagename, einem Wert aus der Anfrage. In den anfälligen Versionen wurde ein benachbarter Seiten-Template-Slug mit validate_file() geprüft, WordPress’ eigener Prüfung auf unsichere Dateipfad-Traversal, der aus pagename gebildete Dateiname jedoch nicht.
Diese fehlende Prüfung machte nicht jede Datei auf einem Server erreichbar. Der Dateiname wurde in der Form page-{pagename}.php zusammengesetzt, daher musste der Pfad durch ein Verzeichnis führen, das tatsächlich mit page- beginnt, und das eingebundene Ziel musste weiterhin auf .php enden, weil WordPress diese Erweiterung anhängte. Patchstack sagt, die praktische Voraussetzung sei ein aktives Theme mit einem Top-Level-Verzeichnis wie page-templates, ein Muster, das in älteren Standard-Themes und einer Reihe populärer Drittanbieter-Themes vorkommt. Ein zusätzlicher urldecode()-Aufruf, der URL-kodierte Zeichen wieder in ihre normale Form umwandelt, konnte einen traversal-förmigen Slug in einen echten Pfad verwandeln. Patchstack sagt, dass es keine funktionierende Anfrage veröffentlicht.
Der Schritt von der Dateieinbindung zur Remote Code Execution ist an Bedingungen geknüpft. Das Einbinden einer lokalen PHP-Datei, wobei PHP die Programmiersprache ist, auf der WordPress läuft, führt aus, was diese Datei normalerweise tut. Um beliebige Codeausführung zu erreichen, benötigt ein Angreifer eine lesbare .php-Datei auf dem Server, die sich beim Einbinden nützlich verhält. Patchstack nennt PEARs pearcmd.php als den bekannten Kandidaten, sagt jedoch, dass sie nur dann nützlich wird, wenn PHP mit aktiviertem register_argc_argv läuft. register_argc_argv ist eine PHP-Einstellung, die Skripten Argumente im Kommandozeilenstil verfügbar macht.
Diese Einstellung ist in den von Patchstack genannten Umgebungen nicht selten. Sie ist standardmäßig in den offiziellen PHP-Docker-Images und in cPanel-Umgebungen mit PHP unter 8.5 aktiviert. Für Website-Betreiber lautet die praktische Einschätzung daher nicht: „Nur ungewöhnliche Server sind gefährdet.“ Patchstack beschreibt das Problem grundsätzlich als nicht authentifizierte Dateieinbindung und als Codeausführung, wenn der Hosting-Stack entsprechend zusammenkommt. Die Empfehlung lautet, die Schwachstelle als kritisch zu behandeln, sofern der eigene Stack der Website nicht geprüft und bestätigt wurde, dass diese Bedingungen nicht erfüllt sind.
WordPress 7.1.2 brachte zwei relevante Änderungen. Die erste wendet dieselbe validate_file()-Prüfung auf den dekodierten pagename-Pfad an, die der benachbarte Zweig bereits hatte. Die zweite ergänzt mit _wp_is_template_path_allowed() eine breitere Eindämmungsprüfung für jeden aufgelösten Template-Pfad, unabhängig davon, welcher Codepfad ihn erzeugt hat. Wenn ein Dateipfad existiert und keine Parent-Directory-Traversal-Markierung enthält, wird er zugelassen. Andernfalls löst WordPress den echten Pfad auf und verlangt, dass er innerhalb eines erlaubten Theme-Speicherorts liegt: im Stylesheet-Verzeichnis, im Template-Verzeichnis oder in theme-compat.
Diese zweite Änderung ist wichtig, weil sie die Template-Auflösung als eine breitere Risikoklasse behandelt, nicht nur als einen einzelnen fehlenden Validierungsaufruf. Eine einzeilige Validierungsänderung hätte den gemeldeten Pfad adressiert. Die Anforderung, dass jeder aufgelöste Template-Pfad innerhalb erlaubter Theme-Verzeichnisse bleiben muss, fügt dem Template-Ladeprozess selbst eine Sicherheitsgrenze hinzu.
Der Zeitplan ist kompakt. Am 22. September 2026 wurde WordPress 7.1.2 mit zurückportierten Korrekturen für jeden unterstützten Zweig bis hinunter zu 4.7 veröffentlicht. Am selben Datum wurde die Sicherheitsmeldung GHSA-7hp8-65ch-5whp veröffentlicht und CVE-2026-87902 zugewiesen. Patchstack fügte das Problem außerdem seiner Schwachstellendatenbank hinzu und sagt, dass es eine RapidMitigate-Regel auf geschützten Websites bereitgestellt hat, empfiehlt aber weiterhin ein Update auf die neueste verfügbare WordPress-Version.
Website-Betreiber können über das WordPress-Dashboard unter Updates aktualisieren oder die Veröffentlichung direkt von WordPress.org herunterladen. Websites mit aktivierten automatischen Hintergrundupdates sollten die Korrektur bereits erhalten haben. Da das Problem bis WordPress 4.7 zurückreicht, wurden korrigierte Versionen für jeden Zweig veröffentlicht, auf den WordPress noch zurückportiert, sodass ältere Websites die Sicherheitskorrektur ohne Sprung auf eine Hauptversion übernehmen können. Patchstack weist außerdem darauf hin, dass nur die neueste WordPress-Version aktiv unterstützt wird und dass dies weiterhin die Version ist, die Websites anstreben sollten.
Wenn ein sofortiges Update nicht möglich ist, sind die zwei von Patchstack empfohlenen Prüfungen praktische Risikoindikatoren, keine Korrekturen. Prüfen Sie erstens, ob das aktive Theme ein Top-Level-Verzeichnis hat, das mit page- beginnt. Prüfen Sie zweitens, ob PHP register_argc_argv aktiviert hat. Diese Antworten sagen einem Website-Betreiber, wie nah der Server an der Worst-Case-Kette zur Codeausführung ist, ersetzen aber nicht die Installation der korrigierten WordPress-Version. Für Website-Betreiber, die dies nicht allein verwalten möchten, ist AEU Hosting ein verwaltetes WordPress-Hosting, das durchgängig abgesichert ist.