WordPress 7.1.2 behebt unauthentifizierte Dateieinbindung

WordPress 7.1.2 erschien am 22. September 2026 als reine Sicherheitsversion mit einer einzigen Korrektur. Der Sicherheitsanbieter Patchstack nennt sie den schwerwiegendsten WordPress-Patch seit Langem. Die Schwachstelle ist eine unauthentifizierte lokale Dateieinbindung (LFI) bei der Auflösung von Seitentemplates durch WordPress. LFI ist eine Art von Schwachstelle, die es einem Angreifer ermöglicht, eine Webanwendung dazu zu bringen, eine lokale Datei zu öffnen, die nicht zugänglich sein sollte. Diese hier kann zur Ausführung von beliebigem Code aus der Ferne (RCE) führen, was bedeutet, dass ein entfernter Angreifer letztlich eigenen Code auf dem betroffenen Webserver ausführen könnte. Patchstack gibt an, dass seine Kunden durch eine RapidMitigate-Regel geschützt sind, empfiehlt aber dennoch, auf die neueste verfügbare WordPress-Version zu aktualisieren.

Die Schwachstelle wurde von Robert Ressl gemeldet und betrifft den WordPress-Kern von Version 4.7.0 bis Version 7.1.1. Sie hat einen CVSS-4.0-Score von 9.2, eine sehr hohe Schweregradbewertung im Common Vulnerability Scoring System, und ist als CWE-98 klassifiziert, eine Kategorie für die unzureichende Kontrolle des Dateinamens, der in einer Include-Anweisung verwendet wird. Der vollständige CVSS-Vektor lautet AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. CVE-2026-87902 wurde zugewiesen. Da jeder unterstützte Zweig bis zurück zu 4.7 betroffen ist, sind fast zehn Jahre an Veröffentlichungen anfällig, und es ist kein Benutzerkonto erforderlich, um den Angriff zu starten.

Die technische Ursache liegt in der Funktion get_page_template() in wp-includes/template.php. Wenn WordPress eine Seite rendert, erstellt es eine Liste von Kandidaten-Dateinamen für Templates aus der Query-Variable pagename, die direkt aus der Browser-Anfrage stammt. Eine Query-Variable ist eine Information, die in der Webadresse gesendet wird und von WordPress verwendet wird, um zu entscheiden, was angezeigt wird. Neben dem anfälligen Code wurde ein weiterer Kandidat bereits durch validate_file() geleitet, WordPress' eigene Prüfung auf Path Traversal, eine Technik, die versucht, .. in einem Dateinamen zu verwenden, um aus einem vorgesehenen Ordner auszubrechen. Der pagename-Zweig hatte diese Prüfung nicht. Konkret baute WordPress einen Dateinamen in der Form page-{pagename}.php, sodass die Nutzlast eines Angreifers von einem Verzeichnis ausgehen muss, das mit "page-" beginnt, und mit .php enden muss, da die Erweiterung angehängt wird. Die praktische Voraussetzung ist ein aktives Theme mit einem Verzeichnis der obersten Ebene namens page-templates, das ältere Standard-Themes und viele beliebte Drittanbieter-Themes haben. Ein zusätzlicher urldecode-Aufruf ist es, der einen Traversal-förmigen Slug in einen echten Dateisystempfad verwandelt. Patchstack hat keine funktionierende Exploit-Anfrage veröffentlicht.

Eine lokale Dateieinbindung allein garantiert keine Codeausführung. Das Einbinden einer lokalen .php-Datei führt aus, was diese Datei tut, aber um die Kontrolle zu erlangen, benötigt ein Angreifer eine lesbare .php-Datei auf dem Server, die sich beim Einbinden nützlich verhält. Der bekannte Kandidat ist PEARs pearcmd.php, und das wird nur dann nützlich, wenn PHP mit aktiviertem register_argc_argv läuft, einer Einstellung, die Kommandozeilenargumente in PHP-Variablen ablegt. Diese Einstellung ist standardmäßig in offiziellen PHP-Docker-Images aktiviert, bei denen es sich um vorgefertigte Serverumgebungen handelt, sowie in cPanel-Umgebungen, einem beliebten Hosting-Kontrollpanel, bei PHP-Versionen unter 8.5. Dadurch ist die Bedingung häufig statt ungewöhnlich. Die ehrliche Darstellung ist eine bedingte Kette: Unauthentifizierte Dateieinbindung ist unter der richtigen Theme-Bedingung immer möglich, und Codeausführung folgt, wenn die Serverkonfiguration passt. Website-Betreiber sollten dies als kritisch behandeln, es sei denn, sie haben überprüft, dass ihr eigener Stack diese Bedingungen nicht erfüllt.

WordPress lieferte zwei Änderungen in 7.1.2. Erstens wendet es dieselbe validate_file()-Prüfung auf das dekodierte pagename an, bevor der Template-Dateiname erstellt wird. Zweitens, und wichtiger, führt es eine Eindämmungsprüfung in einer neuen Funktion _wp_is_template_path_allowed() ein. Jedes aufgelöste Template muss nun einen Test bestehen: Ein Dateipfad, der existiert und kein .. enthält, ist erlaubt, andernfalls wird der reale Pfad aufgelöst und muss sich im Stylesheet-Verzeichnis, im Template-Verzeichnis oder in theme-compat befinden. Diese zweite Änderung geht über den gemeldeten Fehler hinaus und deutet darauf hin, dass das WordPress-Sicherheitsteam die Auflösung von Template-Pfaden als eine Problemklasse und nicht als Einzelfall behandelt hat.

Der Veröffentlichungszeitplan war komprimiert. Am 22. September 2026 veröffentlichte WordPress 7.1.2 mit zurückportierten Korrekturen für jeden unterstützten Zweig bis hinunter zu 4.7. Am selben Tag wurde der Advisory GHSA-7hp8-65ch-5whp veröffentlicht und CVE-2026-87902 zugewiesen. Patchstack fügte das Problem seiner Schwachstellendatenbank hinzu und stellte eine RapidMitigate-Regel für geschützte Websites bereit. Website-Betreiber sollten über Dashboard > Updates aktualisieren oder von WordPress.org herunterladen. Automatische Hintergrundupdates sollten es bereits angewendet haben. Da Korrekturen zurückportiert wurden, können ältere Websites die Korrektur ohne einen großen Versionssprung übernehmen. Nur die neueste WordPress-Version wird weiterhin aktiv unterstützt, und das ist die Version, auf der man sein sollte.

Wenn Sie nicht sofort aktualisieren können, reduzieren zwei Prüfungen die Unsicherheit: Bestätigen Sie, ob Ihr aktives Theme ein Verzeichnis der obersten Ebene hat, dessen Name mit "page-" beginnt, und bestätigen Sie, ob Ihr PHP register_argc_argv aktiviert hat. Keine der beiden Prüfungen ist eine Lösung, aber sie sagen Ihnen, wie nah Sie am schlimmsten Fall sind. Für Leser, die einen verwalteten WordPress-Host wie AEU Hosting nutzen, ist es sinnvoll, beim Anbieter zu bestätigen, dass dieses Sicherheitsupdate angewendet wurde, da verwaltete Plattformen Kernupdates im Allgemeinen im Hintergrund erledigen.