WordPress 7.1.2: Kritische Sicherheitslücke bei der Auswahl von Seitenvorlagen geschlossen

Management Summary
WordPress 7.1.2 schloss eine kritische Lücke beim Laden von Seitenvorlagen. Unter bestimmten Bedingungen konnte eine Anfrage ohne Anmeldung Programmcode auf dem Webserver ausführen, obwohl die Website unauffällig erschien. Das verdeutlicht den Nutzen regelmäßiger Wartung: Sichtbar funktionierende Seiten belegen keinen Schutz. Maßgeblich sind eine wiederherstellbare Sicherung und die tatsächlich installierte aktuelle offizielle Version. Der Artikel behandelt 7.1.2; inzwischen folgte bereits eine weitere Sicherheitsversion.
Inhalt
WordPress 7.1.2 erschien am 22. September 2026 und schloss eine kritische Sicherheitslücke beim Laden von Seitenvorlagen. Unter bestimmten Voraussetzungen konnte eine Anfrage ohne Anmeldung Code auf dem Server ausführen lassen. Das Update war deshalb auch für Websites wichtig, deren Startseite unauffällig funktionierte. [1]
Einordnung vom 25. Oktober 2026: Diese Meldung beschreibt die Korrektur in 7.1.2. Am 6. Oktober folgte bereits 7.1.3 mit weiteren Sicherheitskorrekturen. Für ein anstehendes Update zählt deshalb die aktuelle offizielle Version, nicht allein die hier behandelte Versionsnummer. [5]
Was die Sicherheitslücke ermöglicht
Ein Theme legt das Aussehen einer WordPress-Website fest. Beim Laden einer Seitenvorlage konnte WordPress unter den im Sicherheitshinweis genannten Bedingungen eine vorhandene PHP-Datei außerhalb der Theme-Ordner einbinden. PHP-Code läuft auf dem Server. Eine solche Fehlleitung konnte deshalb zur Ausführung von Code führen, obwohl keine Anmeldung erfolgt war. Der Sicherheitshinweis trägt die Kennungen CVE-2026-87902 und GHSA-7hp8-65ch-5whp. [2]
Für den beschriebenen Angriff mussten mehrere Bedingungen zusammenkommen: ein bestimmter Ordneraufbau im aktiven Theme und eine geeignete vorhandene PHP-Datei, auf die der Webserver zugreifen konnte. Die Meldung belegt daher keinen bereits erfolgten Angriff auf jede Website. Eine funktionierende Startseite belegt umgekehrt keinen Schutz. Im Versionszweig 7.1 waren 7.1.0 und 7.1.1 betroffen; 7.1.2 enthielt die Korrektur.
Was nach dem Update zu prüfen ist
Vor dem Update braucht es eine Sicherung der Dateien und der Datenbank, aus der sich die Website wiederherstellen lässt. Die offizielle Anleitung beschreibt das Update im Verwaltungsbereich und das manuelle Einspielen der Dateien. [3] Danach sind vier Punkte sinnvoll:
- Die tatsächlich installierte Version jeder Website festhalten, auch bei Testsystemen und selten besuchten Installationen.
- Prüfen, ob die aktuelle offizielle Version erfolgreich installiert wurde. Ein eingeschalteter Update-Schalter allein belegt keinen Abschluss.
- Startseite, normale Seite, Beitrag, Anmeldung und ein wichtiges Formular testen.
- Fehlermeldungen und fehlgeschlagene Updates einzeln bearbeiten.
Was Prüfsummen verraten
WP-CLI ist ein Werkzeug zur Verwaltung von WordPress über die Kommandozeile. Die folgenden Befehle werden im Verzeichnis der betreffenden WordPress-Installation ausgeführt. Der erste zeigt die installierte Version. Der zweite vergleicht WordPress-Kerndateien mit den von WordPress.org veröffentlichten Prüfsummen. Eine Prüfsumme ist ein aus dem Dateiinhalt berechneter Vergleichswert. Abweichungen zeigen, dass eine geprüfte Datei nicht zur Referenz passt. [4]
wp core version
wp core verify-checksums --include-root--include-root meldet zusätzlich unerwartete Dateien und Ordner im Hauptverzeichnis. Bei einer falschen Sprach- oder Versionszuordnung können auch unveränderte Dateien abweichen; dafür unterstützt der Befehl --locale und --version. Der Vergleich lädt die Prüfsummen von WordPress.org und verändert keine geprüften Kerndateien. Ein erfolgreicher Vergleich mit einer alten Version macht diese Version nicht aktuell.
Die Kontrolle untersucht weder die gesamte Datenbank noch Benutzerkonten oder vergangene Angriffe. Auch legitime Zusatzdateien können eine Warnung auslösen. Vor einer Löschung ist deshalb zu klären, woher die Datei stammt und wofür die Website die Datei benötigt. Ein passender Prüfsummenvergleich ist kein umfassender Sicherheitsnachweis.
Fragen und Antworten
Reichen eingeschaltete automatische Updates?
Nein. WordPress unterstützt seit Version 3.7 automatische kleinere Updates und Sicherheitsupdates. Ob ein Update tatsächlich läuft, hängt von Einstellungen und Serverbedingungen ab. [6]
AUTOMATIC_UPDATER_DISABLED,WP_AUTO_UPDATE_COREund Plugin-Filter können automatische Updates abschalten oder begrenzen. Entscheidend ist der jeweilige Wert.- Eine erkannte Versionsverwaltung wie Git oder Subversion blockiert automatische Updates standardmäßig. WordPress sucht entsprechende Ordner auch oberhalb der Installation. Ein Filter kann diese Entscheidung ändern. [7]
- Der Updater braucht Zugriff auf die Dateien ohne eine interaktive Abfrage von Zugangsdaten. Auch Serveranforderungen wie eine passende PHP-Version müssen erfüllt sein. [11]
- WP-Cron führt zeitgesteuerte WordPress-Aufgaben aus. Bei
DISABLE_WP_CRON=trueentfällt der übliche Start über Seitenaufrufe. Ein externer Aufruf vonwp-cron.phpoder eine andere eingerichtete Ausführung der Cron-Ereignisse kann die Aufgaben weiterhin starten. Ohne funktionierenden Auslöser bleiben fällige Aufgaben liegen. [10]
WordPress kann nach einem automatischen Kernupdate eine E-Mail senden. Filter können den Versand abschalten; eine versandte Nachricht muss außerdem nicht im überwachten Postfach ankommen. Die vor Ort geprüfte Versionsnummer und das Updateprotokoll sind deshalb wichtiger als eine erwartete E-Mail. [8]
Was bedeutet die Korrektur für ältere Versionen?
WordPress übertrug diese Korrektur auch auf ältere Versionszweige bis 4.7. Beispielsweise erhielt der 4.7-Zweig die korrigierte Version 4.7.37. Eine solche Rückübertragung heißt Backport: Die einzelne Korrektur wird für einen älteren Programmstand angepasst. Das ist keine Zusage, dass künftig alle Fehler dieser alten Version behoben werden. Laut WordPress wird nur die jeweils neueste Version aktiv unterstützt. Ein Backport ersetzt daher nicht die Planung des vollständigen Upgrades. [1][2]
Lassen sich Plugins auf dieselbe Weise prüfen?
wp plugin verify-checksums --all vergleicht Plugin-Dateien mit verfügbaren Prüfsummen von WordPress.org. Für selbst entwickelte oder anderweitig vertriebene Plugins fehlen dort häufig Vergleichsdaten. Auch bei einem Verzeichnis-Plugin können für eine bestimmte Version keine Prüfsummen vorliegen. Solche Warnungen bedeuten eine offene Prüfung, keine bestätigte Unversehrtheit. [9]
Der Befehl prüft keine Themes. Ohne passende Prüfsummen hilft ein Dateivergleich mit einem vertrauenswürdigen Originalpaket derselben Version. Auch ein passender Vergleich sagt nur etwas über diese Dateien aus, nicht über die Sicherheit der gesamten Website.
Quellen
- WordPress 7.1.2 release, 22 September 2026
- WordPress security advisory GHSA-7hp8-65ch-5whp
- Updating WordPress
- WP-CLI: core verify-checksums
- WordPress 7.1.3: 6 October 2026
- WordPress: Configuring Automatic Background Updates
- WP_Automatic_Updater::is_vcs_checkout
- WP_Automatic_Updater::send_email
- WP-CLI: plugin verify-checksums
- WordPress: WP-Cron and system scheduling
- WP_Automatic_Updater::should_update