XSS2Shell: WordPress-Lücke aktiv ausgenutzt – Update auf 7.0.3 dringend

Veröffentlicht am 13.08.2026

Ein einziger Klick auf einen präparierten Link kann ausreichen, um eine WordPress-Website in die Hände von Angreifern zu bringen. Die als XSS2Shell bekannt gewordene Sicherheitslücke im Kern von WordPress wird laut einer offiziellen Warnung des kanadischen Cyber-Sicherheitszentrums bereits aktiv ausgenutzt. Sie trägt die Kennung CVE-2026-64638, ist mit einem CVSS-Wert von 8,9 als „hoch“ eingestuft und betrifft nicht etwa ein einzelnes Plugin, sondern den WordPress-Core selbst. Betroffen ist jede WordPress-Installation vor Version 7.0.3. Wer eine WordPress-Seite betreibt, sollte jetzt handeln.

Was ist passiert?

Sicherheitsforscher des Anbieters pwn.ai entdeckten am 26. Juli 2026 eine Schwachstelle, die sie XSS2Shell tauften. Der Name beschreibt bereits die Angriffskette: von einem Cross-Site-Scripting (kurz XSS, das Einschleusen von fremdem JavaScript-Code in eine Website) bis hin zur „Shell“, also der Ausführung von eigenem Programmcode auf dem Server.

Ausgangspunkt ist die Login-Seite wp-login.php – jene Seite, über die sich Administratoren anmelden. Sie ist ohne WordPress-Konto von außen erreichbar. Genau hier liegt das Problem: Ein Angreifer kann eine Person über einen präparierten Link auf einer fremden Website dazu bringen, diesen Link zu öffnen. Dann wird schädliches JavaScript im sogenannten Origin der WordPress-Seite ausgeführt – also so, als käme der Code direkt von der vertrauenswürdigen Website selbst. Man spricht von einem reflektierten XSS, weil die Login-Seite die manipulierte Eingabe an den Browser „zurückspiegelt“.

Bleibt es dabei, ist der Schaden begrenzt. Gefährlich wird es, wenn zum Zeitpunkt des Klicks ein Administrator angemeldet ist. Dann konnten die Forscher im Labor eine ganze Kette demonstrieren: Der eingeschleuste Code greift ein Application Password ab (ein spezielles Zugriffstoken für Programmschnittstellen), führt darüber privilegierte WordPress-Funktionen aus, lädt ein manipuliertes Plugin-Archiv hoch und bringt schließlich PHP-Code auf dem Server zur Ausführung – im Kontext des Webserver-Prozesses. Das ist der Weg zur vollständigen Serverübernahme.

Wichtig zur Einordnung: keine klicklose Serverübernahme

Auch wenn die Schlagzeilen dramatisch klingen: Es handelt sich nicht um eine Lücke, über die ein Server ohne Zutun des Opfers und ohne Anmeldung übernommen werden kann. Der WordPress-Hersteller stellt in seiner Sicherheitsmeldung ausdrücklich klar, dass die Eskalation zur Codeausführung zusätzliche Bedingungen erfordert:

„Über eine speziell präparierte, vom Angreifer gehostete Drittseite ist es möglich, dies zu einer RCE-Schwachstelle unter Bedingungen außerhalb der Kontrolle des Angreifers zu eskalieren. Dies erfordert erfolgreiches Social Engineering des und ausdrückliche Interaktion durch das Zielopfer.“ – WordPress Security Advisory GHSA-52p2-r8wf-jcrf

Auch der Telemetrieanbieter Imperva betont diese Unterscheidung:

„Eine wichtige Unterscheidung ist, dass CVE-2026-64638 nicht als eine unauthentifizierte RCE ohne Interaktion beschrieben werden sollte.“ – Imperva Threat Research

Das mindert die Dringlichkeit jedoch nicht: Der erste Schritt der Kette braucht kein Konto, die Lücke steckt im Core und die Website ist über das Netz erreichbar. Deshalb ist der Patch für jede öffentlich erreichbare WordPress-Instanz ein dringender Fall.

Der technische Hintergrund – verständlich erklärt

Die Ursache ist eine sogenannte Parser-Differenz: Zwei Filterfunktionen von WordPress beurteilen dasselbe fehlerhafte HTML-Markup unterschiedlich. Konkret durchläuft ein bei einem fehlgeschlagenen Login eingereichter Benutzername zunächst die Funktion wp_strip_all_tags() beziehungsweise das PHP-interne strip_tags() und anschließend wp_kses_post(). Weil beide Filter bestimmtes fehlerhaftes Markup verschieden einordnen, können angreiferkontrollierte Elemente in der Login-Antwort als echte DOM-Elemente wirksam werden – und das bereits geladene WordPress-JavaScript bringt sie in derselben Origin zur Ausführung. Kurz: Ein Fehler beim Bereinigen von Eingaben öffnet die Tür.

Wer ist betroffen?

Betroffen ist jede WordPress-Installation vor Version 7.0.3 beziehungsweise vor der jeweils gepatchten Version des genutzten Release-Zweigs. Weil es sich um den WordPress-Core handelt, spielt es keine Rolle, welche Plugins oder Themes im Einsatz sind.

