Loch in WordPress: Das Login-Formular gibt den Server preis
Eine WordPress-Schwachstelle mit dem Spitznamen XSS2Shell verwandelt einen fehlgeschlagenen Login in PHP-Code, der auf dem Server laeuft. Die Luecke wird als CVE-2026-64638 gefuehrt und erreicht 8,9 Punkte auf der CVSS-Skala. Sie beginnt mit einem Benutzernamen im oeffentlichen Anmeldeformular und endet unter den richtigen Bedingungen mit einem Plugin des Angreifers, das in Ihrer Installation entpackt wird. WordPress lieferte den Fix am 6. August 2026 mit Version 7.0.3 aus und portierte ihn bis zum Zweig 4.7 zurueck. Oeffentlicher Exploit-Code tauchte binnen Tagen auf.
Wie die XSS2Shell-Kette funktioniert
Der Einstiegspunkt ist die Fehlermeldung beim Login. Schicken Sie einen nicht existierenden Benutzernamen, und WordPress gibt ihn auf der Seite wieder aus. Diese Spiegelung soll harmlos sein, und zwei getrennte Sanitizer stehen im Weg. Der vom Team von pwn.ai gefundene Bypass nutzt eine Unstimmigkeit zwischen beiden: strip_tags() behandelt ein Tag, dem ein Leerzeichen vorangeht, nicht als Tag, weshalb eine Nutzlast der Form < area id=ajaxurl> unberuehrt durchgeht, waehrend wp_kses_post() dieselbe Zeichenkette spaeter als gueltiges HTML liest und als echtes Element in der Seite rendert.
Was dieses Element tut, ist der raffinierte Teil. Es ist kein Skript. Es ist ein benannter DOM-Knoten, der mit einer JavaScript-Variablen kollidiert, die WordPress auf diesem Bildschirm undefiniert laesst. Die Technik heisst DOM Clobbering. Ein Kern-Adminskript greift auf ajaxurl zu, findet statt nichts das Element des Angreifers und richtet eine Anfrage dorthin, wohin der Angreifer gezeigt hat. Von da an laeuft die Kette durch den eigenen vertrauenswuerdigen Code der Website: Ein REST-Endpunkt mit JSONP-Unterstuetzung fuehrt das JavaScript des Angreifers im Origin der Website selbst aus, ein fensteruebergreifender Methodenaufruf greift in die Sitzung eines angemeldeten Administrators und bestaetigt dort ein Application Password, und dieses Zugangsdatum gewaehrt authentifizierten REST-Zugriff.
Der letzte Schritt braucht ueberhaupt keinen exotischen Fehler. Das gestohlene Application Password traegt Administratorrechte, also laedt der Angreifer schlicht ueber die API ein Plugin hoch: ein ZIP-Archiv mit PHP darin. Auf einer Einzelinstallation hat ein Administrator zudem standardmaessig das Recht auf ungefiltertes HTML, und genau das macht den Zwischenschritt moeglich, eine Seite voller JavaScript zu veroeffentlichen. Ab diesem Punkt liegt der Code nicht mehr im Browser. Er laeuft mit den Rechten des PHP-Workers, direkt neben den Datenbank-Zugangsdaten.
Was ein Angreifer tatsaechlich braucht
Hier trennen sich Schlagzeile und Realitaet. Die Cross-Site-Scripting-Haelfte braucht tatsaechlich weder Konto noch Passwort, und genau deshalb gilt der Fehler als Pre-Auth. Die Haelfte mit der Codeausfuehrung zuendet dagegen nicht von allein. Ein Administrator muss auf der Zielseite angemeldet sein und einen vom Angreifer kontrollierten Link oeffnen. Es erscheint keine Abfrage, es wird keine Bestaetigung verlangt, und das Opfer sieht nichts Ungewoehnliches, aber der Besuch muss stattfinden.
In der Praxis ist das eine niedrige Huerde. Website-Administratoren klicken den ganzen Tag Links in Supporttickets, Kontaktformularen, Kommentarbenachrichtigungen und Dienstleister-Mails an, haeufig in derselben Browsersitzung, in der ihr Dashboard offen ist. Die Formulierung "erfordert Benutzerinteraktion" als Beruhigung zu lesen, ist genau der Weg, auf dem so eine Kette einen Monat lang ungepatcht bleibt.
Welche Versionen betroffen sind
Jede WordPress-Ausgabe von 4.7 bis einschliesslich 7.0.2 ist verwundbar. Dieser Zweig erschien im Dezember 2016, weshalb der betroffene Bereich praktisch jede Installation abdeckt, die noch Aktualisierungen erhaelt. WordPress veroeffentlichte am selben Tag Korrekturen fuer den gesamten unterstuetzten Baum, von 7.0.3 ueber 6.9.6 und 6.8.7 bis hinunter zu 4.7.34. Alles auf 4.6 oder aelter bekommt gar keine Sicherheitsupdates mehr und ist als dauerhaft exponiert zu behandeln.
XSS2Shell war eines von zwoelf Problemen, die in dieser Version geschlossen wurden. Zu den uebrigen zaehlen gespeichertes Cross-Site-Scripting in den Bloecken Post Date und Post Content, in den Emoji-Einstellungen und im Quick Edit, eine Informationspreisgabe, die Kommentare zu passwortgeschuetzten Beitraegen offenlegte, ein Umgehen der E-Mail-Bestaetigung, eine CSS-Injektion ueber den Filter fuer sichere Attribute, eine Rechteausweitung in Multisite-Netzwerken mit offener Registrierung, eine Server-Side Request Forgery in der URL-Pruefung mit Zugriff auf Link-Local-Bereiche und eine Aufzaehlung von Beitrags-Slugs. Auch ohne die grosse Kette ist diese Liste ein Grund, heute zu aktualisieren.
Was jetzt zu tun ist
- Sofort aktualisieren: auf 7.0.3 wechseln oder auf die gepatchte Ausgabe des eigenen Zweigs. Automatische Hintergrundupdates spielen kleinere Sicherheitsreleases standardmaessig ein, aber pruefen Sie die Version, statt sie vorauszusetzen.
- Application Passwords pruefen: jedes Administratorprofil oeffnen und jedes Zugangsdatum widerrufen, das Sie nicht kennen. Genau dieses Artefakt hinterlaesst die Kette, und es ueberlebt ein Zuruecksetzen des Passworts.
- Benutzer, Plugins und Dateien durchsehen: nach Administratorkonten suchen, die Sie nicht angelegt haben, und nach Plugins, die ohne passenden Eintrag in Ihrer eigenen Aenderungshistorie aufgetaucht sind.
- Nicht ueberall ins eigene Dashboard: die Adminsitzung in einem anderen Browserprofil zu halten als E-Mail und Supporttickets nimmt dem Angriff genau die Voraussetzung, auf der er beruht.
- Den Loginbildschirm einschraenken: die Spiegelung sitzt in wp-login.php. Wer den Zugriff darauf begrenzt, per IP-Freigabeliste, HTTP-Authentifizierung oder Firewallregel, verkleinert die Flaeche fuer den naechsten Fehler in derselben Datei.
Warum das nicht nur Seitenbetreiber angeht
Eine kompromittierte WordPress-Installation ist selten das Ziel des Angreifers. Sie ist ein Transportmittel, und dem Verkehr von dort wird gerade deshalb vertraut, weil die Domain echt ist. Dasselbe Muster gab es, als ein Werbeskript auf Tausenden gewoehnlicher Websites Krypto-Wallet-Adressen umschrieb, und dieselbe Idee steckt hinter Angriffen auf Browserebene, die auf einer bereits offenen angemeldeten Sitzung des Opfers mitreiten. Fuer Leser statt Administratoren liegt die praktische Verteidigung auf der Netzwerkebene: DNS-Filter und Blocklisten verhindern, dass die Nutzlast der zweiten Stufe laedt, selbst wenn die ausliefernde Seite eine ist, die Sie seit Jahren besuchen. Das ist ein schlichtes Argument fuer Datenschutzwerkzeuge, die schon bei der Namensaufloesung blocken, und es gehoert dazu, offen zu sagen: Kein solches Werkzeug patcht Ihren eigenen Server. Das tut nur das Update.
