WordPress 7.1.1 schließt Click2Shell: Preauth-RCE über Theme-Vorschau

WordPress 7.1.1 ist seit dem 17. September 2026 verfügbar und sollte zeitnah eingespielt werden. Das Release ist ein kombiniertes Sicherheits- und Wartungsupdate mit 17 Fehlerbehebungen im Core, 19 Korrekturen am Block-Editor und elf Sicherheitskorrekturen. Eine dieser Korrekturen schließt eine Schwachstellenkette, die die Sicherheitsforscher von pwn.ai unter dem Namen Click2Shell veröffentlicht haben: eine Remote Code Execution, die keine Anmeldung beim Zielsystem voraussetzt und durch einen einzigen Klick ausgelöst wird.

Betroffen ist grundsätzlich jede WordPress-Installation, die nicht auf 7.1.1 aktualisiert ist. Ausdrücklich nicht betroffen sind Installationen, die bereits auf 7.1.1 stehen, etwa weil automatische Hintergrund-Updates für Minor-Releases aktiv sind. Wer solche Auto-Updates nutzt, sollte den tatsächlichen Versionsstand dennoch prüfen, statt ihn anzunehmen. Für alle anderen gilt: heute prüfen, heute patchen. Ein Nachweis aktiver Angriffe liegt zum Redaktionsschluss am 19. September 2026 nicht vor, und eine CVE-Kennung war zum Zeitpunkt der Veröffentlichung des Forschungsbeitrags noch nicht vergeben.

Was ist passiert?

WordPress.org hat am 17. September 2026 die Version 7.1.1 als Maintenance- und Security-Release veröffentlicht. Im offiziellen Release-Beitrag werden elf Sicherheitskorrekturen aufgeführt, darunter mehrere Cross-Site-Scripting-Probleme, ein Path Traversal im REST-Templates-Controller und eine Umgehung von Berechtigungsprüfungen über XML-RPC. BornCity nennt in seiner Meldung zwölf Sicherheitskorrekturen, die offizielle Release-Notes listen elf Punkte auf. Die abweichende Zahl ändert nichts an der Einschätzung, da sie dieselbe Version betrifft.

Ein Punkt in dieser Liste ist knapp formuliert: speziell gestaltete URLs können ein inaktives Theme von WordPress.org automatisch installieren und in der Vorschau öffnen. Hinter diesem Satz steckt die von pwn.ai beschriebene Kette. Ein Wert aus der URL einer Theme-Vorschau wird zweimal ausgewertet, einmal durch die Themes-API von WordPress.org und ein zweites Mal fehlerhaft durch JavaScript im Browser der angemeldeten Person. Die API reduziert den Wert auf einen normalen Theme-Slug, der Browser behält jedoch die ursprüngliche Zeichensetzung und setzt sie in einen jQuery-Selektor ein. Das Ergebnis: Die Theme-Vorschau klickt den Installieren-Knopf selbst.

Damit allein wäre ein fremd gewähltes Theme aus dem offiziellen Katalog installiert, ohne dass die Administration etwas bestätigt. Den zweiten Teil der Kette lieferte ein separater Fehler in einem damals aktuellen Katalog-Theme: WordPress lädt den PHP-Code eines Themes bereits während einer Customizer-Vorschau, auch wenn ein anderes Theme aktiv bleibt. In dem betroffenen Theme war ein AJAX-Handler ohne Nonce und ohne Rechteprüfung registriert, der eine fremd gewählte Paket-URL entgegennahm, entpackte und deren PHP-Code lud. Die Forscher geben an, vergleichbare Fehler in über 40 weiteren Themes im Verzeichnis gefunden zu haben.

Wer ist betroffen?

Die Angriffskette setzt beim WordPress-Core an, nicht bei einem einzelnen Plugin. Das macht den Betroffenenkreis deutlich größer als bei den üblichen Plugin-Meldungen.

