Das Wichtigste in Kürze
- WordPress 7.1.1 erschien am 17. September 2026 mit 11 Sicherheitsfixes, 17 Bugfixes im Core und 21 im Block-Editor.
- Nachtrag vom 22. September 2026: Am selben Tag erschien WordPress 7.1.2 mit einer weiteren, kritischen Lücke ohne Login. Maßstab ist damit 7.1.2 oder die passende Backport-Version.
- Minor-Updates wie dieses installiert WordPress seit Version 3.7 standardmäßig selbst. Viele Seiten laufen bereits auf 7.1.1.
- Genau eine der elf Lücken funktioniert ohne Login: eine gespeicherte XSS-Lücke über das Kommentarformular, die erst greift, wenn der Kommentar veröffentlicht ist.
- Eine zweite Lücke, von den Findern „Click2Shell“ genannt, braucht einen eingeloggten Administrator, der eine präparierte Adresse aufruft.
- WordPress hat die Fixes bis zurück auf Version 4.7 zurückportiert. Version 4.6 und älter bekommen nichts mehr.
- Nachtrag vom 25. September 2026: Die Lücke aus 7.1.2 wird laut Patchstack seit dem 23. September aktiv ausgenutzt. Wer erst danach aktualisiert hat, sollte Protokolle und Server auf Spuren prüfen.
Am 17. September 2026 kam WordPress 7.1.1, ein Sicherheits- und Wartungsrelease mit elf Sicherheitsfixes. Die übliche Schlagzeile dazu lautet „sofort aktualisieren“. Für die meisten Firmenwebsites ist dieser Schritt längst erledigt, und zwar ohne dass jemand etwas getan hätte.
Interessant ist deshalb die Frage danach. Zwei der elf Lücken brauchen kein Angreifer-Konto auf deiner Seite. Beide hängen an Einstellungen und Gewohnheiten bei euch im Haus: wie Kommentare freigegeben werden und wie eingeloggt mit Links umgegangen wird. Das Update schließt beide Lücken. Die Gewohnheiten dahinter schaut es sich nicht an.
Was in 7.1.1 wirklich steckt
Die Zahlen stehen in der offiziellen Versionsdokumentation: 17 Bugfixes im Kern, 21 im Block-Editor, 11 Sicherheitsfixes. Die Release-Meldung nennt für den Block-Editor 19, die Versionsdokumentation 21. Geändert wurden 13 Dateien, darunter wp-includes/formatting.php und wp-admin/js/theme.js. Diese beiden gehören zu den zwei Lücken, um die es hier geht.
Sortiert man die elf Einträge danach, was ein Angreifer mitbringen muss, ergibt sich ein klares Bild:
| Voraussetzung | Anzahl | Beispiele aus der Liste |
|---|---|---|
| Kein Konto, aber eine Freigabe im Haus | 1 | gespeicherte XSS über die Absatz-Formatierung |
| Ein Klick des eingeloggten Administrators | 1 | präparierte Adresse installiert ein Theme aus dem WordPress.org-Katalog |
| Konto ab Rolle Mitarbeiter oder höher | 9 | Pfad-Traversal in der REST-API, Überschreiben fremder Beiträge, Offenlegung von Entwurfs-Adressen |
Neun der elf Punkte setzen also voraus, dass jemand bereits ein Konto auf der Seite hat. Für eine Firmenwebsite mit drei Redakteuren, die alle bekannt sind, ist das ein anderes Risiko als für ein offenes Portal mit Gastautoren. Wer keine Fremdkonten vergibt, kann diese neun Punkte gelassen abhaken, sobald die Version stimmt.
Die Lücke ohne Login hängt an der Kommentar-Freigabe
Der Eintrag in der Liste ist präzise formuliert: eine gespeicherte Cross-Site-Scripting-Lücke über die Absatz-Formatierung, „subject to comment approval“. Cross-Site-Scripting (kurz XSS) heißt, dass fremder Programmcode im Browser deiner Besucher ausgeführt wird, als käme er von deiner Seite. „Gespeichert“ bedeutet, dass der Code in der Datenbank liegt und bei jedem Seitenaufruf mit ausgeliefert wird.
Die Lücke trägt die Kennung CVE-2026-93485. Patchstack gibt in der technischen Analyse vom 18. September 2026 einen CVSS-Wert von 7.1 an. CVSS ist eine Schweregrad-Skala von 0 bis 10, 7.1 liegt im oberen Mittelfeld.
Der Weg hinein ist das gewöhnliche Kommentarformular. Kein Konto, kein Login, ein normaler Besucher. Der Text passiert den Kommentar-Filter von WordPress, weil er dabei völlig harmlos aussieht. Gefährlich wird er erst später, wenn die Anzeige-Funktion den Text in Absätze umbaut und dabei ein HTML-Element an der falschen Stelle aufbricht.
Was die Lücke bremst, und wo die Bremse aussetzt
Der Kommentar muss veröffentlicht werden, sonst passiert nichts. Patchstack beschreibt die Standard-Installation so, dass der erste Kommentar einer unbekannten Person in der Moderation landet. Der CVE-Eintrag vom 18. September 2026 ist deutlicher: Die Kommentar-Moderation sei standardmäßig aus, und die Bedingung eines bereits freigegebenen Kommentars lasse sich umgehen. Die Bremse ist also schwächer, als die Formulierung in der offiziellen Liste vermuten lässt.
Moderation ist keine Sicherheitsfunktion. Sie ist Routinearbeit, oft an eine Assistenz oder eine externe Redaktion delegiert. In der Warteschlange sieht so ein Kommentar unauffällig aus. Und wer einmal freigegeben wurde, wird von WordPress ab dann automatisch durchgelassen.
Die Frage ist deshalb: Braucht ihr Kommentare auf der Firmenwebsite überhaupt? Bei vielen B2B-Seiten stehen sie offen, weil sie nie jemand abgeschaltet hat. Die konkreten Prüfschritte dazu stehen weiter unten.
Click2Shell: ein Klick im eingeloggten Backend
Die zweite Lücke ohne Angreifer-Konto ist die interessantere Konstruktion. Gemeldet haben sie Paulos Yibelo und pwn.ai, der Name „Click2Shell“ stammt von den Findern. In der offiziellen Liste steht sie sachlich als Problem, bei dem eine präparierte Adresse ein Theme aus dem WordPress.org-Katalog installiert und in der Vorschau anzeigt.
Die Analyse von Patchstack beschreibt die Kette in drei Stufen. Zuerst wird derselbe Wert aus der Adresszeile an zwei Stellen unterschiedlich behandelt: der Server räumt ihn auf, das JavaScript im Backend nimmt ihn ungeprüft. Dadurch klickt die Seite in Vertretung des Nutzers auf „Installieren“, und zwar bei einem Theme, das der Angreifer bestimmt. Zweitens wird dieses Theme über die Vorschau im Customizer kurz aktiv, wodurch sein Code läuft. Drittens kann ein unsauber programmiertes Theme an dieser Stelle eine beliebige ZIP-Datei als Plugin nachladen.
Was die Sache begrenzt, gehört genauso zur Wahrheit. Ein eingeloggter Administrator muss die präparierte Adresse selbst aufrufen. Ein normaler Besucher kann das nicht auslösen, ein Redakteur auch nicht. Die volle Wirkung bis zur Codeausführung setzt zusätzlich voraus, dass am Ende ein verwundbares Theme installiert wird. Auf Seiten, die keine Dateien installieren dürfen, etwa mit der Einstellung DISALLOW_FILE_MODS, endet die Kette früher.
Der praktische Schluss daraus ist nicht neu, aber er wird selten so konkret: Administrator-Sitzungen sind der empfindlichste Zustand deiner Website. Wer dauerhaft eingeloggt im Backend surft und nebenbei Links aus E-Mails öffnet, macht aus einem Phishing-Versuch eine technische Möglichkeit. Das galt schon bei der kritischen WordPress-Lücke vom Juli 2026 und gilt hier wieder.
Warum die meisten Seiten schon aktualisiert sind
Automatische Hintergrund-Updates gibt es seit WordPress 3.7. Die Dokumentation für Administratoren schreibt dazu, dass Bestandsinstallationen Minor-Updates standardmäßig erhalten. 7.1.1 ist genau so ein Minor-Update: die dritte Stelle der Versionsnummer ändert sich, der Funktionsumfang bleibt.
Abgeschaltet ist das nur, wenn jemand es abgeschaltet hat, etwa über die Konstante AUTOMATIC_UPDATER_DISABLED oder WP_AUTO_UPDATE_CORE in der wp-config.php. Das kommt in der Praxis vor, meist nach einem missglückten Update vor Jahren.
Die Prüfung dauert zwei Minuten: Im Backend unter „Dashboard“ und „Aktualisierungen“ steht die laufende Version. Steht dort 7.1.2, ist der Teil erledigt. Steht dort 7.1.1, ist das Update vom 22. September noch nicht angekommen. Steht dort 7.1 oder älter, greifen die automatischen Updates bei euch nicht. Dann lohnt die Frage nach dem Warum mehr als der einmalige Klick auf „Jetzt aktualisieren“.
Alte Versionen: Backports bis 4.7
WordPress hat die Fixes auf alle betroffenen älteren Zweige zurückportiert. Die Versionsdokumentation nennt die Zielversionen einzeln:
| Zweig | Fix in Version | Betroffene Lücken |
|---|---|---|
| 7.0 | 7.0.5 | alle 11 |
| 6.9 | 6.9.8 | alle 11 |
| 6.8 | 6.8.9 | alle 11 |
| 6.7 | 6.7.8 | alle 11 |
| 6.0 bis 6.6 | 6.0.15 bis 6.6.8 | 10 von 11 |
| 5.0 bis 5.9 | 5.0.28 bis 5.9.17 | 7 bis 10 |
| 4.7 bis 4.9 | 4.7.36 bis 4.9.32 | 6 bis 7 |
| 4.6 und älter | kein Fix | keine Sicherheitsupdates mehr |
Dazu schreibt WordPress einen Satz, der wichtiger ist als die Tabelle: nur die jeweils neueste Version wird aktiv unterstützt. Backports sind eine Kulanz, keine Zusage. Wer auf 6.4 steht, bekommt heute einen Fix und weiß nicht, ob das beim nächsten Mal wieder so läuft. Ein Sprung auf den aktuellen Zweig ist damit Wartungsarbeit mit Termin, keine Notfallaktion. Das nächste große Release ist laut WordPress Version 7.2 und für Dezember geplant.
Nachtrag vom 22. September: WordPress 7.1.2
Am 22. September 2026 hat WordPress mit Version 7.1.2 nachgelegt. Das Release enthält genau einen Sicherheitsfix, und WordPress stuft ihn selbst als kritisch ein. Laut Meldung kann ein Angreifer ohne Login unter bestimmten Bedingungen erreichen, dass die Seitenvorlagen-Auflösung eine lokale PHP-Datei außerhalb des Theme-Verzeichnisses einbindet. Treffen die Voraussetzungen auf Server und aktivem Theme zu, reicht das bis zur Codeausführung auf dem Server.
Die Lücke trägt die Kennung CVE-2026-87902. Patchstack gibt einen CVSS-4.0-Wert von 9.2 an und nennt als betroffen alle Versionen von 4.7.0 bis 7.1.1. Auch hier gibt es Backports, laut Versionsdokumentation etwa 7.0.6, 6.9.9 und 6.8.10.
Für die Prüfung heißt das: Die Tabelle oben beschreibt den Stand für 7.1.1. Maßgeblich ist jetzt 7.1.2 oder die neue Backport-Version eures Zweigs. Der Weg dorthin ist derselbe, das automatische Minor-Update.
Nachtrag vom 25. September 2026: Die Lücke aus 7.1.2 wird ausgenutzt
Seit dem ersten Nachtrag hat sich die Lage verschärft. Patchstack hat seinen Bericht am 23. September 2026 aktualisiert: Aus dem Abtasten sind Angriffe geworden, die über die Lücke PHP-Dateien auf den Server schreiben. Laut Patchstack ist fertiges Scan-Werkzeug im Umlauf, darunter eine Vorlage für den verbreiteten Scanner Nuclei. Den ersten Versuch, eine Datei zu schreiben, hat Patchstack am 22. September um 15:34 Uhr UTC gesehen, also noch am Tag des Patches.
Ob eine Seite angreifbar ist, hängt laut Advisory von WordPress an zwei Bedingungen. Erstens hat das aktive Theme oder sein Eltern-Theme einen Ordner auf oberster Ebene, dessen Name mit page- beginnt, etwa page-templates. WordPress nennt dafür die alten Standard-Themes Twenty Twelve und Twenty Fourteen sowie verbreitete Themes wie Neve, Hestia und Sydney. Zweitens braucht der Angreifer eine passende PHP-Datei auf dem Server. Der bekannte Weg führt über pearcmd.php und funktioniert, wenn die PHP-Einstellung register_argc_argv eingeschaltet ist. Laut Advisory trifft das auf das offizielle PHP-Image für Docker zu und auf die Standardeinstellung von cPanel mit PHP vor Version 8.5.
Für die Prüfung heißt das: Mit 7.1.2 oder der passenden Backport-Version ist die Lücke zu. Wer das Update erst Tage nach dem 22. September bekommen hat, sollte zusätzlich nachsehen, ob vorher jemand durch war. Woran man das erkennt, steht in den häufigen Fragen unten.
Eine Stimme aus der Praxis dazu: In der Diskussion zum Release auf Reddit schreibt ein Teilnehmer, der nach eigener Angabe rund 70 Websites betreut, die automatischen Sicherheitsupdates hätten bei ihm nie Probleme gemacht. Das passt zu dem, was wir oben zur Update-Automatik geschrieben haben. Es bleibt aber eine Einzelmeinung und keine Messung.
So gehst du deine Seite durch
Sechs Schritte, zusammen etwa eine Stunde:
- Öffne im Backend „Dashboard“ und „Aktualisierungen“ und lies die Versionsnummer. 7.1.2 oder die passende Backport-Version vom 22. September bedeutet: Kern erledigt.
- Steht dort eine ältere Version, prüfe die
wp-config.phpaufAUTOMATIC_UPDATER_DISABLEDundWP_AUTO_UPDATE_CORE. Meist steckt dort die Ursache. - Schau unter „Einstellungen“ und „Diskussion“ nach, ob Kommentare offen sind. Wenn ihr sie nicht braucht, schalte sie ab. Das ist die dauerhafte Lösung, nicht die schnelle.
- Falls ihr Kommentare braucht: Sag der Person, die freigibt, dass automatische Freigabe für Wiederholungskommentatoren eine Entscheidung ist, keine Einstellung von allein.
- Prüfe, wie viele Konten mit Administrator-Rechten existieren und ob jedes davon noch gebraucht wird. Jedes zusätzliche Admin-Konto ist eine zusätzliche Person, die den falschen Link anklicken kann.
- Kam 7.1.2 bei euch erst Tage nach dem 22. September an, lass die Zugriffsprotokolle und die Ordner
/tmpund/var/tmpauf die Spuren aus den FAQ prüfen.
Wenn bei euch unklar ist, wer die WordPress-Version im Blick hat und ob die automatischen Updates überhaupt laufen, schauen wir uns den Ist-Stand gemeinsam an. Am Ende steht eine Liste mit dem, was ansteht, und dem, was ihr liegen lassen könnt. Mehr zur laufenden WordPress-Betreuung steht auf der Leistungsseite.
Häufige Fragen
Muss ich WordPress 7.1.1 manuell installieren?
Meistens nicht. WordPress installiert Minor-Updates wie dieses seit Version 3.7 standardmäßig selbst. Prüfe die Versionsnummer im Backend unter „Aktualisierungen“. Seit dem 22. September ist 7.1.2 der aktuelle Stand. Steht dort eine deutlich ältere Version, sind die automatischen Updates bei dir vermutlich deaktiviert.
Bin ich betroffen, wenn meine Seite keine Kommentare hat?
Die Lücke ohne Login läuft über das Kommentarformular. Ohne offene Kommentare fehlt der Einstieg. Die übrigen zehn Lücken aus 7.1.1 betreffen dich unabhängig davon, sie setzen aber ein Konto auf deiner Seite oder einen Klick deines Administrators voraus. Die Lücke aus 7.1.2 hängt nicht an Kommentaren.
Was ist Click2Shell genau?
So nennen die Finder eine Kette aus mehreren Schwachstellen. Eine präparierte Adresse bringt das Backend dazu, ein Theme zu installieren und in der Vorschau zu starten. Ein unsauber programmiertes Theme kann an dieser Stelle weiteren Code nachladen. Auslösen kann das nur ein eingeloggter Administrator, der die Adresse selbst aufruft.
Meine Seite läuft auf WordPress 6.4. Reicht der Backport?
Für die elf Lücken aus 7.1.1 ja, die Version 6.4.11 enthält die Fixes. Für die Lücke aus 7.1.2 brauchst du 6.4.12. WordPress weist aber ausdrücklich darauf hin, dass nur die jeweils neueste Version aktiv unterstützt wird. Backports sind eine Kulanz für ältere Zweige, kein Dauerzustand.
Gibt es Hinweise auf aktive Angriffe?
Für die Lücken aus 7.1.1 nennen weder wordpress.org noch Patchstack beobachtete Angriffe. Die Lücke aus 7.1.2 wird dagegen ausgenutzt. Patchstack sah erste Abtast-Versuche noch am Tag des Patches und meldete am 23. September, dass Angreifer über die Lücke Dateien auf Server schreiben.
Woran erkenne ich, ob meine Seite über die Lücke aus 7.1.2 angegriffen wurde?
Patchstack nennt konkrete Spuren. In den Zugriffsprotokollen sind das Anfragen, deren Parameter pagename kodierte Pfadsprünge wie %2e%2e enthält, oft zusammen mit page_id, und Anfragen mit pearcmd. Auf dem Server sind unerwartete PHP-Dateien in /tmp oder /var/tmp das deutlichste Zeichen. Findet sich dort so eine Datei, ist die Seite laut Patchstack als kompromittiert zu behandeln und nicht nur als abgetastet.
Was tun, wenn das Update auf 7.1.2 heute nicht möglich ist?
Patchstack nennt zwei Notlösungen. Eine Firewall-Regel, die Pfadsprünge im Parameter pagename abweist, stört den normalen Betrieb nicht, weil echte Seitennamen so etwas nie enthalten. Das Abschalten von register_argc_argv in der PHP-Konfiguration schließt die Lücke nicht, unterbricht aber den bekannten Weg zur Codeausführung. Beides kauft Zeit und ersetzt das Update nicht.
Quellen
- WordPress.org News, 17.09.2026, WordPress 7.1.1 Maintenance and Security Release. wordpress.org
- WordPress.org Dokumentation, Stand 17.09.2026, Version 7.1.1. wordpress.org
- WordPress Developer Resources, Stand 01.07.2026, Upgrading WordPress, Abschnitt Configuring Automatic Background Updates. developer.wordpress.org
- Patchstack, 18.09.2026, WordPress 7.1.1 Maintenance and Security Release. patchstack.com
- Patchstack, 18.09.2026, Click2Shell: The RCE WordPress 7.1.1 Just Patched. patchstack.com
- CVE-Programm, abgerufen am 22.09.2026, CVE-2026-93485. cve.org
- WordPress.org News, 22.09.2026, WordPress 7.1.2 Security Release. wordpress.org
- WordPress.org Dokumentation, Stand 22.09.2026, Version 7.1.2. wordpress.org
- Patchstack, 22.09.2026, WordPress 7.1.2 Security Release, CVE-2026-87902. patchstack.com
- Patchstack, 22.09.2026, CVE-2026-87902, erste Abtast-Versuche nach dem Patch. patchstack.com
- Patchstack, 22.09.2026, aktualisiert 23.09.2026, CVE-2026-87902: From Probing to Code Execution. patchstack.com
- WordPress Security Advisory GHSA-7hp8-65ch-5whp, 22.09.2026, Vorbedingungen und betroffene Themes. github.com
- Reddit r/Wordpress, Diskussion zu WordPress 7.1.2, 22.09.2026. reddit.com