WordPress heeft een pre-authenticatie reflected cross-site scripting (XSS)-kwetsbaarheid in het inlogscherm opgelost die alle versies van het contentmanagementsysteem betreft. Onder aanvullende voorwaarden kan deze kwetsbaarheid worden gecombineerd tot uitvoering van PHP-code op de server. De kwetsbaarheid, geregistreerd als CVE-2026-64638 met een CVSS-score van 8.9, vereist geen enkele privileges van een aanvaller.

Volgens het beveiligingsbedrijf pwn.ai, dat de kwetsbaarheid ontdekte en technische details deelde met The Hacker News, kan de XSS-aanval op de inlogpagina worden uitgevoerd zonder dat een account nodig is of dat het slachtoffer extra interactie vertoont zodra een speciaal vervaardigd verzoek wordt afgeleverd. De keten naar PHP-code-uitvoering is complexer en vereist dat het slachtoffer al is ingelogd als single-site Administrator, een enkele klik op een door de aanvaller gecontroleerde pagina uitvoert en dat meerdere WordPress-functies en implementatievoorwaarden samenkomen.

De kwetsbaarheid is op 6 augustus verholpen in WordPress 7.0.3, met fixes teruggeport naar versies vanaf 4.7. WordPress adviseert direct te updaten. Sites met automatische achtergrondupdates ontvangen de beveiligingsupdate automatisch. Versies ouder dan 4.7 blijven kwetsbaar maar vallen buiten het huidige backport-bereik van het project.

WordPress wordt gebruikt door 41,2% van alle websites, aldus W3Techs. De aanvalsketen, door pwn.ai XSS2Shell genoemd, is gebaseerd op onderzoek van Paulos Yibelo uit 2022 naar Same Origin Method Execution (SOME). De keten werd op 26 juli gereproduceerd en de volgende dag gemeld aan WordPress. De kwetsbaarheid ontstaat doordat WordPress de gebruikersnaam van een mislukte login verwerkt via functies als sanitize_user() en wp_strip_all_tags(), waarbij bepaalde tag-achtige strings met witruimte na het openingssymbool < als tekst blijven bestaan. Later wordt dezelfde waarde door wp_kses_post() als toegestane HTML geïnterpreteerd, wat leidt tot door de aanvaller gecontroleerde live DOM-elementen op de mislukte loginpagina.

Deze elementen interacteren vervolgens met WordPress’ eigen user-profile.js, een script voor profielbeheer dat ook op de inlogpagina wordt geladen vanwege de afhandeling van wachtwoordresets. Omdat bepaalde profielvelden ontbreken op deze pagina, kunnen variabelen worden overschreven en wordt WordPress’ JavaScript gestuurd naar een door de aanvaller gekozen same-origin REST-verzoek. De onderzoekers maken gebruik van WordPress’ REST JSONP-ondersteuning om dit verzoek om te zetten in JavaScript dat binnen de site wordt uitgevoerd. Zelfs een nonce-gebaseerd Content Security Policy met strict-dynamic blokkeert deze keten niet.

De keten van XSS naar PHP-uitvoering bouwt voort op Yibelo’s SOME-techniek, waarbij een JSONP-eigenschap wordt gebruikt om een methode in een ander browservenster aan te roepen. In de demonstratie van pwn.ai activeert de WordPress-origin XSS de native Application Password-goedkeuringscontrole binnen een ingelogde Administrator-sessie. WordPress genereert vervolgens een API-credential en stuurt deze door naar een door de aanvaller gekozen HTTPS success_url. Application Passwords zijn intrekbare credentials bedoeld voor API-toegang, waardoor het niet nodig is het primaire wachtwoord van de beheerder te stelen. Met deze credential kan de aanvaller geauthenticeerde REST-toegang verkrijgen en een WordPress-pagina publiceren met same-origin JavaScript, waarmee de sessie van de beheerder wordt overgenomen.