• Jede WordPress-Installation mit einer Version unterhalb 7.1.1, unabhängig von Theme, Plugin-Auswahl oder Hoster.
• Besonders relevant für Seiten, auf denen regelmäßig angemeldete Redaktions- oder Administrationskonten im Browser aktiv sind, denn die Kette wird durch den Besuch einer fremden Seite aus einer laufenden Sitzung heraus ausgelöst.
• Multisite-Netzwerke, weil dort ein einzelner erfolgreicher Zugriff mehrere Sites gleichzeitig betrifft.
• Agentur- und Dienstleisterbestände mit vielen gleichartigen Installationen, bei denen das Update nicht zentral gesteuert wird.
• Nicht betroffen: Installationen, die nachweislich auf 7.1.1 oder höher laufen. Der Nachweis ist entscheidend, nicht die Annahme.

Die Forscher von pwn.ai ordnen die Tragweite über die Verbreitung ein: WordPress betreibt nach ihren Angaben rund 43 Prozent des Webs. Diese Zahl ist eine Marktanteilsschätzung, kein Messwert für Betroffenheit, taugt aber als Maßstab dafür, warum Core-Lücken anders zu behandeln sind als Plugin-Lücken.

Wie kritisch ist das?

Die Einordnung sollte präzise bleiben. Es handelt sich um eine Remote Code Execution, also um die Ausführung fremden PHP-Codes unter dem Konto des Webservers, nicht um eine lokale Rechteausweitung und nicht um einen reinen Datenabfluss. Preauth bedeutet hier, dass die angreifende Seite kein eigenes Konto auf der Zielseite benötigt. Voraussetzung bleibt aber eine Interaktion: Ein Klick beziehungsweise ein Seitenbesuch aus einer bereits angemeldeten Sitzung heraus löst die Kette aus. Ein vollautomatischer Massenangriff ohne jede Nutzeraktion ist das damit nicht.

Ein CVSS-Wert liegt für Click2Shell bislang nicht vor. Auch eine CVE-Kennung war zum Zeitpunkt der Veröffentlichung des Forschungsbeitrags nicht vergeben; laut den Forschern hat das WordPress-Projekt eine Zuweisung angekündigt und die maximale Prämie aus seinem Bug-Bounty-Programm gezahlt. Aussagen über eine aktive Ausnutzung gibt es zum Redaktionsschluss weder vom WordPress-Sicherheitsteam noch von den Entdeckern. Das ist ein Grund für zügiges, aber geordnetes Handeln, kein Grund für ein hastiges Update ohne Sicherung.

Einzuordnen ist die Lücke auch im Kontext: Dieselbe Forschergruppe hatte einen Monat zuvor die Kette XSS2Shell mit der Kennung CVE-2026-64638 gemeldet, die in WordPress 7.0.3 vom 6. August 2026 behoben wurde. Der Core steht damit erkennbar unter gezielter Beobachtung, und weitere Funde in diesem Bereich sind wahrscheinlich.

Was sollten Admins jetzt tun?

• Versionsstand belegen, nicht schätzen. Im Backend unter Dashboard, Aktualisierungen steht die laufende Version. Auf Dateiebene liefert wp-includes/version.php den Wert in $wp_version. Per Kommandozeile ist wp core version der schnellste Weg, auch über mehrere Installationen hinweg per Schleife über die Verzeichnisse.
• Backup vor dem Update. Datenbank und Dateibestand sichern, und zwar so, dass die Rücksicherung auch getestet ist. Ein nicht geprüftes Backup ist im Fehlerfall wertlos.
• Core aktualisieren. Im Backend über Aktualisierungen, auf der Kommandozeile mit wp core update und anschließend wp core update-db. Danach die Version erneut auslesen und das Ergebnis protokollieren.
• Automatische Updates für Minor-Releases aktivieren. Für Sicherheitsreleases dieser Art ist das die wirksamste Dauermaßnahme. Wer sie bereits nutzt, hat 7.1.1 eventuell schon erhalten und muss das nur noch bestätigen.
• Themes im Verzeichnis kontrollieren. Unter wp-content/themes darf nichts liegen, das niemand bewusst installiert hat. Unbekannte Theme-Ordner sind bei dieser Angriffskette das naheliegendste Indiz.
• Benutzerkonten prüfen. Unerwartete Konten mit Administrationsrechten, geänderte E-Mail-Adressen bei bestehenden Konten und kürzlich geänderte Passwörter gehören kontrolliert.
• Dateiänderungen und Logs auswerten. Kürzlich geänderte PHP-Dateien im Web-Root, unerwartete Schreibvorgänge unter wp-content, außerdem Webserver-Logs auf ungewöhnliche Aufrufe des Customizers und der Theme-Installationsroutinen.
• Bei Verdacht nicht nur patchen. Ein Update schließt die Lücke, entfernt aber keinen bereits abgelegten Code. Bei konkretem Verdacht ist die saubere Neuaufsetzung aus einem geprüften Backup der sicherere Weg.
• Plugins und Themes mitziehen. Die zweite Hälfte der Kette lag in einem Theme, nicht im Core. Veraltete Erweiterungen bleiben unabhängig von 7.1.1 ein Risiko.
• Wartungsfenster einplanen, wo nötig. Multisite-Netzwerke und stark angepasste Installationen mit Child-Themes, eigenen Plugins oder Page-Buildern sollten das Update in einem definierten Zeitfenster und nach Möglichkeit erst auf Staging erhalten.
• Nach dem Update funktional testen. Login, Medien-Upload, Formulare, Caching und Zahlungs- oder Buchungsstrecken prüfen, bevor das Wartungsfenster geschlossen wird.
• Ergebnis dokumentieren. Datum, Version, geprüfte Installationen und verbleibende Ausnahmen gehören mit Termin und Zuständigkeit in die Betriebsdokumentation.

