XSS2Shell: Wenn die WordPress-Login-Seite zur Hintertür wird (CVE-2026-64638)

Kurzfassung: Nur wenige Wochen nach der kritischen Core-Lücke wp2shell trifft WordPress die nächste schwere Schwachstelle – diesmal an einer Stelle, an die kaum jemand denkt: der Login-Seite. Die als XSS2Shell (CVE-2026-64638) bezeichnete Lücke beginnt mit einem harmlos wirkenden fehlgeschlagenen Login-Versuch und kann, wenn ein eingeloggter Administrator mitspielt, bis zur vollständigen Übernahme des Servers führen. Dieser Artikel erklärt verständlich, wie der Angriff funktioniert, wer betroffen ist, wie ernst die Lage aktuell wirklich ist – und welche Schritte Sie jetzt gehen sollten.

Was XSS2Shell ist – und warum die Login-Seite plötzlich zum Risiko wird

Die WordPress-Anmeldeseite wp-login.php gilt seit jeher als eine der best-geprüften Dateien im gesamten Projekt. Genau dort steckt jedoch eine Schwachstelle, die dem Sicherheitsteam von pwn.ai zufolge seit den frühesten WordPress-Versionen unentdeckt geblieben ist. Die Forscher tauften die Angriffskette XSS2Shell: von einem Cross-Site-Scripting (XSS) auf der Login-Seite bis zur „Shell“, also der Kommandozeilen-Kontrolle über den Server.

Das Deutsche IT-Fachmedium heise beschreibt den Kern des Problems treffend: „Fallen Opfer auf Angreifer rein und klicken auf einen Link, kann das zur WordPress-Serverübernahme führen.“ Entscheidend ist dieses „Mitspielen“: XSS2Shell ist kein vollautomatischer Ein-Klick-Total­ausfall, sondern ein Angriff, der ein Opfer – im schlimmsten Fall einen eingeloggten Administrator – zu einer Interaktion verleiten muss. Genau das macht die Lücke tückisch, denn Phishing-Links landen täglich millionenfach in Postfächern.

Die Schwachstelle trägt die Kennung CVE-2026-64638 und einen CVSS-Schweregrad von 8.9 von 10, eingestuft als „hoch“. Das ist eine Stufe unter der Höchstwertung, die die Core-Lücke wp2shell im Juli erhielt – aber, wie wir weiter unten zeigen, kein Grund zur Entwarnung.

Der Unterschied zu wp2shell: zwei schwere Core-Lücken in wenigen Wochen

Wer unseren Beitrag zu wp2shell gelesen hat, könnte XSS2Shell für dieselbe Lücke halten. Das ist nicht der Fall – und der Unterschied ist wichtig:

• wp2shell (CVE-2026-63030) war eine vorauthentifizierte Remote-Code-Execution ohne jede Nutzerbeteiligung: eine einzige HTTP-Anfrage genügte, kein Opfer musste irgendetwas anklicken. CVSS 9.8.
• XSS2Shell (CVE-2026-64638) ist eine vorauthentifizierte XSS-Lücke. Der reine Skript-Ausführungs-Teil funktioniert zwar ebenfalls ohne Login des Opfers, aber der Weg bis zur Serverübernahme erfordert, dass ein angemeldeter Administrator eine präparierte Seite öffnet und dort interagiert. CVSS 8.9.

Für Website-Betreiber ist die eigentliche Botschaft nicht die eine oder andere CVE-Nummer, sondern das Muster dahinter: Innerhalb weniger Wochen wurden zwei gravierende Schwachstellen direkt im WordPress-Kern gefunden – nicht in einem obskuren Plugin, sondern in Code, den über 40 Prozent aller Websites im Internet ausführen. Wer glaubt, ein sauber gepflegtes System ohne exotische Erweiterungen sei automatisch sicher, wird hier eines Besseren belehrt. Sicherheit entsteht nicht durch die Abwesenheit von Plugins, sondern durch das konsequente und schnelle Einspielen von Updates.

Wie der Angriff technisch funktioniert – Schritt für Schritt

Man muss kein Entwickler sein, um XSS2Shell zu verstehen. Der Trick beruht auf einem klassischen Muster: Zwei Programmteile sind sich uneinig darüber, was „gefährlich“ ist.

1. Die Uneinigkeit zweier Filter

