WordPress heeft een pre-authenticatiefout die cross-site scripting (XSS) weerspiegelde in het inlogscherm opgelost en die van invloed is op elke versie van het contentmanagementsysteem. pwn.ai liet zien hoe de fout kan worden gekoppeld aan de uitvoering van PHP-code op de server wanneer een ingelogde beheerder communiceert met een door een aanvaller bestuurde pagina.
Bijgehouden als CVE-2026-64638 (CVSS-score: 8,9), vereist de zeer ernstige kwetsbaarheid geen aanvallerrechten. Volgens pwn.aidie de fout ontdekte en technische details deelde met The Hacker News, vereist de inlogpagina XSS geen authenticatie. Zodra een vervaardigde gebruikersnaam de foutpagina voor mislukt inloggen bereikt, wordt het resulterende JavaScript uitgevoerd in de browser van de bezoeker, zonder dat verdere interactie op die pagina vereist is.
Voor het code-uitvoeringspad is een slachtoffer nodig dat al is ingelogd als beheerder en expliciete interactie met een door de aanvaller beheerde pagina. In de demonstratie van pwn.ai is die interactie één gewone klik.
De onderzoekers vertelden The Hacker News dat de aanval werkt tegen standaard WordPress-installaties en geen ongebruikelijke hosting- of implementatie-instellingen vereist. De onderzoekers zeiden dat ze meerdere paden hebben van de XSS naar de uitvoering van code, inclusief varianten die een plug-in installeren of een willekeurige ZIP uploaden.
Het eigen advies van WordPress hanteert een voorzichtiger kijk op de exploiteerbaarheid en merkt op dat escalatie naar RCE omstandigheden met zich meebrengt die buiten de controle van de aanvaller liggen en succesvolle social engineering vereist plus expliciete slachtofferinteractie.
Het probleem is op 6 augustus gepatcht in WordPress 7.0.3, waarbij de oplossingen zijn teruggezet via de 4.7 branch. WordPress raadt aan om onmiddellijk te updaten, en sites die automatische achtergrondupdates ondersteunen zouden de beveiligingsrelease automatisch moeten ontvangen. Versies ouder dan 4.7 blijven getroffen, maar vallen buiten het huidige backport-bereik van het project.
De onderzoekers noemen de aanvalsketen XSS2Shellzei dat zijn autonome systeem de kwetsbaarheidsketen ontdekte en reproduceerde nadat het was gegeven Paulos Yibelo’s Same Origin Method Execution (SOME)-onderzoek uit 2022 als uitgangspunt.
Het bedrijf zei dat het werk bijna vier dagen duurde met behulp van open-sourcemodellen en een workflow met meerdere agenten. Er stond dat de keten op 26 juli werd gereproduceerd en de volgende dag aan WordPress werd gerapporteerd.
De fout begint in de manier waarop WordPress omgaat met de gebruikersnaam na een mislukte login. Volgens de onderzoekers gaat de waarde via sanitize_user() en wp_strip_all_tags(), die afhankelijk is van PHP’s strip_tags(). Een tag-achtige string met witruimte na de opening < kan die parser als tekst overleven. Later geeft WordPress de waarde door via wp_kses_post(), wiens afzonderlijke parser dezelfde invoer interpreteert als toegestane HTML. Het resultaat zijn door de aanvaller bestuurde live DOM-elementen op de mislukte aanmeldingspagina.
Deze elementen werken vervolgens samen met WordPress’s eigen user-profile.js, een script voor profielbeheer dat ook op de inlogpagina wordt geladen omdat de pagina het opnieuw instellen van wachtwoorden afhandelt.
Sommige profielelementen die het script verwacht, ontbreken daar: twee ontbrekende invoergegevens worden beide omgezet in ongedefinieerd, waardoor een gelijkheidscontrole kan worden doorstaan, terwijl de anders ongedefinieerde ajaxurl-variabele kan worden omvergeworpen met een geïnjecteerd DOM-element. Dat stuurt het eigen JavaScript van WordPress in de richting van een door de aanvaller geselecteerd REST-verzoek van dezelfde oorsprong.
De onderzoekers gebruiken de REST JSONP-ondersteuning van WordPress om dat verzoek om te zetten in JavaScript dat wordt uitgevoerd in de oorsprong van de site. Voor implementaties waarbij anonieme REST-verzoeken HTTP 401 retourneren, kan de parameter _envelope=1 de weigering in een extern HTTP 200-antwoord verpakken, waardoor jQuery het antwoord als script kan blijven verwerken.
De onderzoekers ontdekten tijdens hun tests ook dat een niet-gebaseerd contentbeveiligingsbeleid dat gebruikmaakt van strikt-dynamisch het gedemonstreerde pad niet blokkeerde.
Het pad van XSS naar PHP-uitvoering bouwt voort op Yibelo’s eerdere SOME-techniek, die een toegestane JSONP-eigenschapsketen gebruikt om een methode in een ander browservenster aan te roepen.
Eén pad dat door pwn.ai wordt gedemonstreerd, gebruikt de XSS van WordPress om de eigen goedkeuringscontrole voor het toepassingswachtwoord op te roepen in een ingelogde beheerderssessie. WordPress maakt vervolgens een API-referentie aan en stuurt deze om naar een door de aanvaller geselecteerde HTTPS success_url.
Applicatiewachtwoorden zijn herroepbare referenties die bedoeld zijn voor API-toegang, dus dit pad hoeft het primaire wachtwoord van de beheerder niet te stelen. De onderzoekers gebruikten de inloggegevens voor geverifieerde REST-toegang om een WordPress-pagina te publiceren met JavaScript van dezelfde oorsprong. Toen de bewaarde beheerderssessie die pagina opende, haalde het script de plug-in-upload nonce van WordPress binnen en uploadde een door de aanvaller geleverde ZIP. PHP kan dan rechtstreeks vanuit de geëxtraheerde plug-in worden opgevraagd. De plug-in hoefde niet geactiveerd te worden.
Het aan The Hacker News geleverde productiebewijs stopt bij de XSS. De onderzoekers reproduceerden afzonderlijk de cookieloze inlogpagina XSS voor twee WordPress 7.0.2-implementaties in nieuwe Chrome-profielen zonder WordPress-cookies of inloggegevens.
Ze hebben op deze systemen geen poging gedaan tot het maken van een applicatiewachtwoord, het uploaden van bestanden, het persistent maken ervan of het uitvoeren van PHP. De volledige PHP-uitvoeringsketen werd afzonderlijk gedemonstreerd op een schone lokale WordPress 7.0.2-installatie.
De onderzoekers zeiden dat bekende WordPress-verhardingsmaatregelen niet mogen worden beschouwd als een volledige beperking van de onderliggende XSS en dat het toepassen van de beveiligingsupdate vereist is.
Een succesvolle PHP-uitvoering zou de WordPress-databasereferenties in wp-config.php blootleggen, aanhoudende beheerderscreatie en inhoudswijzigingen mogelijk maken, bestanden en geheimen blootleggen die leesbaar zijn voor de PHP-werker, en besturingssysteemopdrachten toestaan met de rechten van die medewerker.
WordPress heeft het team van pwn.ai gecrediteerd voor het ontdekken en op verantwoorde wijze openbaar maken van de kwetsbaarheid. Vanaf 7 augustus rapporteert het advies van het project geen exploitatie in het wild.
