Click2Shell: kritische RCE-Kette in WordPress Core, so patchen Sie auf 7.1.1

Veröffentlicht: 21.09.2026 · Letzte Aktualisierung: 21.09.2026

Was ist passiert

WordPress hat am 17.09.2026 die Version 7.1.1 veröffentlicht, ein Sicherheits- und Wartungsrelease mit elf Sicherheitsfixes. Darunter ist die vom Sicherheitsteam von pwn.ai gemeldete Angriffskette Click2Shell, die einen einzigen Klick eines eingeloggten Administrators bis zur Ausführung von fremdem PHP-Code auf dem Server verlängern kann.

Damit steht nach wp2shell im Juli 2026 zum wiederholten Mal in diesem Jahr eine Schwachstelle im WordPress Core im Raum, die bis zur Codeausführung reicht. Das ist bemerkenswert, denn der Core gilt zu Recht als eine der am besten geprüften Komponenten im WordPress-Ökosystem. Die allermeisten Sicherheitsvorfälle entstehen in Plugins und Themes. Wenn der Core selbst betroffen ist, steigt die Zahl der potenziell angreifbaren Installationen schlagartig auf praktisch alle. WordPress betreibt nach eigenen Angaben rund 43 Prozent aller Websites weltweit, entsprechend groß ist die Angriffsfläche, sobald eine Core-Lücke mit öffentlichem Proof of Concept existiert.

Der Umfang des Releases laut offizieller Ankündigung und Versionsdokumentation: elf Sicherheitsfixes, 17 Bugfixes im Core und 21 Bugfixes im Block-Editor. WordPress empfiehlt ausdrücklich, sofort zu aktualisieren. Wir schließen uns dieser Empfehlung ohne Einschränkung an.

Die Schwachstelle im Detail

Click2Shell ist keine einzelne Lücke, sondern eine Kette aus drei Bausteinen, die einzeln betrachtet harmlos oder zumindest beherrschbar wirken. Erst in Kombination entsteht daraus die Ausführung von Angreifer-Code. Genau diese Bauweise macht den Fall lehrreich.

Schritt 1: Selector-Injection im Theme-Installer

WordPress erlaubt Administratoren, Themes direkt aus dem offiziellen WordPress.org-Katalog heraus zu installieren und in der Vorschau anzusehen. Der Name des Themes, der sogenannte Slug, wird dabei als URL-Parameter übergeben und von zwei verschiedenen Stellen verarbeitet. Auf dem Server normalisiert die WordPress.org Themes API den Wert: Sonderzeichen werden entfernt, übrig bleibt ein gültiger Theme-Slug. Im Browser des Administrators nimmt das JavaScript von wp-admin jedoch den ursprünglichen, unbereinigten Wert und setzt ihn direkt in einen jQuery-Selektor ein.

Diese Diskrepanz ist die eigentliche Schwachstelle. Ein präparierter Slug kann aus dem Selektor ausbrechen, durch das DOM der Admin-Seite wandern und dabei den Install-Button des Theme-Installers auslösen. Der Administrator klickt nichts an, er öffnet lediglich einen Link. Die Installations-Nonce und die nötige Berechtigung liefert die vertrauenswürdige Admin-Seite gleich mit, denn aus Sicht von WordPress handelt hier der Administrator selbst.

Das Ergebnis: Ein Angreifer kann die WordPress-Installation dazu bringen, ein von ihm ausgewähltes Theme aus dem offiziellen Katalog herunterzuladen und zu installieren. Das Theme bleibt dabei inaktiv, die sichtbare Website verändert sich nicht. Genau deshalb fällt der Vorgang im Alltag kaum auf.

Schritt 2: PHP-Ausführung vor der Theme-Aktivierung