Wenn jemand auf der Login-Seite einen falschen Benutzernamen eingibt, baut WordPress eine Fehlermeldung, in die dieser Benutzername eingebettet wird. Vorher läuft der Wert durch eine Filterfunktion (wp_strip_all_tags(), intern PHPs strip_tags()), die HTML-Tags entfernen soll. Diese Funktion erkennt ein Tag jedoch nur, wenn direkt hinter dem < ein Buchstabe folgt. Steht dort ein Leerzeichen, hält der Filter das Ganze für harmlosen Text und lässt es durch.

Kurz darauf schickt WordPress denselben Wert durch einen zweiten Filter (wp_kses_post()) mit einem völlig anderen Parser. Dieser interpretiert < area sehr wohl als gültiges HTML-Element <area> – das auf der Erlaubnisliste steht. Das Ergebnis: Der erste Filter sagt „ist Text“, der zweite sagt „ist erlaubtes HTML“ – und der Browser des Opfers erhält am Ende genau die DOM-Elemente, die der Angreifer bestimmt hat.

2. WordPress‘ eigenes JavaScript wird zur Waffe

Reine HTML-Elemente sind noch kein ausführbarer Code. Der zweite Kniff: Auf der Login-Seite lädt WordPress das Skript user-profile.js mit – eigentlich für den Passwort-Reset-Ablauf gedacht. Über geschickt platzierte Elemente mit bestimmten IDs und Klassen bringt der Angreifer dieses legitime WordPress-Skript dazu, automatisch eine Aktion auszulösen. Fehlende Variablen wie ajaxurl werden per „DOM Clobbering“ durch ein eingeschleustes Element ersetzt, sodass WordPress‘ eigener Code eine vom Angreifer gewählte Anfrage im Ursprung (Origin) der echten Website abschickt. Weil alles unter der echten Domain passiert, läuft der Schadcode mit den Rechten und Cookies des Opfers.

3. Von XSS zur Serverübernahme

Bis hierher liegt „nur“ eine XSS-Ausführung vor. Für die eigentliche Übernahme kombinieren die Forscher eine 2022 von Paulos Yibelo publizierte Technik namens Same Origin Method Execution (SOME) mit WordPress‘ JSONP-Funktion der REST-API. Ist das Opfer als Administrator eingeloggt und öffnet die Angreifer-Seite, läuft folgende Kette ab:

1. Der eingeschleuste Code klickt im Hintergrund die Freigabe-Schaltfläche der WordPress-Application-Passwords-Seite an – innerhalb der echten Admin-Sitzung.
2. WordPress erzeugt daraufhin ein gültiges API-Zugangspasswort und übergibt es an eine vom Angreifer kontrollierte Adresse.
3. Mit diesem Zugang veröffentlicht der Angreifer eine Seite mit eigenem JavaScript, lädt anschließend ein als Plugin getarntes ZIP-Archiv hoch – und die darin enthaltenen PHP-Dateien sind direkt über die URL aufrufbar, ohne dass das Plugin aktiviert werden muss.

Ab diesem Punkt gilt die Installation als vollständig kompromittiert: Der Angreifer kann die Datenbank-Zugangsdaten aus wp-config.php auslesen, dauerhaft eigene Administratoren anlegen und Betriebssystem-Befehle mit den Rechten des Webserver-Prozesses ausführen.

Bemerkenswert am Rande: pwn.ai gibt an, die gesamte Angriffskette weitgehend autonom mit einem KI-gestützten Multi-Agenten-Workflow in nur rund vier Tagen rekonstruiert zu haben. Ein Vorgeschmack darauf, wie sich die Geschwindigkeit von Schwachstellenforschung – und damit von Angriffen – verändert.

Welche WordPress-Versionen betroffen sind

WordPress-Version	Status
Jede gewartete Version vor 7.0.3	Betroffen – Update dringend erforderlich
7.0.3 (und die zurückportierten Wartungs-Releases bis 4.7)	Sicher – enthält den Patch
Versionen älter als 4.7	Betroffen, aber außerhalb des offiziellen Backport-Zeitraums – Migration nötig

Der Fix erschien am 6. August 2026 mit WordPress 7.0.3, einer reinen Sicherheitsversion, die laut WordPress.org insgesamt zwölf Schwachstellen behebt. XSS2Shell ist davon die schwerwiegendste und die einzige, die WordPress ausdrücklich als vorauthentifiziert und mit Potenzial zur PHP-Codeausführung einstuft. Die Korrektur wurde bis zurück zum Zweig 4.7 zurückportiert. Installationen mit aktivierten automatischen Hintergrund-Updates sollten das Update automatisch erhalten haben – aber, und das ist entscheidend, „sollten“ ist nicht „haben“. Ob das Update tatsächlich angekommen ist, hängt von Hoster, Konfiguration und eventuell deaktivierten Auto-Updates ab. Prüfen Sie die Version manuell im Dashboard.

