Aktuelles

Kein Scheunentor - aber immerhin eine offene Kellertür: WordPress XSS2Shell und was jetzt zu tun ist

Manchmal reicht ein falsch eingetippter Benutzername, um das halbe Internet ins Wanken zu bringen. Genau das ist gerade mit WordPress passiert, und die Ironie könnte kaum größer sein: Ausgerechnet die Login-Seite, also der Ort, an dem WordPress eigentlich beweisen will, dass es was auf Sicherheit hält, war die Einfallschneise für eine Kette, die am Ende mit ausführbarem PHP-Code auf dem Server endet. Klingt nach Klickbait und Panikmache? Ist aber, mit ein paar Einschränkungen, ziemlich genau das, was passiert ist.

Die Kollegen von heise haben es vergangene Woche bereits berichtet, unter dem schönen Namen XSS2Shell. Und wer wie wir tagtäglich fremde WordPress-Installationen entstört, aufräumt oder aus Malware-Trümmern wieder zusammenbaut, liest solche Meldungen nicht mit akademischem Interesse, sondern mit einem leisen Ziehen im Magen. Ein paar Seiten aus dem eigenen Bekanntenkreis waren in den letzten Monaten betroffen von genau der Sorte Angriff, bei der man hinterher nie ganz sicher sagen kann, über welche Tür die Einbrecher eigentlich reingekommen sind. Jetzt gibt es zumindest für einen möglichen Fall einen Namen, eine CVE-Nummer und ein Update.

Es beginnt mit einem Tippfehler

Der Einstiegspunkt ist fast schon unverschämt banal. Man tippt auf der WordPress-Login-Seite einen Benutzernamen ein, den es gar nicht gibt. WordPress ist höflich genug, das in der Fehlermeldung zu quittieren, samt einer Wiederholung dessen, was man eingegeben hat. Dieses Wiederholen läuft über eine Funktion, die eigentlich HTML-Tags rausfiltern soll, bevor daraus Schindluder getrieben werden kann.

Das Problem: Diese Filterfunktion und die Stelle, die den gefilterten Text später als Markup interpretiert, sind sich nicht ganz einig darüber, was eigentlich ein Tag ist. PHPs strip_tags() erkennt ein Tag nur, wenn direkt nach der spitzen Klammer ein Buchstabe folgt. Schiebt man ein Leerzeichen dazwischen, etwa < area id=test>, ist das für den Filter kein Tag mehr, sondern harmloser Text. WordPress selbst sieht das an anderer Stelle anders und rendert es doch als Markup. Zwei Komponenten derselben Software, unterschiedliche Meinung, ein Loch dazwischen. Genau aus solchen Meinungsverschiedenheiten bestehen die interessanten Lücken, nicht aus vergessenen Prüfungen.

Vom pöhsen Link zur Serverübernahme

Für sich genommen wäre das eine mittelprächtige Cross-Site-Scripting-Lücke, wie es sie im Web-Alltag ständig gibt. Was die Sache zu XSS2Shell macht, ist das, was das Sicherheitsteam von pwn.ai daraus gebastelt hat: eine mehrstufige Kette, die DOM Clobbering, ein automatisch ausgeführtes Core-Skript, die REST-API mit einem manipulierten JSONP-Callback und einen sogenannten Same-Origin-Method-Execution-Trick kombiniert, um browserübergreifend an das Application Password eines eingeloggten Administrators zu kommen. Mit diesem Zugangsschlüssel lässt sich anschließend ein präpariertes Plugin als ZIP hochladen, und von da ist der Weg zu PHP-Code auf dem Server nur noch Kinderkacke.

Bemerkenswert ist auch, wie diese Kette entstanden ist: Die Forscher setzten dafür KI-gestützte Multi-Agent-Recherche ein, aufbauend auf älteren Arbeiten zu Same Origin Method Execution, und brauchten dafür rund vier Tage. Das sagt weniger über WordPress aus als über die Richtung, in die Sicherheitsforschung gerade kippt. Wenn Angreifer irgendwann dieselben Werkzeuge einsetzen, wird die Zeitspanne zwischen "Lücke gefunden" und "Exploit im Umlauf" nicht länger, sondern kürzer.

Bevor jetzt alle WordPress-User in Panik verfallen: Es handelt sich nicht um eine Lücke, die aus dem Nichts und ganz ohne Zutun zur Serverübernahme führt. Der XSS-Teil braucht kein Konto und keine Anmeldung, das stimmt. Aber der Sprung zur Codeausführung setzt voraus, dass ein eingeloggter Administrator auf einen präparierten Link klickt oder eine präparierte Seite besucht, meist über Phishing. Ohne diesen einen unbedachten Klick bleibt es bei "peinlich", und nicht bei "Totalschaden". Das ist der Unterschied zwischen einer offenen Tür und einer Tür, die aufgeht, wenn jemand freundlich anklopft und man selbst öffnet.

