WordPress 7.1.2: Zweites Sicherheitsupdate innert einer Woche

Zwei Sicherheitsreleases in fünf Tagen

Für WordPress-Administratoren war es eine intensive Woche. Am 17. September 2026 erschien WordPress 7.1.1, ein kombiniertes Wartungs- und Sicherheitsupdate mit 17 Core-Fixes, 19 Korrekturen für den Block-Editor und 11 Sicherheitskorrekturen. Nur fünf Tage später folgte mit 7.1.2 bereits das nächste Release, diesmal ausschliesslich zur Behebung einer einzelnen, als kritisch eingestuften Schwachstelle.

Wichtig: Die in 7.1.2 behobene Lücke ist unabhängig von den Fehlern, die 7.1.1 geschlossen hat. Wer 7.1.1 bereits eingespielt hat, muss erneut aktualisieren.

Rückblick: Was WordPress 7.1.1 behoben hat

Das Release vom 17. September adressierte unter anderem folgende Schwachstellen:

• Stored Cross-Site-Scripting (XSS) in wpautop(), das nicht authentifizierten Besuchern das Einschleusen von Skripten ermöglicht (abhängig von der Kommentarfreigabe)
• Präparierte URLs, über die ein inaktives Theme aus dem WordPress.org-Verzeichnis automatisch installiert und in der Vorschau geladen werden kann
• Authenticated Path Traversal im REST Templates Controller
• Überschreiben beliebiger Beiträge durch Benutzer ab der Rolle «Contributor»
• Umgehung der edit_css-Prüfung via XML-RPC

Sicherheitsforscher von pwn.ai haben die Theme-Preview-Schwachstelle unter dem Namen «Click2Shell» beschrieben. Nach ihrer Darstellung lässt sie sich zu einer Angriffskette ausbauen, die mit einem einzigen Klick zur Codeausführung führt.

CVE-2026-87902 im Detail

Die Schwachstelle

Ursache ist eine unzureichende Kontrolle von Dateinamen in PHP-Include-Anweisungen, klassifiziert als CWE-98 («Improper Control of Filename for Include/Require Statement»). Konkret betrifft sie die Funktion get_page_template(), mit der WordPress die passende Seitenvorlage ermittelt.

Ein Angreifer kann beim Aufruf nicht nur die vorgesehene Vorlage laden lassen, sondern zusätzlich beliebige PHP-Dateien einbinden, die ausserhalb des eigentlich zuständigen Theme-Verzeichnisses auf dem Server liegen. Da sich Speicherort und Dateiname vorhandener PHP-Dateien in einer WordPress-Installation meist gut erraten lassen, ist die Hürde für Angreifer gering. Im Ergebnis kann die Lücke zur Ausführung von Code auf dem Zielsystem führen (Remote Code Execution).

Der Fix beschränkt sich auf eine einzige Datei: wp-includes/template.php.

Voraussetzung: Vorlagen in einem «page-»-Verzeichnis

Nicht jede WordPress-Installation ist gleichermassen angreifbar. Eine Ausnutzung setzt voraus, dass die verwendete Seitenvorlage in einem Verzeichnis liegt, dessen Name mit page- beginnt. Das ist allerdings keine Seltenheit: Viele Themes legen ihre Seitenvorlagen in einem Unterordner wie page-templates/ ab. Betroffen sind etwa die WordPress-eigenen Standard-Themes Twenty Twelve und Twenty Fourteen sowie verschiedene populäre Themes externer Anbieter.

Ob Ihre Themes eine solche Struktur aufweisen, prüfen Sie auf der Kommandozeile mit:

find wp-content/themes -maxdepth 2 -type d -name 'page-*'

Ein Treffer bedeutet nicht zwingend eine Kompromittierung, zeigt aber, dass die Installation grundsätzlich angreifbar ist. Umgekehrt ist ein leeres Ergebnis kein Grund, auf das Update zu verzichten.

Entdeckt von einem Schweizer Sicherheitsforscher

Aufgedeckt und verantwortungsvoll an das WordPress-Sicherheitsteam gemeldet hat die Schwachstelle der Schweizer Robert Ressl. Das Beispiel zeigt, wie wichtig Responsible Disclosure für das Open-Source-Ökosystem ist: Die Lücke wurde geschlossen, bevor Details breit öffentlich wurden, und die Betreiber erhalten den Fix über den regulären Update-Mechanismus.

Eckdaten auf einen Blick

Welche Version Sie benötigen

Massgebend ist der Versionszweig, den Sie aktuell betreiben:

Beachten Sie: Aktiv gepflegt wird ausschliesslich die aktuelle Hauptversion. Die Backports für ältere Zweige erfolgen aus Kulanz. Installationen auf 7.0.x oder älter sollten den Wechsel auf 7.1.x daher zeitnah einplanen. Versionen vor 4.7 erhalten keine Sicherheitsupdates mehr und sollten nicht mehr produktiv betrieben werden.

Was Sie jetzt tun sollten

1. Installierte Version prüfen

Im Dashboard finden Sie die Version unter «Dashboard → Aktualisierungen». Bei mehreren Installationen ist WP-CLI deutlich effizienter:

wp core version
wp core check-update

Wer viele Instanzen verwaltet, sollte die Abfrage per Skript über alle Webroots laufen lassen, um veraltete Installationen systematisch zu identifizieren.

2. Update einspielen

Websites mit aktivierten automatischen Hintergrund-Updates installieren den Fix selbstständig. Verlassen Sie sich trotzdem nicht blind darauf, sondern prüfen Sie die tatsächlich installierte Version.

Manuell aktualisieren Sie über das Dashboard oder per WP-CLI:

wp core update

Wenn Sie innerhalb Ihres aktuellen Versionszweigs bleiben möchten, etwa weil ein Plugin noch nicht mit 7.1 kompatibel ist, spielen Sie nur das Minor-Release ein:

wp core update --minor

Erstellen Sie vor dem Update ein aktuelles Backup von Dateien und Datenbank. Bei reinen Sicherheitsreleases ist das Kompatibilitätsrisiko gering, ein Restore-Punkt gehört im professionellen Betrieb aber zum Standard.

3. Automatische Core-Updates kontrollieren

Seit WordPress 3.7 werden Minor- und Sicherheitsreleases standardmässig automatisch installiert. Diese Funktion wird jedoch häufig bewusst oder versehentlich deaktiviert. Prüfen Sie Ihre wp-config.php auf folgende Einträge:

• AUTOMATIC_UPDATER_DISABLED auf true deaktiviert sämtliche automatischen Updates.
• WP_AUTO_UPDATE_CORE auf false deaktiviert Core-Updates.
• WP_AUTO_UPDATE_CORE auf 'minor' entspricht dem empfohlenen Standardverhalten.

Auch Plugins oder Must-Use-Plugins können Auto-Updates über Filter wie auto_update_core unterbinden. Wer Updates bewusst über ein Deployment-Verfahren steuert, braucht einen Prozess, der kritische Releases innert Stunden ausrollt, nicht erst beim nächsten Wartungsfenster.

4. Nach dem Update: Kurztest und Log-Analyse

Kontrollieren Sie nach der Aktualisierung die wichtigsten Seitentypen, Formulare und Checkout-Prozesse. Werfen Sie zusätzlich einen Blick in die Access-Logs: Auffällige Requests mit Path-Traversal-Mustern (../) können auf Ausnutzungsversuche vor dem Patch hindeuten. Bei Verdacht auf eine Kompromittierung reicht das Update allein nicht aus. Dann sind eine Integritätsprüfung der Core-Dateien (wp core verify-checksums) sowie eine Suche nach unbekannten PHP-Dateien in Upload- und Theme-Verzeichnissen angezeigt.

Härtung: Angriffsfläche dauerhaft reduzieren

Beide Releases dieser Woche betreffen die Art, wie WordPress Themes und Vorlagen lädt. Neben zeitnahen Updates reduzieren folgende Massnahmen das Risiko solcher Schwachstellenklassen:

PHP-Ausführung in Upload-Verzeichnissen unterbinden

Eine File-Inclusion-Lücke wird besonders gefährlich, wenn ein Angreifer eine eigene PHP-Datei auf dem Server platzieren kann. Unterbinden Sie die PHP-Ausführung in wp-content/uploads per Webserver-Konfiguration (Apache .htaccess bzw. Nginx-Location-Block).

Dateisystemzugriff von PHP einschränken

Mit open_basedir begrenzen Sie die Verzeichnisse, auf die PHP zugreifen darf. Das verhindert nicht jede Inclusion innerhalb des erlaubten Bereichs, erschwert aber das Einbinden von Dateien ausserhalb des Webroots erheblich.

Ungenutzte Themes und Plugins entfernen

Jedes installierte, aber inaktive Theme ist potenzielle Angriffsfläche. Das gilt gerade für ältere Standard-Themes wie Twenty Twelve oder Twenty Fourteen, die auf vielen Installationen aus Gewohnheit liegen bleiben. Behalten Sie neben dem aktiven Theme höchstens ein aktuelles Standard-Theme als Fallback.

Restriktive Dateiberechtigungen

Der Webserver-Benutzer sollte nur dort Schreibrechte besitzen, wo es zwingend nötig ist. Setzen Sie bei Bedarf DISALLOW_FILE_EDIT bzw. DISALLOW_FILE_MODS in der wp-config.php.