Ein installiertes, aber nicht aktiviertes Theme galt lange als weitgehend ungefährlich. Die Analyse von pwn.ai zeigt, dass diese Annahme nicht trägt: WordPress lädt die functions.php eines inaktiven Themes, wenn dieses im Customizer als Vorschau geöffnet wird. Der Code des inaktiven Themes registriert in diesem Moment seine Hooks und AJAX-Handler, obwohl in der Datenbank weiterhin das ursprüngliche Theme als aktiv geführt wird.

Ein zweiter präparierter Aufruf genügt also, um den PHP-Code des gerade zwangsinstallierten Themes zur Ausführung zu bringen. Für die Besucher der Website bleibt weiterhin alles beim Alten. Genau diese Unauffälligkeit macht den Mechanismus tückisch: Das aktive Theme wechselt zu keinem Zeitpunkt, im Frontend gibt es keinerlei sichtbare Veränderung, und wer nicht gezielt ins Theme-Verzeichnis oder in die Logs schaut, bemerkt den Vorgang nicht.

Die Erkenntnis dahinter ist grundsätzlicher Natur und gilt unabhängig von diesem Einzelfall: Eine Theme-Installation ist eine privilegierte Code-Deployment-Operation. Sobald ein Theme auf dem Server liegt, existiert dort ausführbarer PHP-Code, den WordPress unter bestimmten Bedingungen lädt, ganz ohne Aktivierung. „Installiert, aber inaktiv“ ist deshalb kein Sicherheitszustand, auf den man sich verlassen sollte.

Schritt 3: der ungeschützte AJAX-Installer

Der dritte Baustein liegt nicht im Core, sondern im Theme-Katalog. Das Theme Mobile Repair Zone registrierte bis einschließlich Version 2.5.4 einen AJAX-Handler ohne Nonce-Prüfung und ohne Berechtigungsprüfung, der eine beliebige Plugin-Paket-URL entgegennimmt, das Paket herunterlädt, entpackt und dessen PHP lädt. Laut pwn.ai enthalten über 40 weitere im WordPress-Katalog gehostete Themes vergleichbar ungeschützte Handler.

Damit ist die Kette komplett: Der Core-Bug installiert das verwundbare Katalog-Theme, der Customizer-Aufruf lädt dessen PHP, und der ungeschützte AJAX-Handler holt ein vom Angreifer gebautes Plugin-Paket auf den Server und führt es aus. Aus einem geöffneten Link wird Codeausführung unter dem Server-Konto der WordPress-Installation.

Was WordPress geändert hat

WordPress 7.1.1 behebt das Problem an der Wurzel des ersten Kettenglieds. Der Slug wird im Admin-JavaScript nun durch $.escapeSelector() geschickt, bevor er in den jQuery-Selektor gelangt, und das Matching ist auf echte Theme-Card-Elemente beschränkt. Der übergebene Wert wird damit als Text behandelt und nicht mehr als Selektor-Syntax. Er kann keine Buttons mehr auslösen.

Die Lehre für Entwickler geht über diesen Einzelfall hinaus: Sobald derselbe Eingabewert von zwei unabhängigen Codepfaden interpretiert wird, muss er auf beiden Seiten bereinigt werden. Eine serverseitige Normalisierung schützt den Browser nicht.

Wer ist betroffen

Betroffen ist jede Installation von WordPress 6.0 bis 7.1.0, bei der Theme-Installationen über das Backend möglich sind und mindestens ein Administrator-Konto aktiv genutzt wird. Für ältere Versionszweige hat WordPress Backport-Patches bis hinunter zu Version 4.7 bereitgestellt, ein Zeichen dafür, wie ernst das Projekt die Lücke nimmt.

Versionszweig	Gepatchte Version
7.1	7.1.1
7.0	7.0.5
6.9	6.9.8
6.8	6.8.9
6.7	6.7.8
6.6	6.6.8
6.5	6.5.11
6.4 bis 4.7	Backports bis 4.7.36

WordPress 4.6 und älter erhalten keine Sicherheitsupdates mehr. Wer eine so alte Installation betreibt, hat allerdings ein grundsätzlicheres Problem als diese eine Lücke und sollte eine Migration nicht weiter aufschieben.

