WordPress schließt Login-XSS, das Codeausführung ermöglichen könnte

WordPress hat eine Pre-Authentication-Reflected-Cross-Site-Scripting-(XSS-)Schwachstelle im Login-Bildschirm behoben, die jede Version des Content-Management-Systems (CMS) betrifft, so Sicherheitsforscher von pwn.ai, die ihre Ergebnisse an The Hacker News gemeldet haben. Die Lücke, die als CVE-2026-64638 mit einem CVSS-Score von 8.9 geführt wird, erfordert keine Angreiferrechte. Sobald ein präparierter Benutzername die Fehlerseite nach fehlgeschlagenem Login erreicht, läuft der resultierende JavaScript-Code im Browser des Besuchers, ohne dass auf dieser Seite weitere Interaktion erforderlich ist.

Die gravierendere Konsequenz ist, dass dieses XSS zu PHP-Codeausführung auf dem Server verkettet werden kann, wenn ein angemeldeter Administrator mit einer vom Angreifer kontrollierten Seite interagiert. PHP ist die serverseitige Programmiersprache, mit der WordPress Websites erstellt und ausführt, sodass die Ausführung einem Angreifer die Kontrolle über die Website gibt. In der Demonstration von pwn.ai ist diese Interaktion ein gewöhnlicher Klick. Die Forscher sagten, der Angriff funktioniere gegen Standard-WordPress-Installationen und erfordere keine ungewöhnlichen Hosting- oder Deployment-Einstellungen. Sie beschrieben mehrere Wege vom XSS zur Codeausführung, darunter Varianten, die ein Plugin installieren oder ein beliebiges ZIP-Archiv hochladen.

Die eigene Advisory von WordPress bewertet die Ausnutzbarkeit vorsichtiger und merkt an, dass die Eskalation zur Remote-Codeausführung Bedingungen außerhalb der Kontrolle des Angreifers umfasst und erfolgreiches Social Engineering sowie ausdrückliche Interaktion des Opfers erfordert. Das Problem wurde am 6. August in WordPress 7.0.3 behoben, mit Fixes, die bis in den 4.7-Zweig zurückportiert wurden. WordPress empfiehlt, sofort zu aktualisieren, und Websites, die automatische Hintergrund-Updates unterstützen, sollten das Sicherheitsrelease automatisch erhalten. Versionen älter als 4.7 bleiben betroffen, fallen aber außerhalb des aktuellen Backport-Bereichs des Projekts.

pwn.ai, das die Angriffskette XSS2Shell nennt, sagte, sein autonomes System habe die Schwachstellenkette entdeckt und reproduziert, nachdem ihm Paulos Yibelos Forschung zu Same Origin Method Execution (SOME) aus dem Jahr 2022 als Ausgangspunkt gegeben worden sei. Das Unternehmen sagte, die Arbeit habe mit Open-Source-Modellen und einem Multi-Agenten-Workflow fast vier Tage gedauert. Die Kette wurde am 26. Juli reproduziert und am folgenden Tag an WordPress gemeldet.

Die Lücke beginnt in der Art und Weise, wie WordPress den Benutzernamen aus einem fehlgeschlagenen Login verarbeitet. Laut den Forschern durchläuft der Wert sanitize_user() und wp_strip_all_tags(), was auf PHPs strip_tags() beruht. Eine tag-ähnliche Zeichenkette mit Leerzeichen nach dem öffnenden < kann diesen Parser als Text überleben. Später leitet WordPress den Wert durch wp_kses_post(), dessen separater Parser dieselbe Eingabe als erlaubtes HTML interpretiert. Das Ergebnis sind vom Angreifer kontrollierte Live-DOM-Elemente auf der Fehlerseite nach fehlgeschlagenem Login. Diese Elemente interagieren dann mit WordPress' eigener user-profile.js, einem Profilverwaltungsskript, das auch auf der Login-Seite geladen wird, weil die Seite Passwortzurücksetzungen behandelt. Einige Profil-Elemente, die das Skript erwartet, fehlen dort: zwei fehlende Inputs lösen beide zu undefined auf, wodurch eine Gleichheitsprüfung durchgeht, während die ansonsten undefinierte Variable ajaxurl mit einem injizierten DOM-Element überschrieben werden kann. Das lenkt WordPress' eigenes JavaScript in Richtung einer vom Angreifer gewählten Same-Origin-REST-Anfrage. Die Forscher nutzen WordPress' REST-JSONP-Unterstützung, um diese Anfrage in JavaScript zu verwandeln, das im Origin der Website ausgeführt wird. Für Deployments, bei denen anonyme REST-Anfragen HTTP 401 zurückgeben, kann der Parameter _envelope=1 die Ablehnung in eine äußere HTTP-200-Antwort einwickeln, sodass jQuery die Antwort weiter als Skript verarbeiten kann. Die Forscher fanden in ihren Tests außerdem, dass eine Nonce-basierte Content Security Policy mit strict-dynamic den demonstrierten Pfad nicht blockierte.