Zur Größenordnung: Laut W3Techs lief WordPress am 12. August 2026 auf 41,0 % aller Websites weltweit und auf 59,0 % aller Websites mit bekanntem Content-Management-System. Diese Zahl beschreibt die Reichweite der Plattform – nicht die Zahl verwundbarer oder bereits kompromittierter Installationen.

Dass die Lücke tatsächlich angegriffen wird, ist gut belegt: Das Canadian Centre for Cyber Security veröffentlichte am 10. August 2026 die Warnung AV26-792 und erklärte unter Verweis auf Open-Source-Berichte, CVE-2026-64638 werde in freier Wildbahn ausgenutzt. Imperva berichtete am selben Tag von automatisiertem Targeting gegen mehr als 11.000 unterschiedliche Websites in 67 Ländern und Hunderttausenden Anfragen. Wichtig: Das sind Angriffsversuche und Anbieter-Telemetrie – keine verifizierte Zahl erfolgreicher Übernahmen oder kompromittierter Datensätze.

So prüfen Sie, ob Sie betroffen sind

1. Alle WordPress-Instanzen inventarisieren. Erfassen Sie nicht nur Ihre Hauptseite, sondern auch Staging-Systeme, Microsites, Kampagnenseiten und alte, vergessene Subdomains – einschließlich Installationen, die von Agenturen oder Hostern betrieben werden.
2. Die tatsächlich laufende Core-Version prüfen. Im Backend finden Sie sie unter Dashboard > Aktualisierungen. Wenn WP-CLI (die Kommandozeilen-Verwaltung von WordPress) verfügbar ist, liefert wp core version die Version. Bei gesperrtem Backend können Administrator oder Hoster die Datei wp-includes/version.php oder das Hosting-Patchprotokoll prüfen.
3. Mit der offiziellen Patch-Liste vergleichen. Jede Version, die vor der gepatchten Version ihres Zweigs liegt, ist dringend aktualisierungsbedürftig. WordPress 4.6 oder älter erhält keinen Fix und muss auf eine unterstützte Version migriert werden.
4. Den Update-Erfolg nachvollziehen. Verlassen Sie sich nicht blind auf automatische Updates – kontrollieren Sie Versionsstand, Zeitstempel und gegebenenfalls das Updateprotokoll. Legen Sie vor jedem Update ein geprüftes, rücksicherbares Backup von Dateien und Datenbank an.
5. Protokolle auf Auffälligkeiten prüfen. Untersuchen Sie Login-, Webserver-, WAF- und REST-Protokolle auf ungewöhnliche POST-Anfragen an wp-login.php, verdächtige REST-Aufrufe und Plugin-Upload-Ereignisse. Ein von pwn.ai beschriebener Untersuchungsindikator sind Login-POSTs, bei denen das Benutzername-Feld ein URL-kodiertes Kleiner-als-Zeichen enthält – das ist ein Hinweis für die Analyse, kein alleiniger Beweis einer Kompromittierung.
6. Administrations- und Dateispuren prüfen. Suchen Sie nach unbekannten Administratoren, unerklärlichen Application Passwords, neuen oder kürzlich geänderten Plugins und ungewöhnlichen Dateien unter wp-content/plugins/. Bei Verdacht: Zugänge absichern, Logs und Beweise sichern und qualifizierte Incident-Response-Unterstützung sowie den Hoster einbeziehen.

Das müssen Sie jetzt tun

Die gute Nachricht: Es gibt einen Patch. WordPress veröffentlichte am 6. August 2026 die Sicherheitsversion 7.0.3, die die Lücke schließt. Zusätzlich stehen Backports für alle damals sicherheitsgepflegten Zweige bis zurück zu Version 4.7 bereit – konkret die Versionen 6.9.6, 6.8.7, 6.7.6, 6.6.6, 6.5.9, 6.4.9, 6.3.9, 6.2.10, 6.1.11, 6.0.13, 5.9.14, 5.8.14, 5.7.16, 5.6.18, 5.5.19, 5.4.20, 5.3.22, 5.2.25, 5.1.23, 5.0.26, 4.9.30, 4.8.29 und 4.7.34. Für Version 4.6 und älter gibt es keinen Fix.