Ein wichtiger Punkt zur Einordnung: Der Name „Pre-Auth“, der in manchen PoC-Repositories kursiert, ist irreführend. Der Angreifer braucht zwar kein eigenes Konto auf der Zielseite, die Kette benötigt aber zwingend eine aktive Administrator-Session im Browser des Opfers oder eine bereits vorhandene XSS-Lücke auf der Website, die den präparierten Aufruf im Browser eines Administrators auslöst. Ohne eingeloggten Administrator passiert nichts.

Besonders relevant ist die Lücke für Digital- und Marketingagenturen, die viele Kundeninstallationen betreuen. Wer täglich mit einem Administrator-Konto zwischen Dutzenden WordPress-Backends wechselt, per Dauer-Session eingeloggt bleibt und dabei E-Mails, Tickets und Chat-Nachrichten mit Links öffnet, bietet genau die Angriffsfläche, auf die diese Kette zugeschnitten ist. Für Agenturen haben wir unser Wartungsangebot gebündelt: WordPress-Wartung für Agenturen.

Timeline

• 22.08.2026: Paulos Yibelo (pwn.ai) meldet die Selector-Injection und die automatische Theme-Installation an WordPress, inklusive Proof of Concept. WordPress reproduziert das Verhalten noch am selben Tag auf 7.1.0.
• 01.09.2026: pwn.ai liefert die vollständige Kette bis zur PHP-Ausführung nach, demonstriert mit dem Katalog-Theme Mobile Repair Zone 2.5.4.
• Anfang September 2026: WordPress zahlt die maximale Bounty seines Bug-Bounty-Programms von 300 US-Dollar und kündigt ein Sicherheitsrelease an.
• 17.09.2026: WordPress 7.1.1 erscheint mit dem Fix, pwn.ai wird in den Release Notes genannt.
• 18.09.2026: pwn.ai veröffentlicht die vollständige technische Analyse. Seitdem sind funktionsfähige PoC-Skripte auf GitHub verfügbar.

Am Rande bemerkt: 300 US-Dollar als Maximal-Bounty für eine Kette, die bis zur Codeausführung auf einem beträchtlichen Teil der weltweiten Websites reicht, wirkt bescheiden. Umso höher ist einzuschätzen, dass pwn.ai den Fund verantwortungsvoll gemeldet hat.

Sofortmaßnahmen

Die folgenden Schritte decken Prüfung, Patch und Nachkontrolle ab. Wenn Sie mehrere Installationen betreuen, arbeiten Sie die Liste pro Installation ab.