Der Weg vom XSS zur PHP-Ausführung baut auf Yibelos früherer SOME-Technik auf, die eine erlaubte JSONP-Eigenschaftskette nutzt, um eine Methode in einem anderen Browserfenster aufzurufen. Ein von pwn.ai demonstrierter Pfad nutzt das XSS im WordPress-Origin, um das native Application-Password-Genehmigungssteuerelement innerhalb einer angemeldeten Administrator-Sitzung aufzurufen. WordPress erstellt dann eine API-Anmeldeinformation und leitet sie an eine vom Angreifer gewählte HTTPS-success_url weiter. Application Passwords sind widerrufbare Anmeldeinformationen, die für API-Zugriff gedacht sind, sodass dieser Pfad nicht das primäre Passwort des Administrators stehlen muss. Die Forscher nutzten die Anmeldeinformation für authentifizierten REST-Zugriff, um eine WordPress-Seite mit Same-Origin-JavaScript zu veröffentlichen. Als die beibehaltene Administrator-Sitzung diese Seite öffnete, erhielt ihr Skript den Plugin-Upload-Nonce von WordPress und lud ein vom Angreifer geliefertes ZIP hoch. PHP konnte dann direkt aus dem extrahierten Plugin angefordert werden. Das Plugin musste nicht aktiviert werden.

Die The Hacker News bereitgestellten Produktionsnachweise enden beim XSS. Die Forscher reproduzierten das cookie-lose XSS auf der Login-Seite separat gegen zwei WordPress-7.0.2-Deployments in frischen Chrome-Profilen ohne WordPress-Cookies oder Anmeldeinformationen. Sie versuchten auf diesen Systemen nicht, Application Password zu erstellen, Dateien hochzuladen, Persistenz zu erreichen oder PHP auszuführen. Die vollständige PHP-Ausführungskette wurde separat auf einer sauberen lokalen WordPress-7.0.2-Installation demonstriert.

Eine erfolgreiche PHP-Ausführung würde WordPress-Datenbank-Anmeldeinformationen in wp-config.php offenlegen, das dauerhafte Anlegen von Administratoren und Inhaltsänderungen ermöglichen, Dateien und Geheimnisse offenlegen, die für den PHP-Worker lesbar sind, und Betriebssystembefehle mit den Rechten dieses Workers erlauben. Die Forscher sagten, bekannte WordPress-Härtungsmaßnahmen sollten nicht als vollständige Abschwächung des zugrunde liegenden XSS betrachtet werden und die Anwendung des Sicherheitsupdates sei erforderlich.

WordPress würdigte das Team von pwn.ai für die Entdeckung und verantwortungsvolle Offenlegung der Schwachstelle. Stand 7. August berichtet die Advisory des Projekts nicht über Ausnutzung in freier Wildbahn. Für Website-Betreiber auf Managed-WordPress-Hosting konzentriert sich ein Dienst wie AEU Hosting darauf, die Plattform aktuell und gehärtet zu halten, was genau die Art von Verteidigung ist, die bei Schwachstellen wie dieser zählt.