Nach Angaben von pwn.ai beginnt der Fehler bei der Verarbeitung des Benutzernamens nach einem fehlgeschlagenen Login. Der Wert durchläuft demnach sanitize_user() und wp_strip_all_tags(), das auf PHPs strip_tags() setzt. Eine tagähnliche Zeichenfolge mit Leerraum direkt nach dem öffnenden „<“ kann diesen Parser als Text passieren. Später reicht WordPress den Wert durch wp_kses_post(), dessen separater Parser dieselbe Eingabe als erlaubtes HTML interpretiert. Das Ergebnis sind laut den Forschern vom Angreifer kontrollierte aktive DOM-Elemente auf der Fehlerseite nach einem fehlgeschlagenen Login.
Diese Elemente greifen anschließend mit user-profile.js zusammen, einem WordPress-eigenen Skript zur Profilverwaltung, das auch auf der Login-Seite geladen wird, weil sie Passwortzurücksetzungen verarbeitet. Dort fehlen jedoch einige Profilelemente, die das Skript erwartet: Zwei nicht vorhandene Eingabefelder werden beide zu undefined aufgelöst, wodurch eine Gleichheitsprüfung bestanden wird. Zusätzlich kann die sonst undefinierte Variable ajaxurl mit einem eingeschleusten DOM-Element überschrieben werden. So lässt sich WordPress’ eigenes JavaScript laut pwn.ai zu einer vom Angreifer ausgewählten Same-Origin-REST-Anfrage lenken.
Für den nächsten Schritt nutzen die Forscher die REST-JSONP-Unterstützung von WordPress, um aus dieser Anfrage JavaScript zu machen, das im Ursprung der Website ausgeführt wird. In Umgebungen, in denen anonyme REST-Anfragen mit HTTP 401 beantwortet werden, kann der Parameter _envelope=1 die Ablehnung in eine äußere HTTP-200-Antwort einbetten, sodass jQuery die Antwort weiter als Skript verarbeitet. In ihren Tests beobachteten die Forscher zudem, dass eine nonce-basierte Content Security Policy mit strict-dynamic den gezeigten Pfad nicht blockierte.
Die Kette von XSS bis zur PHP-Ausführung baut nach Angaben von pwn.ai auf Paulos Yibelos früherer SOME-Technik auf. Die Forscher nennen ihre Angriffskette XSS2Shell. Ihr autonomes System habe die Kette entdeckt und reproduziert, nachdem es Yibelos Forschung zur „Same Origin Method Execution“ aus dem Jahr 2022 als Ausgangspunkt erhalten hatte. Das Unternehmen erklärte, die Arbeit habe mit Open-Source-Modellen und einem Multi-Agenten-Workflow fast vier Tage gedauert. Reproduziert worden sei die Kette am 26. Juli, einen Tag später sei sie an WordPress gemeldet worden.
Ein von pwn.ai demonstrierter Weg nutzt die XSS im WordPress-Ursprung, um in der Sitzung eines bereits angemeldeten Administrators die native Freigabesteuerung für Application Passwords aufzurufen. WordPress erstellt daraufhin eine API-Zugangsinformation und leitet sie an eine vom Angreifer gewählte HTTPS-success_url weiter. Da Application Passwords widerrufbare Zugangsdaten für den API-Zugriff sind, muss auf diesem Weg nicht das primäre Administratorpasswort entwendet werden. Mit diesem Zugang veröffentlichten die Forscher per authentifiziertem REST-Zugriff eine WordPress-Seite mit Same-Origin-JavaScript. Öffnete die fortbestehende Administratorsitzung diese Seite, beschaffte das Skript die Nonce für den Plugin-Upload und lud ein vom Angreifer geliefertes ZIP hoch. PHP ließ sich anschließend direkt aus dem entpackten Plugin anfordern; eine Aktivierung des Plugins war nicht nötig.
Die gegenüber The Hacker News vorgelegten Nachweise aus produktiven Umgebungen enden jedoch bei der XSS. Die Forscher reproduzierten die Login-XSS ohne Cookies gegen zwei WordPress-7.0.2-Installationen in frischen Chrome-Profilen ohne WordPress-Cookies oder Zugangsdaten. Die Erzeugung von Application Passwords, Datei-Uploads, Persistenz oder PHP-Ausführung testeten sie dort nicht. Die vollständige Kette bis zur PHP-Ausführung demonstrierten sie separat auf einer sauberen lokalen WordPress-7.0.2-Installation.
WordPress hat die Lücke am 6. August in Version 7.0.3 geschlossen und Korrekturen bis einschließlich des 4.7-Zweigs zurückportiert. Websites mit automatischen Hintergrund-Updates sollten die Sicherheitsversion automatisch erhalten, so das Projekt. WordPress empfiehlt die sofortige Aktualisierung. Das Projekt schreibt die Entdeckung und verantwortungsvolle Offenlegung dem Team von pwn.ai zu. Laut dem Advisory vom 7. August gibt es bislang keine gemeldete Ausnutzung in freier Wildbahn.