Click2Shell: Wie ein präparierter Link WordPress-Sites komplett übernimmt

Was geschah

WordPress hat in Version 7.1.1 (17. September) elf Sicherheitslücken geschlossen — darunter eine, die die Entdecker von pwn.ai Click2Shell getauft haben: Eine Kette, die aus einem einzigen Klick eines eingeloggten Administrators auf einen präparierten Link die vollständige Übernahme der Website macht. Technische Details und ein Proof-of-Concept sind öffentlich, eine CVE-Nummer ist laut WordPress in Arbeit. Heise berichtet, BleepingComputer und Patchstack haben die Analyse vertieft.

Die Kette in Kürze: Ein einziger Wert aus einer Theme-Vorschau-URL wird von zwei Stellen unterschiedlich interpretiert — und aus diesem Interpretationskonflikt entsteht eine erzwungene Theme-Installation, die per Customizer-Vorschau PHP lädt und über einen ungeschützten AJAX-Endpunkt eine Shell nachzieht.


Der Bug: Ein Wert, zwei Interpretationen

WordPress erlaubt Theme-Vorschauen direkt aus dem WordPress.org-Katalog. Der Theme-Slug wird dabei in der URL übergeben — und genau dieser Wert wird doppelt gelesen:

  1. Serverseite: Die WordPress.org Themes API kanonisiert den Slug. Aus twentytwenty"]> wird schlicht twentytwenty — die API liefert den echten, harmlosen Katalog-Eintrag.
  2. Browser: Die eigene JavaScript-Logik im wp-admin (wp-admin/js/theme.js) nimmt den Originalwert und setzt ihn ungeprüft in einen jQuery-Selektor ein.

Das injizierte Anführungszeichen schließt den Attribut-Selektor, Kind-Kombinatoren wandern in die Theme-Karte hinein, ein CSS-Kommentar neutralisiert den Rest. Der Selektor greift damit nicht mehr nur die Karte, sondern ihren Install-Button — und WordPress führt den Install selbst aus, im Namen des Administrators:

  • Der Angreifer braucht keinen WordPress-Account.
  • Er braucht kein Install-Nonce — die vertrauenswürdige Admin-Seite hat eines.
  • Er braucht keine install_themes-Berechtigung — das Opfer liefert sie mit.

Ergebnis: WordPress installiert ein vom Angreifer gewähltes Theme aus dem offiziellen Katalog — ohne dass der Admin je auf „Installieren" klickt. Die Seite sieht danach unverändert aus, das installierte Theme ist inaktiv. Genau da wird es interessant.


Inaktiv heißt nicht harmlos: Der zweite Teil der Kette

Ein installiertes, aber nicht aktiviertes Theme klingt harmlos — wäre es auch, gäbe es nicht den Customizer. Denn zur Vorbereitung einer Vorschau lädt WordPress die functions.php des inaktiven Themes, obwohl in der Datenbank ein anderes Theme aktiv bleibt. Das Theme kann also Hooks und Handler registrieren, bevor es je sichtbar wird.

pwn.ai fand im damaligen Katalog-Paket Mobile Repair Zone 2.5.4 (und in über 40 weiteren Themes im Katalog) genau das benötigte zweite Glied: einen registrierten AJAX-Handler ohne Nonce- und ohne Capability-Check, der eine vom Angreifer gewählte Plugin-URL entgegennimmt, das ZIP in das Plugin-Verzeichnis schreibt, entpackt und dessen PHP lädt.

Die komplette Kette:

  1. Präparierter Link zwingt WordPress, ein Katalog-Theme zu installieren (Core-Bug).
  2. Eine Nachfolge-Anfrage öffnet die Customizer-Vorschau — WordPress lädt die functions.php des inaktiven Themes.
  3. Dessen ungeschützter AJAX-Endpunkt zieht das Angreifer-Plugin.
  4. Dessen PHP läuft unter dem Server-Account: wp-config.php samt DB-Credentials, User- und Content-Manipulation, volle Übernahme.

Wie realistisch ist der Angriff?

Patchstack ordnet es ein: Es ist kein Drive-by. Benötigt wird ein eingeloggter Administrator, der den präparierten Link besucht — realistisch über gezieltes Phishing oder über eine bestehende XSS-Schwachstelle, die den Request im Browser des Admins automatisch abfeuert. Autoren und Editoren reichen nicht, ihnen fehlt die Theme-Install-Berechtigung. Autor/Editor-Accounts sind also kein Pfad — der Admin selbst ist das Ziel.

Zur Schwere gibt es drei Einschätzungen: WordPress listet die Lücke im GitHub-Advisory GHSA-5qf7-2r5p-ppj8 als mittel, pwn.ai bewertet die erzwungene Installation allein als hoch (CVSS 3.1: 7,1) und die vollständige Kette als kritisch (9,3, mit UI:R als Milderung). Heise nennt als gefährlichste der elf geflickten Lücken übrigens eine Stored-XSS-Lücke, über die ein geposteter Kommentar dauerhaft Schadcode verankert — auch die passt als Einfallstor in eine Click2Shell-Kette.


Der Fix

Changeset 63664 macht zwei Dinge: Der Selektor wird auf echte div.theme-Karten begrenzt, und der URL-Slug läuft vor dem Einbau in den Selektor durch $.escapeSelector(). Die injizierten Zeichen werden damit zu literalen Slug-Buchstaben — der Selektor kann nicht mehr in den Install-Button wandern.

Betroffen sind alle Versionen vor 7.1.1. Wer nicht sofort patchen kann: DISALLOW_FILE_MODS in der wp-config.php blockiert die erzwungene Theme- und Plugin-Installation (schützt aber nicht vor der Selektor-Injektion selbst).


Die eigentliche Lektion

Der tiefere Punkt ist der Formfehler, nicht der einzelne Selektor: Derselbe Wert wird serverseitig und clientseitig von zwei unabhängigen Codeteilen geparst — und nur eine Seite bereinigt ihn. Die Themes API kanonisiert, der Browser vertraut. Solche Doppel-Interpretationen finden sich überall, wo Backend und Frontend denselben Input unabhängig verarbeiten. Wer Eingaben validiert, muss sie an jedem Konsumpunkt validieren — und bei WordPress-Instanzen gilt ohnehin: Core-Updates sofort einspielen, PoC und technische Details sind seit dem 18. September öffentlich.

Nebenbei bemerkenswert: Die Forscher von pwn.ai fanden die Kette mit einer eigenen KI-Harness — „Claude Opus 5 und ein Mensch, kollaborierend". Bug-Hunting mit LLMs ist längst kein Konzept mehr, sondern Methode. Das dritte Mal diese Woche, dass hier KI-gestützte Sicherheitsforschung in der Meldungslage auftaucht — ein Trend mit Steigung.


Quellen