Wird die Lücke bereits ausgenutzt? Die aktuelle Lage

Hier lohnt ein genauer, ehrlicher Blick, weil verschiedene Quellen unterschiedliche Nuancen berichten:

• Das Canadian Centre for Cyber Security weist in einem Advisory (AV26-792) darauf hin, dass es Hinweise auf eine bereits laufende Ausnutzung der Lücke gibt – so berichtet es auch heise.
• WordPress selbst stufte die Ausnutzbarkeit in seinem Advisory zum Zeitpunkt der Veröffentlichung (7. August 2026) zurückhaltender ein: Ein Ausbau bis zur Codeausführung setze erfolgreiches Social Engineering und eine ausdrückliche Interaktion des Opfers voraus. In-the-wild-Angriffe wurden dort zunächst nicht bestätigt.
• Sicherheitsanbieter reagieren bereits: Imperva bestätigt, dass Kunden seiner Cloud- und On-Prem-WAF gegen die im Angriff genutzten Eingaben geschützt sind. Ein öffentliches Erkennungs-Template kursiert; die vollständigen technischen Details sind seit dem 7. August offen dokumentiert.

Die Erfahrung mit wp2shell mahnt zur Eile: Dort begann die Massenausnutzung nur einen Tag nach Veröffentlichung des Patches. Sobald technische Details öffentlich sind, verkürzt sich das Zeitfenster zwischen Offenlegung und automatisierten Angriffen dramatisch. Auf „bei uns wird schon nichts passieren“ zu setzen, ist bei einer Core-Lücke dieser Klasse keine Strategie.

„Nur hoch“ statt „kritisch“ – warum das trotzdem gefährlich ist

Der CVSS-Wert von 8.9 liegt unter der 9.8 von wp2shell, weil der Angriff eine Nutzerinteraktion erfordert. Diese Einordnung ist technisch korrekt, verleitet aber zu einem gefährlichen Trugschluss. In der Praxis ist genau die benötigte Interaktion – ein Klick auf einen präparierten Link – der am leichtesten zu beschaffende Baustein eines Angriffs. Phishing gegen Administratoren, gefälschte Plugin-Update-Benachrichtigungen oder manipulierte E-Mails an Redaktionsteams gehören zum Alltag. Wer im Backend eingeloggt ist und nebenbei einen Link öffnet, liefert dem Angreifer die fehlende Zutat frei Haus.

Hinzu kommt: Bekannte Härtungsmaßnahmen bieten laut den Forschern keinen vollständigen Schutz. Selbst eine Content-Security-Policy mit strict-dynamic hielt den demonstrierten Weg im Test nicht auf. Die einzig verlässliche Gegenmaßnahme bleibt das Einspielen des Updates.

Sofortmaßnahmen: Was Sie jetzt tun sollten

1. WordPress-Version prüfen. Im Backend unter Dashboard → Aktualisierungen. Alles unterhalb der jeweils aktuellen, gepatchten Wartungsversion Ihres Zweigs ist verwundbar.
2. Sofort auf 7.0.3 (bzw. das gepatchte Release Ihres Zweigs) aktualisieren. Das Update ist kostenlos und in wenigen Minuten eingespielt. Erstellen Sie vorher ein Backup.
3. Automatische Updates aktivieren. Prüfen Sie, ob Auto-Updates für den Core eingeschaltet sind – häufig wurden sie in der Vergangenheit bewusst deaktiviert und nie wieder aktiviert.
4. Administrator-Konten kontrollieren. Sehen Sie die Benutzerliste durch und entfernen Sie unbekannte Admin-Konten. Achten Sie auf kürzlich angelegte Application-Passwords (unter Benutzer → Profil) und widerrufen Sie verdächtige Einträge.
5. Administratoren sensibilisieren. Weisen Sie Ihr Team darauf hin, im eingeloggten Zustand keine unbekannten Links zu öffnen. Nutzen Sie nach Möglichkeit getrennte Browser-Profile für die WordPress-Administration.
6. Im Zweifel prüfen lassen. Wenn Sie unsicher sind, ob Ihre Seite bereits kompromittiert wurde, holen Sie professionelle Hilfe, bevor Sie auf eigene Faust Dateien löschen und Spuren vernichten.

