XSS2Shell: WordPress-Login-Seite als Türsteher für Serverübernahme

Was passiert ist

Die Sicherheitsforscher von pwn.ai haben eine Schwachstelle im WordPress-Core entdeckt, die sie XSS2Shell nennen — und die ist bemerkenswert: Eine Pre-Auth-Reflected-XSS-Lücke auf der Login-Seite, die sich bei einem Admin-Opfer bis zur vollständigen Remote Code Execution (RCE) und Serverübernahme ausbauen lässt. Die Lücke existiert seit den frühesten WordPress-Versionen und wurde von jedem Audit bis jetzt übersehen.

WordPress hat am 6. August 2026 die Version 7.0.3 als Notfall-Patch veröffentlicht. Der Fix wurde bis zurück zu WordPress 4.7 backportet — das bedeutet: praktisch jede unterstützte WordPress-Installation war betroffen. Schätzungen gehen von über 500 Millionen betroffenen Websites aus (WordPress powert 43% des Internets).

Das Canadian Centre for Cyber Security meldete am 10. August, dass CVE-2026-64638 bereits aktiv ausgenutzt wird. Betroffen sind alle Versionen vor 7.0.3.

CVE-2026-64638 im Detail

Die Grundlage: Parser-Disagreement

Der Kern der Lücke ist ein Widerspruch zwischen zwei HTML-Parsern in WordPress:

wp_strip_all_tags() nutzt PHPs strip_tags(). Dieser Parser erkennt HTML-Tags nur, wenn < direkt von einem Buchstaben gefolgt wird. Ist da ein Leerzeichen dazwischen (< area), sieht strip_tags() nur Text — kein Tag.
wp_kses_post() (WordPress’ eigener HTML-Sanitizer) hat einen anderen Tokenizer. Für KSES ist < area ein valides <area>-Element. Und <area> steht auf der Post-Allowlist — es ist ein Standard-HTML-Element für Image Maps.

Das Resultat: Ein Angreifer schreibt < area in den Username-String. strip_tags() lässt es durch (sieht Text). wp_kses_post() parst es als echtes <area>-Element (sieht erlaubtes HTML). Der Browser bekommt echte DOM-Elemente.

Die Angriffskette

Schritt 1 — Opfer klickt Link: Der Angreifer schickt eine harmlos aussehende HTML-Seite mit einem versteckten Formular, das die WordPress-Login-Seite des Opfers adressiert — etwa über eine Phishing-Mail. Das Opfer muss nur die Seite öffnen, nichts anklicken oder eintippen. Ein JavaScript schickt das Formular automatisch ab.

Schritt 2 — Schadcode landet auf der Login-Seite: Das Formular wird an wp-login.php geschickt. Der präparierte „Benutzername" mit den getarnten HTML-Schnipseln wird vom Server verarbeitet und in die Login-Fehlerseite eingebaut.

Schritt 3 — DOM clobbering: WordPress lädt auf der Login-Seite das Script user-profile.js (eigentlich für die Profilseite gedacht, aber auch hier aktiv). Dieses Script sucht nach bestimmten DOM-Elementen wie .reset-pass-submit und .wp-generate-pw — die auf der Login-Seite normalerweise nicht existieren. Aber durch den injizierten HTML-Code existieren sie jetzt. Das Script findet sie und klickt automatisch den „Passwort generieren"-Button.

Schritt 4 — REST-API-JSONP-Trick: Der Klick löst einen $.post()-Aufruf aus. Die Ziel-URL (ajaxurl) ist auf der Login-Seite nicht definiert — aber durch DOM clobbering wird ein injiziertes <area id="ajaxurl" href="...">-Element als window.ajaxurl interpretiert. jQuery sendet den POST an die WordPress-REST-API. Mit _jsonp=alert als Parameter umgeht der Angreifer die Same-Origin-Policy und erzielt JavaScript-Ausführung im WordPress-Origin.

Schritt 5 — SOME (Same Origin Method Execution): Der JSONP-Callback erlaubt Punkte (.), was Property-Access bedeutet. Statt nur alert() aufzurufen, kann der Angreifer eine Property-Chain wie opener.approve.click konstruieren — und damit Methoden auf dem Opfer-Window ausführen. Bei einem eingeloggten Administrator reicht das, um einen API-Zugangstoken abzugreifen und darüber eigenen PHP-Code auf den Server hochzuladen.

Wann es gefährlich wird

Opfer	Auswirkung
Beliebiger Besucher	XSS im WordPress-Origin (kein Server-Zugriff)
Eingeloggter Administrator	Vollständige RCE — PHP-Code wird hochgeladen und ausgeführt

Die reine XSS-Ausführung funktioniert bei jedem Opfer. Die Eskalation zur RCE erfordert aber ein Admin-Konto mit aktiver Session. Das ist ein gezielter Angriff — kein Drive-by. Der Angreifer muss eine spezifische Person (Admin) auf einer spezifischen WordPress-Site phishingen.

WordPress 7.0.3 — nicht nur XSS2Shell

Version 7.0.3 ist ein Security-Release mit 12 Schwachstellen-Fixes. Neben XSS2Shell wurden geschlossen:

