Aktuelles

Irgendwas ist ja immer: WordPress Version 7.1.2 erschienen - und die sollte tunlichst installiert werden!

Lass mich rein, lass mich raus

Mit Version 7.1.2 hat das WordPress-Team am 22. September eine durchaus heftige Sicherheitslücke dichtgemacht und die Beschreibung liest sich harmloser, als sie es eigentlich ist.

„Ein Sicherheitsfix." Klingt nach Routine, ist es aber nicht. Dahinter steckt eine Schwachstelle, die ohne Benutzerkonto, ohne Passwort, ohne irgendeinen Fuß in der Tür fremden Code auf dem Server ausführen kann (wie oft denn noch?) - unter den richtigen Umständen natürlich. Und die richtigen Umstände sind erschreckend gewöhnlich.

Was genau kaputt war

Der Kern sitzt in wp-includes/template.php, in der Funktion get_page_template(). Die baut, wenn WordPress eine Seite rendert, eine Liste möglicher Template-Dateien und reicht sie an den Loader weiter. Einer dieser Kandidaten entsteht direkt aus dem pagename aus der Anfrage, also aus dem, was der Besucher schickt.

Robert Ressl hat's gefunden und gemeldet, was da schiefläuft: Der Slug wird zu "page-{$pagename}.php" zusammengesetzt. Ein zusätzlicher urldecode()-Aufruf macht aus einem als Traversal getarnten Slug einen echten Pfad. Und während der erste Template-Kandidat sauber durch validate_file() läuft (das ist WordPress' eigene Traversal-Bremse), rutscht der zweite ungeprüft durch. Die Schutzfunktion existierte zwar, stand aber an der falschen Stelle.

Das Advisory trägt die Kennung CVE-2026-87902 und ist als CWE-98 klassifiziert: unsaubere Kontrolle eines Dateinamens in einer include-Anweisung. Der CVSS-4.0-Wert liegt bei 9.2 das ist kritisch. Betroffen ist WordPress-Core von 4.7.0 bis einschließlich 7.1.1. Das sind fast zehn Jahre Releases!

Von „Datei eingebunden" bis zu „Server übernommen"

Eine lokale .php-Datei einzubinden, ist noch keine freie Codeausführung. Es läuft nur das, was in dieser Datei steht. Der Weg zum echten Schaden braucht zwei Bausteine, die zufällig zusammenpassen müssen und viel zu oft tun sie das.

Erstens: Das aktive Theme muss ein Verzeichnis auf oberster Ebene mitbringen, das mit page- beginnt – etwa page-templates. Ältere Standard-Themes haben so etwas, diverse populäre Fremd-Themes ebenfalls (wir nennen keine Namen!). Zweitens: Auf dem Server muss eine lesbare .php-Datei liegen, die beim Einbinden etwas Nützliches tut. Der Klassiker ist PEARs pearcmd.php – und die wird zur Waffe, sobald PHP mit aktiviertem register_argc_argv läuft.

Und jetzt kommt der Teil, bei dem man kurz die Kaffeetasse abstellt: Diese Einstellung ist in den offiziellen PHP-Docker-Images standardmäßig an. In cPanel-Umgebungen mit PHP unter 8.5 auch. „Ungewöhnliche Konfiguration" wäre also glatt gelogen. Die ehrliche Formulierung lautet: Dateieinbindung ohne Login immer, Codeausführung immer dann, wenn der Host zufällig passt. Und davon gibt es wahrscheinlich Abertausende.

Warum der Fix mehr macht, als er müsste

WordPress hat zwei Dinge geändert. Das erste ist die naheliegende Ein-Zeilen-Korrektur: Auch der aus pagename_decoded gebaute Kandidat läuft jetzt durch validate_file(), bevor er akzeptiert wird. Reparatur erledigt.

Das zweite ist interessanter. 7.1.2 führt zusätzlich eine neue Funktion _wp_is_template_path_allowed() ein, die jeder aufgelöste Template-Pfad passieren muss, ganz egal, welcher Codepfad ihn erzeugt hat. Der Pfad muss innerhalb des Stylesheet-Verzeichnisses, des Template-Verzeichnisses oder von theme-compat landen, sonst fliegt er raus.

Für den gemeldeten Bug hätte die eine Zeile gereicht. Dass das Security-Team trotzdem eine Rundum-Schranke eingezogen hat, sagt etwas: Sie behandeln Template-Auflösung als Problemklasse, nicht als Einzelfall. Übersetzt heißt das, sie waren sich nicht sicher, ob der gemeldete Pfad der einzige war. Vorsicht statt Optimismus. Genau richtig.

Die Versionslage auf einen Blick

Was	Detail
Aktuelle Version	WordPress 7.1.2 (veröffentlicht 22.09.2026)
Art des Releases	Reines Sicherheitsupdate, ein einziger Fix
Kennung	CVE-2026-87902 / GHSA-7hp8-65ch-5whp
Schwachstellentyp	Unauthentifizierter Path Traversal / Local File Inclusion ? bedingte RCE (CWE-98)
Schweregrad	CVSS 4.0: 9.2 (kritisch)
Betroffen	Core 4.7.0 bis einschließlich 7.1.1
Gemeldet von	Robert Ressl
Geänderte Datei	wp-includes/template.php
Backports	Alle unterstützten Branches zurück bis 4.7

Was Sie heute tun sollten, nicht erst beim nächsten Wartungsfenster

Update auf 7.1.2. Sofort. Über Dashboard > Aktualisierungen oder direkt von WordPress.org. Wer automatische Hintergrund-Updates aktiviert hat, sollte den Fix schon haben, ein kurzer Blick auf die Versionsnummer schadet trotzdem nicht.

Das Schöne an diesem Release: Weil die Lücke bis 4.7 zurückreicht, hat WordPress für jeden noch gepflegten Branch eine korrigierte Version herausgegeben. Eine ältere Installation kann den Fix also einsammeln, ohne gleich einen Major-Sprung zu wagen. Keine Ausrede!

Und wenn Sie (aus welchen Gründen auch immer) nicht sofort updaten können? Dann prüfen Sie wenigstens zwei Dinge, um zu wissen, wie nah Sie am Worst Case stehen: Hat Ihr aktives Theme ein Verzeichnis auf oberster Ebene, das mit page- anfängt? Und läuft Ihr PHP mit register_argc_argv? Keins von beidem ist ein Fix. Aber beides sagt Ihnen, ob Sie auf einem Sofa oder auf einem Stapel Streichhölzer sitzen.

Die gute Nachricht: Website-Betreiber mit einem TAGWORX-Wartungsvertrag haben alle aktuellen Updates bereits und müssen sich keine Sorgen machen.

Die eigentliche Lehre steckt in drei Zeilen Abstand

Diese Lücke war kein exotischer Zero-Day mit Raketenwissenschaft dahinter. Es war eine fehlende Prüfung, drei Zeilen neben genau der Prüfung, die man gebraucht hätte. Zehn Jahre lief das mit, durch unzählige Reviews, unzählige Releases. Sicherheit scheitert selten am fehlenden Wissen. Sie scheitert daran, dass die richtige Schranke an der einen Stelle vergessen wird, wo sie zählt. Wer WordPress-Seiten betreut, kennt das Gefühl und weiß deshalb: Der Patch ist die halbe Miete. Die andere Hälfte ist, ihn eingespielt zu haben, bevor jemand anders die drei Zeilen findet.

22.09.2026