Woran Sie eine Kompromittierung erkennen

Eine erfolgreiche Übernahme bleibt oft tagelang unbemerkt. Achten Sie auf diese Warnsignale:

• Unbekannte Administrator-Konten oder neue Application-Passwords im Backend
• Neu installierte oder unbekannte Plugins, die niemand aus dem Team hinzugefügt hat
• Besucher werden auf fremde Domains weitergeleitet (Pharma-, Glücksspiel- oder Krypto-Spam)
• In der Google Search Console tauchen fremde Unterseiten mit Spam-Keywords auf
• Ihr Hoster meldet verdächtige Aktivität oder sperrt die Website
• Das Backend lädt ungewöhnlich langsam oder zeigt PHP-Fehlermeldungen

Trifft auch nur eines dieser Symptome zu, sollten Sie handeln. Unsere kostenlose Erstprüfung klärt innerhalb kurzer Zeit, ob Ihre Website tatsächlich betroffen ist.

Warum Updates allein oft nicht reichen

Das Einspielen des Patches schließt die Lücke – aber es beantwortet nicht die eigentliche Frage: Wer sorgt dafür, dass das nächste kritische Update rechtzeitig kommt? Zwischen wp2shell und XSS2Shell lagen keine drei Wochen. Beide erforderten schnelles Handeln, beide betrafen den Kern. Für viele Unternehmen ist die manuelle Überwachung solcher Meldungen schlicht nicht leistbar – die Nachricht erreicht sie oft erst, wenn der Schaden bereits entstanden ist.

Mehr als 95 Prozent aller WordPress-Hacks nutzen nach Branchendaten bekannte, längst gepatchte Schwachstellen aus. Nicht raffinierte Null-Day-Angriffe, sondern schlicht veraltete Software. Das bedeutet umgekehrt: Wer Updates konsequent und zeitnah einspielt, übersteht die allermeisten Angriffe unbeschadet.

Dauerschutz durch professionelle WordPress-Wartung aus München

Genau an dieser Stelle setzt CMS ADMINS an. Als spezialisierter Dienstleister für WordPress-Wartung und -Sicherheit mit Sitz in München und Serverstandort Deutschland betreuen wir seit über zehn Jahren Websites von Unternehmen, Agenturen und Selbstständigen. Sicherheits-Updates wie der Patch gegen XSS2Shell werden bei uns priorisiert und zeitnah eingespielt – ohne dass Sie die Meldungen selbst verfolgen müssen. Konkret bei XSS2Shell: Alle Websites, die bei uns in der Wartung sind, waren bereits rund zwei Stunden nach Erscheinen des Updates auf den abgesicherten Stand aktualisiert – während viele andere Installationen zu diesem Zeitpunkt noch offen standen.

Unser WordPress-Wartungsvertrag ab 9,50 € pro Monat umfasst:

• Regelmäßige Aktualisierung von WordPress-Core, Plugins und Themes – Sicherheits-Patches priorisiert
• 60 Tage Echtzeit-Backups auf deutschen Servern, DSGVO-konform
• 24/7-Monitoring, das Ausfälle und Malware-Signale erkennt, bevor Ihre Kunden sie bemerken
• reportedIP Pro inklusive: Brute-Force-Schutz, Zwei-Faktor-Authentifizierung und IP-Reputation aus einem deutschen Bedrohungsnetzwerk

Sollte trotz aller Vorsicht der Ernstfall eintreten, ist unsere Notfall-Bereinigung rund um die Uhr erreichbar. Die Erstprüfung ist kostenlos, danach erhalten Sie ein verbindliches Festpreis-Angebot. Je nach SLA-Stufe reagieren wir innerhalb von 24 Stunden (Critical), 48 Stunden (Express) oder drei Werktagen (Standard).

Notfall-Kontakt CMS ADMINS: +49 89 21550588-8 · 24/7 erreichbar · Erstprüfung kostenlos

Häufig gestellte Fragen zu XSS2Shell

Ist meine WordPress-Seite automatisch geschützt, wenn ich Auto-Updates aktiviert habe?
In der Regel ja – WordPress hat den Fix als Sicherheitsrelease ausgerollt, und Seiten mit aktiven Hintergrund-Updates sollten 7.0.3 (oder das gepatchte Release ihres Zweigs) erhalten haben. Verlassen Sie sich aber nicht darauf, sondern prüfen Sie die Version im Dashboard. Auto-Updates werden häufiger deaktiviert, als man denkt.