1. WordPress-Version prüfen. Im Dashboard unter Aktualisierungen oder per WP-CLI mit wp core version. Alles unterhalb von 7.1.1 beziehungsweise unterhalb der gepatchten Version Ihres Zweigs ist verwundbar.
2. Auf 7.1.1 oder den passenden Backport aktualisieren. Bei geschäftskritischen Seiten gilt die Reihenfolge Staging vor Produktion: Update zuerst in der Staging-Umgebung einspielen, Kernfunktionen prüfen, dann live gehen. Unser nginx-Hosting stellt dafür Staging-Umgebungen und Rollback-Punkte bereit.
3. Automatische Core-Updates für Minor-Releases aktiviert lassen. WordPress spielt Sicherheitsreleases wie 7.1.1 standardmäßig automatisch ein. Wer diese Automatik deaktiviert hat, sollte die Entscheidung nach diesem Fall überdenken oder das Einspielen organisatorisch absichern.
4. Theme-Bestand inventarisieren. Listen Sie alle installierten Themes auf (wp theme list) und löschen Sie alles, was nicht aktiv genutzt wird, insbesondere das Theme Mobile Repair Zone in Version 2.5.4 oder älter. Jedes installierte Theme ist ausführbarer PHP-Code auf Ihrem Server, auch wenn es nie aktiviert wurde.
5. DISALLOW_FILE_MODS bewerten. Die Konstante DISALLOW_FILE_MODS in der wp-config.php unterbindet Installationen und Updates über das Backend vollständig und hätte die Zwangsinstallation in dieser Kette blockiert. Die Nebenwirkung: Auch legitime Plugin- und Theme-Installationen sowie Updates über das Backend sind danach nicht mehr möglich, Pflege läuft dann über WP-CLI oder Deployment-Prozesse. Für professionell gewartete Seiten ist das eine sinnvolle Härtung, mehr dazu auf unserer Seite zur WordPress-Sicherheit.
6. Administrator-Konten reduzieren und absichern. Jedes Admin-Konto ist ein möglicher Auslöser für diese Kette. Entziehen Sie Konten, die keine Administrator-Rechte brauchen, diese Rolle, erzwingen Sie Zwei-Faktor-Authentifizierung und invalidieren Sie nach dem Update alle bestehenden Sessions.
7. Auf Kompromittierung prüfen. Kontrollieren Sie das Theme-Verzeichnis auf Themes, die niemand installiert hat, das Plugin-Verzeichnis auf unbekannte Einträge, die Nutzerliste auf neue Administrator-Konten und den Dateibestand auf Änderungen seit dem 18.09.2026, dem Tag der Veröffentlichung der PoC-Skripte. In den Server-Logs sind Aufrufe von theme-install.php mit ungewöhnlichen Parametern und auffällige POST-Requests an admin-ajax.php die relevanten Spuren.
8. Bei Verdacht sofort handeln. Wenn Sie unbekannte Themes, Plugins oder Admin-Konten finden, behandeln Sie die Seite als kompromittiert: Passwörter und Salts rotieren, Seite forensisch sichern, bereinigen. Wie wir dabei vorgehen, beschreibt unsere Notfallseite WordPress gehackt.

Einschätzung von CMS ADMINS

Wie gefährlich ist Click2Shell in der Praxis? Die ehrliche Antwort: gefährlich, aber nicht auf die Art, die Schlagzeilen suggerieren. Die Einstiegshürde ist eine aktive Administrator-Session, das senkt die Massenausnutzbarkeit gegenüber einem Fall wie wp2shell deutlich. Niemand kann Ihre Seite übernehmen, nur weil sie existiert. Jemand muss einen Ihrer Administratoren dazu bringen, im eingeloggten Zustand einen Link zu öffnen.

Genau da liegt aber das Problem: Dieses Szenario ist realistischer, als es klingt. Administratoren bleiben dauerhaft eingeloggt. Links kommen den ganzen Tag herein, in E-Mails, Support-Tickets, Kommentar-Benachrichtigungen und Chats. Die Kombination aus öffentlich verfügbarem PoC, jahrelang gewachsenen Theme-Beständen mit vergessenen Altlasten und Agentur-Umgebungen mit vielen Admin-Konten ist erfahrungsgemäß genau das Muster, bei dem Angriffe in der Praxis funktionieren. Dass eine aktive Ausnutzung zum Redaktionsschluss nicht belegt ist, sollte niemanden beruhigen: Zwischen PoC-Veröffentlichung und ersten realen Kampagnen vergehen typischerweise Tage, nicht Monate.

Für unsere Wartungskunden ist der Fall bereits abgeräumt: Geprüfte Updates innerhalb definierter Fristen, Staging vor Produktion, Rollback-Punkte und laufendes Monitoring gehören zum Standardumfang unserer WordPress-Wartung. Wenn Sie Ihre Installation selbst betreuen, nehmen Sie diesen Fall zum Anlass, die Punkte 4 bis 6 der Sofortmaßnahmen nicht nur einmalig, sondern als wiederkehrende Routine einzuplanen.

Häufige Fragen (FAQ)

Bin ich betroffen, wenn meine Seite auf WordPress 7.0 läuft?