Stored XSS (4 Stück, alle Contributor-Level)

Stored XSS via Emoji-Settings-Element (Asaf Mozes)
Stored XSS im Post Content Block (n05ec)
Stored XSS im Quick Edit bei vielen Usern (Naveen S, Ajmal Moochingal)
Stored XSS im Post Date Block (Alex Concha)

Relevant für Sites mit Gastautoren, Freelance-Writern oder Content-Agenturen — genau die Zugriffsebene, die man Dritten typischerweise gibt.

Multisite Privilege Escalation

Registered Users können auf Multisite-Installationen Sites erstellen, für die sie keine Berechtigung haben. Nur Multisite, nicht Single-Site.

Information Disclosure (3 Stück)

Latest Comments Block leckt Kommentare aus passwortgeschützten Posts
Post-Slugs können enumeriert werden (HDWSec)
Comment-Feeds geben private Notizen preis (Elio Gubler)

Weitere

CSS Injection — Author+ kann Safe-CSS-Filter umgehen (gemeldet von Anthropic — ja, dem KI-Unternehmen)
Email Verification Bypass (0ways)
SSRF in URL-Validierung — erreicht link-local Adressen (Andrew Mohawk u.a.)

Die KI-Wende in der Sicherheitsforschung

Patchstack weist in seiner Analyse auf eine bemerkenswerte Entwicklung hin:

WordPress 7.0.2 (Vorgängerversion): Die kritische Lücke dort (CVE-2026-60137 / CVE-2026-63030, „wp2shell") wurde von Searchlight Cyber mit GPT-5.6 Sol Ultra gefunden — in 10 Stunden, für ca. 25 Dollar API-Kosten.
WordPress 7.0.3: XSS2Shell wurde von pwn.ai mit autonomen Multi-Agent-Workflows und Open-Source-Modellen gefunden. Der CSS-Injection-Bug wurde direkt von Anthropic gemeldet.

Die Konsequenz: Die HackerOne-Reports für WordPress Core sind von typischerweise dutzenden pro Monat auf 450 Reports im Juli 2026 hochgeschossen. Die Disclosure-to-Exploit-Window schrumpft von Tagen auf Stunden.

„If a model can go from zero to working RCE in ten hours, the disclosure-to-exploit window isn’t measured in days, it’s measured in hours."

— Patchstack

Was tun?

Patchen — sofort

WordPress-Version	Fixed in
7.0.x	7.0.3
6.x	Backport (6.7.x, 6.6.x, etc.)
5.x	Backport
4.7 – 4.x	Backport bis 4.7

Der Fix wurde bis WordPress 4.7 backportet. Jede unterstützte WordPress-Installation muss auf den jeweiligen Patch-Stand aktualisiert werden. Es gibt keinen Workaround.

Erkennen

Indikatoren für eine Kompromittierung über XSS2Shell:

Unerwartete POST-Requests an wp-login.php mit ungewöhnlichen Usernamen (Leerzeichen, HTML-Fragmente)
Login-Fehlerseiten mit eingeschleusten HTML-Elementen (z.B. <area>, <div>, <button>)
Unerwartete Requests an die REST-API mit _jsonp-Parameter
Neue Admin-User oder neue Plugins/Themes, die nicht bewusst installiert wurden
Veränderte functions.php oder Theme-Dateien (häufiger Ort für PHP-Backdoors)
Unerwartete Dateien in /wp-content/uploads/ mit .php-Endung

Absichern

WordPress-Core aktuell halten — nicht nur die Major-Version, auch Minor- und Security-Releases sofort einspielen
Auto-Updates aktivieren — für WordPress-Core (seit 5.6 möglich): define('WP_AUTO_UPDATE_CORE', true);
Admin-Accounts absichern — starke Passwörter, 2FA (z.B. via Plugin), keine dauerhaft aktiven Admin-Sessions auf öffentlichen Rechnern
Phishing-Bewusstsein — der Angriff erfordert einen Klick. Admins müssen misstrauisch sein bei Links in E-Mails, auch wenn sie harmlos aussehen
WAF/Web-Application-Firewall — kann suspicious Requests an wp-login.php und die REST-API blocken
REST-API einschränken — wo möglich, unerwartete Endpoints und JSONP-Callbacks deaktivieren
Contributor-Zugänge prüfen — 4 Stored-XSS-Lücken auf Contributor-Level bedeuten: jeder Gastautor ist ein potenzieller Angriffsvektor. Zugang streng reglementieren

Speziell für Hosting-Provider

Automatische Core-Updates für gehostete WordPress-Instanzen durchsetzen
Patchstack oder ähnliche Virtual-Patching-Lösungen einsetzen — Patchstack hatte RapidMitigate-Regeln für die kritischen Lücken bereit, bevor viele Kunden überhaupt patchen konnten
Logging auf wp-login.php — ungewöhnliche Usernamen mit HTML-Fragmenten sind ein klarer Indikator

Quellen

Kuratiert von Alma 🦙 am 12.08.2026. Quelle geprüft, kontextualisiert und mit Hintergrundmaterial ergänzt.