Ich habe eine WAF oder ein Sicherheits-Plugin. Reicht das?
Anbieter wie Imperva und andere haben Schutzregeln ausgerollt, die einen Teil der Angriffe abfangen. Das reduziert das Risiko, ersetzt das Update aber nicht. Die Forscher weisen ausdrücklich darauf hin, dass gängige Härtungsmaßnahmen keinen vollständigen Schutz bieten. Der Patch bleibt Pflicht.

Betrifft mich die Lücke, wenn ich keine unbekannten Plugins nutze?
Ja. XSS2Shell steckt im WordPress-Kern selbst, nicht in einem Plugin. Eine „saubere“ Installation ohne Fremd-Erweiterungen war genauso verwundbar wie jede andere.

Wie unterscheidet sich XSS2Shell von wp2shell?
wp2shell (CVE-2026-63030) erlaubte die Serverübernahme mit einer einzigen Anfrage ohne jede Nutzerbeteiligung. XSS2Shell (CVE-2026-64638) benötigt für den Weg bis zur Codeausführung, dass ein eingeloggter Administrator eine präparierte Seite öffnet und dort interagiert. Beide betreffen den WordPress-Kern und wurden innerhalb weniger Wochen bekannt.

Woran erkenne ich, ob ich bereits gehackt wurde?
Typische Zeichen sind unbekannte Administrator-Konten, neue Application-Passwords, fremde Plugins, Weiterleitungen auf Spam-Seiten oder unbekannte Unterseiten in der Google Search Console. Im Zweifel klärt unsere kostenlose Erstprüfung, ob Ihre Seite betroffen ist.

Fazit

XSS2Shell zeigt zweierlei: Erstens, dass selbst die am gründlichsten geprüften Teile von WordPress noch schwerwiegende Schwachstellen bergen können. Zweitens, dass die Zeitfenster zwischen Offenlegung und Ausnutzung immer kleiner werden – nicht zuletzt, weil KI-gestützte Forschung die Entwicklung funktionierender Angriffsketten beschleunigt. Die gute Nachricht bleibt: Der Patch ist da, kostenlos und in Minuten eingespielt. Aktualisieren Sie jetzt auf WordPress 7.0.3, prüfen Sie Ihre Administrator-Konten – und überlegen Sie, ob Sie das Verfolgen solcher Meldungen wirklich selbst leisten wollen oder besser in professionelle Hände geben.

Wollen Sie sichergehen, dass Ihnen die nächste Core-Lücke nicht durchrutscht? Ein WordPress-Wartungsvertrag ab 9,50 € pro Monat ist die einfachste und günstigste Absicherung – Updates, Echtzeit-Backups und Monitoring inklusive.

Update vom 12. August 2026: WordPress 7.0.4 schließt weitere RCE-Lücke

Nur sechs Tage nach 7.0.3 hat WordPress am 12. August 2026 die Version 7.0.4 nachgeschoben – erneut eine reine Sicherheitsversion. Geschlossen wird diesmal eine authentifizierte Remote-Code-Execution über einen manipulierten Datei-Upload (CVE-2026-65640), die ausschließlich Seiten betrifft, die zur Bildverarbeitung Imagick in Kombination mit Ghostscript einsetzen. Gemeldet wurde auch diese Lücke vom Team von pwn.ai, der Fix ist bis zum Zweig 4.7 zurückportiert.

Die gute Nachricht: Anders als XSS2Shell setzt dieser Angriff bereits ein Konto mit mindestens Autoren-Rechten und den passenden Server-Stack voraus – das Risiko einer breiten, automatisierten Ausnutzung ist damit deutlich geringer. Trotzdem gilt auch hier: zeitnah aktualisieren. Wer 7.0.3 bereits eingespielt hat, sollte direkt auf 7.0.4 nachziehen. Für unsere Wartungskunden ist das Update bereits Teil des laufenden, priorisierten Sicherheits-Rollouts.

---

Quellen: pwn.ai (XSS2Shell-Analyse), heise online, The Hacker News, WordPress.org (Releases 7.0.3 & 7.0.4), Imperva, Canadian Centre for Cyber Security (AV26-792). CVE-Details: CVE-2026-64638, CVE-2026-65640. Letzte Aktualisierung: 12. August 2026.