Die Fakten in Kurzform

XSS2Shell ist nicht wp2shell - auch wenn die Namen verwirren

Wer in den letzten Wochen aufmerksam die Sicherheitsmeldungen verfolgt hat, könnte jetzt stutzen: War da nicht schon mal was mit einer Serverübernahme ganz ohne Login? Ja, das war eine andere Lücke, wp2shell genannt, bestehend aus CVE-2026-63030 und CVE-2026-60137, geschlossen bereits Mitte Juli in den Versionen 7.0.2 und 6.9.5. Wer diesen Patch eingespielt hat, ist gegen wp2shell geschützt, aber eben nicht automatisch gegen XSS2Shell drei Wochen später. Zwei unterschiedliche Baustellen, zwei unterschiedliche Patches, und ein Namensschema, das offenbar darauf abzielt, System-Administratoren zusätzlich zu verwirren. Danke dafür.

Wie gefährlich ist es wirklich gerade jetzt

Der offizielle WordPress-Advisory vermeldet bislang keine bestätigte Ausnutzung in freier Wildbahn. Das kanadische Canadian Centre for Cyber Security berichtet dagegen, es gebe Hinweise auf bereits laufende Angriffsversuche. Beides schließt sich nicht zwingend aus, es zeigt eher, wie unterschiedlich schnell verschiedene Stellen an verlässliche Telemetriedaten kommen. Die Forscher von pwn.ai haben ihren vollständigen Proof-of-Concept bewusst zurückgehalten, um Betreibern Zeit zum Patchen zu geben. Erfahrungsgemäß ist dieses Zeitfenster bei einer derart gründlich dokumentierten Lücke eher mit Tagen als mit Wochen zu bemessen. Automatisierte Scanner, die gezielt nach dem Muster suchen, gibt es vermutlich längst.

Was bei WP-Installationen jetzt zu tun ist

Die gute Nachricht zuerst: Der Patch existiert, ist unkompliziert und WordPress hat die Version 7.0.3 gleich für elf weitere Sicherheitsprobleme genutzt, überwiegend Cross-Site-Scripting, dazu eine Rechteausweitung, eine SSRF-Lücke und ein Bypass bei der E-Mail-Bestätigung. Wer das Update noch nicht abgefrühstückt hat, sollte es nicht auf die lange Bank schieben!

• Version prüfen: Im Backend unter Dashboard nachsehen, ob 7.0.3 oder eine entsprechend gepatchte Wartungsversion installiert ist. Automatische Updates sind praktisch, aber kein Ersatz für einen manuellen Blick, besonders bei Managed-Hosting-Umgebungen mit eigenwilligen Update-Zyklen.
• Login-Seite absichern: Die klassischen Maßnahmen wie Zwei-Faktor-Authentifizierung für Administratorkonten, eine verschobene oder umbenannte Login-URL und ein Web Application Firewall vor der Installation entschärfen nicht nur diese, sondern gleich eine ganze Klasse ähnlicher Angriffe.
• Application Passwords kontrollieren: Unter Benutzer, Profil nachsehen, ob dort Anwendungspasswörter existieren, die niemand aktiv angelegt hat. Ein unbekannter Eintrag mit verdächtigem Namen und aktuellem Erstellungsdatum ist ein starkes Warnsignal.
• Zugriffslogs durchsehen: Verdächtig sind POST-Anfragen an wp-login.php, deren Benutzername-Feld eine spitze Klammer gefolgt von einem Leerzeichen enthält, ebenso REST-API-Aufrufe mit einem _jsonp-Parameter, der einen Punkt im Wert trägt.
• Plugins und Themes aktuell halten: Klingt banal, ist aber weiterhin die häufigste Einfallschneise überhaupt, unabhängig von dieser konkreten Lücke.

XSS2Shell ist ein gutes Beispiel dafür, dass Sicherheitslücken heute selten aus einem einzelnen, offensichtlichen Fehler bestehen. Es ist eher wie bei einem Einbruch, bei dem der Täter nacheinander eine wacklige Fensterklinke, einen unverschlossenen Kellerschacht und eine offene Verbindungstür ausnutzt, die für sich genommen alle drei niemand als dringendes Problem eingestuft hätte. Genau deshalb lohnt es sich, Updates nicht als lästige Pflichtübung zu behandeln, sondern als das, was sie sind: der einfachste Hebel, den man als Betreiber überhaupt hat, um aus einer Kette mit fünf Gliedern eine Kette mit vier Gliedern zu machen, die dann eben nirgendwo mehr hinführt.

Und wer selbst nicht die Zeit oder Lust hat, jede Woche Sicherheitsmeldungen zu wälzen und Logs zu durchforsten: Genau dafür gibt es uns.

Foto: ©2012 dgrosso CC BY 2.0

12.08.2026