Einordnung für Unternehmen

Für kleine und mittlere Unternehmen ist die praktische Lehre weniger die einzelne Lücke als der Rhythmus. Zwei Core-RCE-Ketten innerhalb von rund sechs Wochen zeigen, dass ein WordPress-Auftritt keine einmalig eingerichtete Sache ist, sondern ein betriebenes System mit Update-Pflicht. Wer die Website als Vertriebskanal nutzt, sollte sie im Patch-Management genauso führen wie Server und Clients.

Drei Punkte machen dabei den größten Unterschied: aktivierte automatische Minor-Updates, eine vollständige Liste aller eigenen Installationen samt Version und ein Backup, dessen Rücksicherung tatsächlich einmal durchgespielt wurde. Wer diese drei Punkte hat, kann auf Meldungen wie diese ruhig reagieren. Wer sie nicht hat, verbringt den Tag mit Suchen statt mit Patchen.

Bei Dienstleisterbetreuung lohnt eine schriftliche Rückmeldung mit Datum, Bestand und Versionsstand nach dem Update. Bei einem konkreten Kompromittierungsverdacht gelten zusätzlich die üblichen Pflichten zur Bewertung eines möglichen Datenschutzvorfalls. Das ist keine Formalie, sondern der Punkt, an dem eine saubere Dokumentation den Unterschied macht.

Passende Anleitungen auf S-EDV

• WordPress 7.1: Update-Anleitung für Admins: Hintergrund zum Hauptrelease 7.1, auf dem das jetzige Wartungsupdate aufsetzt, mit dem Ablauf für ein geordnetes Core-Update.
• WordPress 7.0.4 sicher einspielen: Backup und Imagick prüfen: Der praktische Ablauf aus Backup, Update, Funktionstest und Nachkontrolle, der sich unverändert auf 7.1.1 übertragen lässt.
• WordPress-Core-Schwachstelle wp2shell: Pre-Auth-RCE: Einordnung einer früheren Core-Kette derselben Kategorie, hilfreich für das Verständnis wiederkehrender Angriffsmuster.

Quellen

• WordPress.org: WordPress 7.1.1 Maintenance and Security Release, Primärquelle mit der Liste der Sicherheitskorrekturen, abgerufen am 19.09.2026.
• pwn.ai Research: Click2Shell, Preauth WordPress Core Theme Preview Injection to RCE Chain, technische Beschreibung der Kette durch die Entdecker, abgerufen am 19.09.2026.
• BornCity: Click2Shell-Sicherheitslücke, zeitnah auf WordPress 7.1.1 aktualisieren, deutschsprachige Einordnung vom 18.09.2026.
• BornCity: WordPress 7.1.1 verfügbar (17. September 2026), Meldung zum Erscheinungstermin des Updates.