1. WordPress-Core unverzüglich aktualisieren – auf die gepatchte Version Ihres Zweigs, bevorzugt auf die neueste unterstützte Version. Das ist die einzige echte Abhilfe gegen die zugrunde liegende XSS-Lücke.
2. Update kontrollieren und Backup sichern. Prüfen Sie nach dem Update die laufende Version und stellen Sie einen getesteten Wiederherstellungsweg sicher. Halten Sie danach auch Plugins, Themes und PHP-Version aktuell – das ersetzt den Core-Patch aber nicht.
3. Application Passwords deaktivieren, sofern sie für keine notwendige Integration gebraucht werden. Das nimmt der demonstrierten Angriffskette einen wichtigen Eskalationsschritt.
4. Dateiänderungen härten. Wenn Sie Plugins und Themes über einen kontrollierten Deployment-Prozess ausrollen, erwägen Sie DISALLOW_FILE_MODS in wp-config.php und unterbinden Sie serverseitig die direkte PHP-Ausführung aus nicht benötigten, beschreibbaren Verzeichnissen. Prüfen Sie vorher Kompatibilität und Betriebsablauf.
5. Admin-Rechte begrenzen und absichern. Beschränken Sie Administratorrechte auf notwendige Personen, setzen Sie Mehrfaktor-Authentisierung für Admin-Konten ein und weisen Sie Administratoren an, keine unbekannten Links in einem Browserprofil mit aktiver WordPress-Admin-Sitzung zu öffnen. Genau diese aktive Interaktion braucht der vollständige RCE-Pfad.
6. WAF-Regeln nur als Ergänzung. Temporäre Regeln in einer Web Application Firewall oder einem Reverse Proxy können auffällige, fehlerhaft formatierte Login-Anfragen blockieren oder protokollieren – sie müssen getestet werden und ersetzen den Patch nicht.

Ein wichtiger Hinweis von der University of Toronto: Eine strenge Content Security Policy (eine Browser-Schutzregel gegen fremden Code) half im Test nicht:

„Eine nonce-basierte Content Security Policy mit strict-dynamic wurde gegen den demonstrierten Pfad getestet und verhinderte die Ausnutzung nicht; CSP ist keine kompensierende Maßnahme.“ – University of Toronto Information Security

DSGVO: Was Sie rechtlich beachten müssen

Eine ungepatchte Sicherheitslücke ist noch keine meldepflichtige Datenschutzverletzung. Ergibt Ihre Untersuchung jedoch, dass durch eine erfolgreiche Kompromittierung personenbezogene Daten betroffen sein könnten, müssen Sie die Artikel 33 und 34 DSGVO prüfen.

• Art. 33 DSGVO: Die zuständige Aufsichtsbehörde ist unverzüglich und möglichst binnen 72 Stunden nach Kenntnis zu informieren – es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen. Alle Datenschutzverletzungen sind zu dokumentieren.
• Art. 34 DSGVO: Besteht voraussichtlich ein hohes Risiko, sind grundsätzlich auch die betroffenen Personen unverzüglich zu benachrichtigen.

Für die Einzelfallentscheidung dokumentieren Sie Art und Umfang der möglicherweise abgeflossenen Daten, ob sie verschlüsselt waren, welche Zugriffsspuren es gibt und welche Maßnahmen Sie ergriffen haben. Beziehen Sie Datenschutzbeauftragte, die zuständige Aufsichtsbehörde und gegebenenfalls Rechtsberatung frühzeitig ein.

Dass Aufsichtsbehörden unzureichende Sicherheitsmaßnahmen ahnden, zeigt die deutsche Praxis: Der Bundesbeauftragte für den Datenschutz (BfDI) verhängte 2019 gegen 1&1 Telecom 9,55 Mio. Euro wegen unzureichender Authentifizierungsmaßnahmen und 2025 gegen Vodafone 30 Mio. Euro wegen Sicherheitsmängeln im Authentifizierungsprozess. Beide Fälle betreffen nicht WordPress und erlauben keine Bußgeldprognose für KMU – sie belegen aber die Relevanz von Art. 32 DSGVO (angemessene technische und organisatorische Sicherheit). BfDI-Chefin Prof. Dr. Louisa Specht-Riemenschneider bringt es auf den Punkt:

„Ohne IT-Investitionen drohen Sicherheitsvorfälle und auch Sanktionen der Datenschutzaufsicht. Daher mein Aufruf: Investieren statt Riskieren!“ – Prof. Dr. Louisa Specht-Riemenschneider, BfDI

Fazit

XSS2Shell (CVE-2026-64638) ist eine ernstzunehmende Lücke im WordPress-Core, die bereits aktiv angegriffen wird. Sie ist keine klicklose, kontenlose Serverübernahme – die vollständige Codeausführung setzt einen angemeldeten Administrator, dessen aktive Interaktion und weitere technische Voraussetzungen voraus. Genau deshalb sollten Sie Panik vermeiden, aber unverzüglich handeln.

Die Priorität ist klar: Aktualisieren Sie jeden WordPress-Auftritt sofort auf eine gepatchte Version, kontrollieren Sie den Update-Stand, sichern Sie Ihre Admin-Konten mit Mehrfaktor-Authentisierung und deaktivieren Sie nicht benötigte Application Passwords. Prüfen Sie Ihre Protokolle auf verdächtige Login-Anfragen und Plugin-Uploads. Und dokumentieren Sie Ihr Vorgehen – falls sich später doch ein Datenabfluss zeigt, sind Sie für die DSGVO-Fristen gerüstet. Wer bei über 40 Prozent Marktanteil eine WordPress-Seite betreibt, gehört zur potenziellen Zielgruppe der automatisierten Angriffswellen. Ein zeitnahes Update ist die beste und einzige echte Abhilfe.