Foto von GuerrillaBuzz auf Unsplash
Zwei Sicherheitsupdates in fünf Tagen, das kommt bei WordPress selten vor. Am 17. September 2026 erschien 7.1.1 mit elf Sicherheitsfixes, am 22. September folgte 7.1.2 mit einem einzigen. Der zweite wiegt schwerer, weil er ohne Login funktioniert.
Ich fasse zusammen, was in beiden Updates steckt, wann deine Webseite wirklich angreifbar war und was jetzt zu tun ist.
Was WordPress 7.1.2 repariert
WordPress 7.1.2 ist ein reines Sicherheitsrelease und schließt genau eine Lücke: CVE-2026-87902, eingestuft mit CVSS 9.2 von 10 und damit kritisch. Gemeldet hat sie Robert Ressl.
Betroffen sind alle WordPress-Versionen ab 4.7, also der Bestand aus fast zehn Jahren. Entsprechend breit hat das Sicherheitsteam nachgereicht: Es gibt Backports bis hinunter zu 4.7.37, dazu gepatchte Fassungen für jeden dazwischenliegenden Zweig bis 7.0.6.
Die kritische Lücke CVE-2026-87902
WordPress nimmt die beiden Parameter pagename und page_id aus einer anonymen Anfrage entgegen. Kein Login, kein Klick im Backend.
Der Fehler steckt in der Reihenfolge: Eine doppelt URL-kodierte Pfadangabe überlebt die frühe Prüfung, weil die kodierten Trennzeichen zu diesem Zeitpunkt keine Trennzeichen sind. Erst später ruft get_page_template() ein urldecode() auf, und dann werden sie es. Damit lässt sich aus dem Theme-Verzeichnis herausnavigieren und eine beliebige lesbare PHP-Datei einbinden, beschrieben vom Entdecker selbst.
Aus einer eingebundenen Datei wird eine Codeausführung, wenn der bekannte Weg über pearcmd.php offensteht. Dann kann ein Angreifer eigene PHP-Dateien auf dem Server ablegen.
Wann deine WordPress-Webseite angreifbar ist
Die Lücke ist an Bedingungen geknüpft, und die müssen alle gleichzeitig zutreffen:
- Dein aktives Theme hat im Hauptverzeichnis einen Ordner, dessen Name mit
page-beginnt, typischerweisepage-templates - Es gibt eine veröffentlichte Seite, die über
page_idansprechbar ist - Dieser Seite ist kein eigenes Seitentemplate zugewiesen
- Auf dem Server liegt eine lesbare PHP-Datei außerhalb des Themes
- In der PHP-Konfiguration steht
register_argc_argvaufOn - Die
pearcmd.phpist über das Web erreichbar - Es gibt ein beschreibbares Verzeichnis für die abgelegte Datei
Das klingt nach viel, trifft in der Praxis aber öfter zu, als einem lieb ist. register_argc_argv ist in den Standard-Images von PHP unter Docker und in vielen cPanel-Installationen aktiv, ohne dass es jemand bewusst eingeschaltet hätte.
Der CVSS-Wert bildet das ab: Die 9.2 nach Version 4.0 des Standards enthält bereits den Zusatz für erschwerte Angriffsbedingungen. Kritisch bleibt sie trotzdem.
Welche Themes betroffen sind
Die Standard-Themes der letzten Jahre sind es nicht. Twenty Twenty-Three, Twenty Twenty-Four und Twenty Twenty-Five hatten in der untersuchten Fassung keinen Ordner, der auf das Muster passt.
Anders sieht es bei den älteren aus: Twenty Twelve und Twenty Fourteen bringen einen mit. Dazu kommen weit verbreitete Themes von Drittanbietern, das Sicherheitsteam nennt unter anderem Neve und Hestia.
Du kannst das selbst nachsehen. Öffne per FTP oder Dateimanager wp-content/themes/dein-theme/ und schau, ob dort ein Ordner steht, der mit page- beginnt. Ein Unterordner an anderer Stelle zählt nicht, es geht um die oberste Ebene.
Seit wann die Lücke ausgenutzt wird
Am selben Tag, an dem 7.1.2 erschien. Patchstack sah die ersten Anfragen um 11:49 UTC am 22. September.
Der Ablauf war typisch. Zuerst tastete eine kleine Gruppe von Adressen ab, ob ein Server überhaupt reagiert. Dafür wurde eine harmlose Datei eingebunden, wp-links-opml.php, die in jeder Installation liegt. Wer antwortet, landet auf einer Liste.
Innerhalb von 24 Stunden folgte der zweite Schritt: echte Ausnutzung über pearcmd.php mit dem Ziel, eine Datei zu schreiben. Aus der Handvoll Adressen wurden am Folgetag einige hundert, das Anfragevolumen lag um mehr als das Zehnfache höher.
Ein funktionierender Nachweis ist öffentlich. Das ist der Punkt, ab dem eine Lücke nicht mehr nur theoretisch ist.
Die elf Sicherheitsfixes in WordPress 7.1.1
7.1.1 war das größere Paket, aber das harmlosere. Neben 17 Fehlerkorrekturen im Kern und 19 im Block-Editor stecken elf Sicherheitsfixes darin:
| Was behoben wurde | Wer es ausnutzen konnte |
|---|---|
Gespeichertes Cross-Site-Scripting in wpautop() über Kommentare | Besucher, nach Freigabe des Kommentars |
| Ausbruch aus Kommentaren in der HTML-API | Besucher |
| Gespeichertes Cross-Site-Scripting in Themes mit eigenem Kopfbereich | Besucher |
| Präparierte URLs installieren und zeigen ein inaktives Theme | Besucher |
| Netzwerkweite Aktivierung von Plugins durch Seiten-Administratoren | Administrator einer Unterseite |
| Pfaddurchquerung im REST-Controller für Templates | angemeldetes Konto |
Umgehung der edit_css-Prüfung über XML-RPC | angemeldetes Konto |
| Überschreiben fremder Beiträge | Mitarbeiter und höher |
| Titel privater Beiträge auslesbar | angemeldetes Konto |
| Slugs von Entwürfen auslesbar | Mitarbeiter und höher |
| Kommentare und Notizen umhängen | jedes angemeldete Konto |
Der Unterschied zur Lücke aus 7.1.2 ist die Hürde. Sieben der elf setzen ein Konto auf deiner Webseite voraus. Für einen Onlineshop mit Kundenkonten oder eine Webseite mit mehreren Redakteuren ist das eine echte Einschränkung, für eine Firmenwebseite mit einem einzigen Zugang weniger.
Was du jetzt an deiner WordPress-Webseite tun solltest
- Version nachsehen. Im Dashboard unten rechts oder unter Dashboard, Aktualisierungen. Steht dort etwas unterhalb von 7.1.2, ist heute der Tag.
- Vor dem Update ein Backup anlegen. Eines, das du schon einmal zurückgespielt hast.
- Aktualisieren. Über das Dashboard, oder auf einem älteren Zweig die passende Backport-Version.
- Theme prüfen. Ordner mit
page-im Hauptverzeichnis des aktiven Themes. - Protokolle durchsehen, wenn die Webseite länger auf einer verwundbaren Version stand. Gesucht sind Anfragen mit
page_idundpagenamegleichzeitig, wobei impagenamekodierte Punktfolgen wie%2e%2estehen. register_argc_argvabschalten, falls dein Hoster das zulässt. Für eine Webseite braucht es die Einstellung nicht.
Findest du Treffer in den Protokollen, reicht das Update nicht mehr. Dann gehört die Installation durchgesehen, wie in WordPress gehackt, was tun beschrieben.
Warum automatische Updates allein nicht reichen
WordPress verteilt Sicherheitsreleases im Hintergrund, und in den meisten Installationen kommt 7.1.2 damit von selbst an. Darauf verlassen würde ich mich nicht.
Automatische Updates lassen sich in der wp-config.php abschalten, und genau das passiert oft nach einem Update, das etwas kaputtgemacht hat. Manche Hoster und Sicherheits-Plugins greifen zusätzlich ein. Steht das Dateisystem auf schreibgeschützt, läuft der Mechanismus ins Leere und meldet das niemandem. Wie du das sauber einstellst, steht im Beitrag zu den automatischen WordPress-Updates.
Nachsehen dauert zehn Sekunden: Dashboard, Aktualisierungen.
Meine Wartungskunden haben das Update schon
Die von mir betreuten Webseiten stehen auf 7.1.2. Bei einem kritischen Release mit öffentlichem Nachweis warte ich keinen Wartungstermin ab, sondern spiele es am selben Tag ein, nach einer Sicherung und mit anschließender Funktionsprüfung.
Genau dafür gibt es die WordPress-Wartung: Wann ein Sicherheitsupdate erscheint, bestimmen die Entwickler. Zwei Releases in fünf Tagen passen in keinen Kalender, den man sich vorher zurechtlegt.
Mein Fazit zu den WordPress-Updates
7.1.1 war Routine, elf Lücken mit überschaubarer Reichweite. 7.1.2 ist etwas anderes: Eine Schwachstelle, die ohne Login funktioniert, seit zehn Jahren im Code steckt und binnen Stunden nach der Veröffentlichung angegriffen wurde.
Die gute Nachricht steckt in den Bedingungen. Viele Webseiten waren nie ausnutzbar, weil das Theme keinen passenden Ordner hat oder register_argc_argv aus ist. Das weißt du aber erst, wenn du nachgesehen hast, und bis dahin ist das Update der schnellere Weg.
Wenn du bei deiner Webseite unsicher bist, schreib mir kurz. Ein Blick auf die Version und das Theme dauert fünf Minuten.
Quellen
- WordPress 7.1.2 Security Release
- WordPress 7.1.1 Maintenance and Security Release
- GHSA-7hp8-65ch-5whp: Page template resolution can include arbitrary local PHP files
- CVE-2026-87902: Critical WordPress file inclusion and conditional RCE
- CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch
Häufige Fragen zu den WordPress-Sicherheitslücken
Muss ich sofort auf WordPress 7.1.2 aktualisieren?
Ja. Die Lücke wird seit dem Tag der Veröffentlichung angegriffen, und ein funktionierender Nachweis ist öffentlich. Steht deine Webseite auf einer älteren Version als 7.1.2, ist das Update der erste Punkt auf der Liste. Wer auf einem älteren Zweig bleibt, nimmt die passende Backport-Version, WordPress hat bis hinunter zu 4.7.37 gepatcht.
Woran erkenne ich, ob meine Webseite angreifbar war?
Die Lücke greift nur, wenn dein aktives Theme im Hauptverzeichnis einen Ordner hat, dessen Name mit „page-" beginnt, etwa „page-templates". Dazu müssen auf dem Server register_argc_argv aktiv und eine lesbare PHP-Datei außerhalb des Themes erreichbar sein. Trifft nur eine dieser Bedingungen nicht zu, war deine Webseite nicht ausnutzbar. Aktualisieren solltest du trotzdem.
Sind die Standard-Themes von WordPress betroffen?
Twenty Twenty-Three, Twenty Twenty-Four und Twenty Twenty-Five haben in der untersuchten Fassung keinen passenden Ordner und sind damit nicht ausnutzbar. Twenty Twelve und Twenty Fourteen dagegen schon, ebenso verbreitete Themes von Drittanbietern wie Neve und Hestia.
Reichen automatische Updates aus?
Für den Kern in den meisten Fällen ja, WordPress verteilt Sicherheitsreleases automatisch. Verlassen solltest du dich nicht darauf: Automatische Updates lassen sich in der wp-config.php abschalten, manche Hoster und Sicherheits-Plugins greifen ein, und bei einem gesperrten Dateisystem laufen sie ins Leere. Nachsehen dauert zehn Sekunden, unter Dashboard, Aktualisierungen.
Was war in WordPress 7.1.1 enthalten?
Elf Sicherheitsfixes, dazu 17 Fehlerkorrekturen im Kern und 19 im Block-Editor. Die Sicherheitslücken reichten von gespeichertem Cross-Site-Scripting über Rechteprobleme bis zum Auslesen privater Beitragstitel. Keine davon war als kritisch eingestuft, mehrere setzen ein Konto auf deiner Webseite voraus.
Was kann ein Angreifer über CVE-2026-87902 anrichten?
Im ersten Schritt lässt sich eine beliebige lesbare PHP-Datei vom Server einbinden. Sind die weiteren Bedingungen erfüllt, wird daraus die Ausführung eigenen Codes. Von dort ist alles möglich: eine hinterlegte Hintertür, Zugangsdaten aus der Datenbank, neue Administratorkonten, umgeleitete Besucher.
Ich nutze ein Sicherheits-Plugin, reicht das?
Eine Firewall kann die bekannten Anfragemuster blocken und verschafft dir Zeit. Sie ersetzt das Update nicht, weil sie nur filtert, was sie kennt. Die Lücke selbst bleibt offen, bis der Kern aktualisiert ist.
Wie merke ich, ob jemand es bei mir versucht hat?
In den Zugriffsprotokollen deines Hostings. Gesucht wird nach Anfragen, die gleichzeitig page_id und pagename enthalten, wobei im pagename kodierte Punktfolgen wie %2e%2e stehen. Findest du Treffer und stand deine Webseite auf einer verwundbaren Version, gehört sie geprüft.