Web Application Firewall

Eine WAF kann bekannte Angriffsmuster wie Path-Traversal-Sequenzen abfangen, bevor sie die Anwendung erreichen, und verschafft Ihnen im Ernstfall wertvolle Zeit zwischen Bekanntwerden einer Lücke und dem Einspielen des Patches.

Das Update-Tempo nimmt zu

Die Häufung ist bemerkenswert. Allein seit Juli 2026 hat WordPress mehrere Sicherheitsreleases veröffentlicht:

Für Betreiber bedeutet das: Ein monatlicher Update-Rhythmus reicht nicht mehr aus. Sicherheitsupdates müssen als laufender Betriebsprozess verstanden werden, idealerweise automatisiert und mit Monitoring abgesichert. Dasselbe gilt für Plugins und Themes, die separat gepflegt werden müssen.

Rechtlicher Rahmen in der Schweiz

Für Schweizer Unternehmen ist das Thema nicht nur eine technische Frage. Das revidierte Datenschutzgesetz (revDSG) verpflichtet Verantwortliche in Art. 8 dazu, durch geeignete technische und organisatorische Massnahmen eine dem Risiko angemessene Datensicherheit zu gewährleisten. Das zeitnahe Einspielen bekannter Sicherheitspatches gehört dazu.

Kommt es infolge einer ungepatchten Lücke zu einer Verletzung der Datensicherheit, die voraussichtlich zu einem hohen Risiko für die betroffenen Personen führt, besteht gemäss Art. 24 DSG eine Meldepflicht gegenüber dem EDÖB. Wer über seine WordPress-Website Kontaktformulare, Kundenkonten oder einen Shop betreibt, sollte seinen Patch-Prozess entsprechend dokumentieren.

Welche Hosting-Umgebung zu Ihrem Update-Prozess passt

Wie schnell eine Lücke wie CVE-2026-87902 geschlossen wird, hängt auch davon ab, wer in Ihrer Umgebung für welche Ebene zuständig ist. Beim Hosting und WordPress Hosting von METANET wird die Serverumgebung für Sie betreut, während Core, Themes und Plugins in Ihrer Verantwortung bleiben. Ein VPS gibt Ihnen Root-Zugriff für eigene Härtungsmassnahmen wie open_basedir oder eine WAF, ein Managed Cloud Server nimmt Ihnen die Pflege der Systemebene ab. Für grössere WordPress-Landschaften mit getrennten Staging- und Produktivumgebungen bietet sich ein Virtual Data Center an, in dem sich Updates isoliert testen und kontrolliert ausrollen lassen.

FAQ

Ist meine Website betroffen, wenn ich bereits WordPress 7.1.1 installiert habe?

Ja. CVE-2026-87902 betrifft alle Versionen von 4.7.0 bis einschliesslich 7.1.1. Die Lücke wurde erst mit 7.1.2 bzw. den entsprechenden Backports geschlossen.

Muss ein Angreifer eingeloggt sein, um die Lücke auszunutzen?

Nein. Die Schwachstelle lässt sich ohne Benutzerkonto und ohne Interaktion eines angemeldeten Benutzers ausnutzen. Deshalb ist sie als kritisch eingestuft.

Welche Themes sind besonders gefährdet?

Angreifbar sind Installationen, deren Seitenvorlagen in einem Verzeichnis liegen, dessen Name mit page- beginnt, etwa page-templates/. Das betrifft unter anderem Twenty Twelve und Twenty Fourteen sowie diverse Themes externer Anbieter.

Wie prüfe ich, ob mein Theme diese Struktur hat?

Auf der Kommandozeile finden Sie entsprechende Verzeichnisse mit find wp-content/themes -maxdepth 2 -type d -name 'page-*'. Unabhängig vom Ergebnis sollten Sie das Update einspielen.

Wird WordPress 7.1.2 automatisch installiert?

Ja, sofern automatische Hintergrund-Updates aktiv sind. Prüfen Sie dennoch die installierte Version, da Auto-Updates in der wp-config.php oder durch Plugins deaktiviert sein können.

Ich nutze noch WordPress 6.x. Muss ich sofort auf 7.1 wechseln?

Für den akuten Schutz genügt das Backport-Release Ihres Zweigs, zum Beispiel 6.9.9 für 6.9.x. Da nur die aktuelle Hauptversion aktiv gepflegt wird, sollten Sie den Umstieg auf 7.1.x aber zeitnah planen.

Schützt ein Core-Update auch vor Lücken in Plugins und Themes?

Nein. Core-Updates betreffen ausschliesslich den WordPress-Kern. Plugins und Themes werden separat aktualisiert und müssen ebenso konsequent gepflegt werden.