Ja. WordPress 7.0 ist von allen elf Sicherheitslücken des Releases betroffen, einschließlich Click2Shell. Für den 7.0-Zweig steht die gepatchte Version 7.0.5 bereit, die Sie umgehend einspielen sollten, sofern Sie nicht ohnehin auf 7.1.1 aktualisieren.

Reicht ein Update auf 7.1.1 aus oder muss ich zusätzlich Themes entfernen?

Das Update auf 7.1.1 schließt das Core-Kettenglied und stoppt damit die Zwangsinstallation, die den Angriff startet. Ungenutzte installierte Themes bleiben trotzdem ein eigenes Risiko, denn ihr PHP-Code liegt weiterhin ausführbar auf dem Server und Handler wie der in Mobile Repair Zone 2.5.4 bleiben über andere Wege angreifbar. Löschen Sie deshalb alle Themes, die Sie nicht aktiv nutzen.

Was bedeutet Click2Shell konkret, wenn ich kein Administrator-Konto täglich nutze?

Ihr direktes Risiko sinkt deutlich, denn die Kette braucht eine aktive Administrator-Session im Browser. Entscheidend ist aber nicht nur Ihr eigenes Verhalten: Jedes Administrator-Konto Ihrer Installation, auch das einer Agentur oder eines Kollegen, kann den Angriff auslösen. Prüfen Sie deshalb, wie viele Admin-Konten existieren, und reduzieren Sie sie auf das nötige Minimum.

Wurde die Lücke bereits aktiv ausgenutzt?

Nein, eine aktive Ausnutzung ist zum Redaktionsschluss nicht belegt. Seit dem 18.09.2026 sind allerdings funktionsfähige PoC-Skripte öffentlich auf GitHub verfügbar, womit die technische Hürde für Angreifer praktisch entfällt. Warten Sie mit dem Update deshalb nicht auf erste bestätigte Vorfälle.

Gibt es eine CVE-Nummer für Click2Shell?

Nein, zum Redaktionsschluss ist keine CVE-Nummer vergeben. WordPress hat gegenüber pwn.ai angekündigt, eine CVE nachträglich zuzuweisen. Bis dahin finden Sie die Lücke in den Release Notes von 7.1.1 unter dem Eintrag zu speziell präparierten URLs, die ein inaktives Theme von WordPress.org installieren und in der Vorschau laden können.

Schützt mich mein Security-Plugin auch ohne Update?

Verlassen Sie sich nicht darauf. Anbieter wie Patchstack geben an, ihre Kunden vor dieser Lücke zu schützen, und eine Web Application Firewall kann bekannte Angriffsmuster filtern. Ein virtueller Patch ersetzt aber nie den echten Fix im Core, zumal Varianten des Angriffs Filterregeln umgehen können. Die verlässliche Absicherung ist das Update auf 7.1.1 beziehungsweise den Backport Ihres Versionszweigs.

Fazit

Click2Shell zeigt, wie aus drei einzeln überschaubaren Schwächen eine Kette bis zur Codeausführung wird: eine Selector-Injection im Theme-Installer, PHP-Ausführung vor der Theme-Aktivierung und ein ungeschützter AJAX-Handler in einem Katalog-Theme. Die Einstiegshürde einer aktiven Admin-Session macht die Lücke nicht harmlos, sondern nur zielgerichteter. Spielen Sie das Update auf WordPress 7.1.1 oder den Backport Ihres Zweigs jetzt ein, räumen Sie Ihren Theme-Bestand auf und reduzieren Sie Ihre Administrator-Konten. Wenn Sie Updates, Monitoring und Härtung dauerhaft in professionelle Hände geben möchten, übernehmen wir das im Rahmen unserer WordPress-Wartung ab 9,50 Euro im Monat.

Quellen: WordPress 7.1.1 Release-Ankündigung · WordPress 7.1.1 Versionsdokumentation · pwn.ai: Click2Shell · Patchstack-Analyse · The Hacker News