WordPress heeft een ernstige kwetsbaarheid verholpen die start als WordPress pre-auth XSS op het login-scherm. De bug is verwerkt in WordPress 7.0.3 (met backports via de 4.7-branch). Omdat het om een pre-auth probleem gaat, hoeft een aanvaller niet in te loggen om de XSS te triggeren—het risico zit vooral in de mogelijke keten naar PHP-code-uitvoering op de server.
In dit artikel leggen we uit wat er precies misgaat, onder welke voorwaarden de aanval verder kan escaleren en wat je vandaag nog kunt doen om je WordPress-site te beschermen.
Wat is de WordPress pre-auth XSS (CVE-2026-64638)?
De kwetsbaarheid is geregistreerd als CVE-2026-64638 met een CVSS-score van 8.9. Het gaat om gereflecteerde cross-site scripting (XSS) op de loginpagina. Belangrijk: de aanval kan plaatsvinden zonder dat de aanvaller al rechten heeft op het systeem.
Concreet gaat het om de manier waarop WordPress de username verwerkt bij een mislukte loginpoging. Zodra een speciaal gemaakte invoer op een foutpagina terechtkomt, ontstaat in de browser van de bezoeker kwaadaardige JavaScript-uitvoering. Daarbij is geen extra interactie nodig op die foutpagina zelf: de payload draait zodra het script op de pagina wordt uitgevoerd.
Van XSS naar PHP: waarom de aanval een keten is
Een XSS betekent niet automatisch dat er direct servercode draait. In deze casus is de impact groter, maar de volledige escalatie naar PHP vereist extra voorwaarden. De onderzoekers beschrijven het als een keten die begint bij de XSS en verdergaat richting serverkant.
Volgens de technische analyse werkt de escalatie alleen wanneer de slachtoffer al is ingelogd als beheerder (administrator) en daarna een pagina bezoekt die door de aanvaller wordt gestuurd. In de demonstratie volstond één normale klik op een door de aanvaller gecontroleerde pagina.
Opvallend is dat de onderzoekers meerdere paden hebben gevonden die kunnen leiden tot code-uitvoering. Zo worden varianten beschreven die onder meer neerkomen op het installeren van een plugin of het uploaden van een ZIP-bestand—zonder dat alle stappen automatisch persistente toegang hoeven te garanderen.
Waarom default WordPress al kwetsbaar kan zijn
De onderzoekers geven aan dat de aanval werkt tegen standaard WordPress-installaties. Er is geen ongebruikelijke hosting of speciale deployment-setup nodig om de XSS-aanval te triggeren. Dat maakt het extra relevant: veel organisaties draaien immers “out of the box” WordPress.
WordPress zelf beschrijft echter ook een nuance. In het officiële advies wordt de exploitbaarheid met meer voorbehoud bekeken, omdat de stap van XSS naar RCE/PHP-exécution afhankelijk kan zijn van omstandigheden buiten controle van de aanvaller. In hun visie vraagt de keten om social engineering en expliciete interactie van het slachtoffer.
Wat gaat er precies mis in de verwerking van de username?
De keten start bij de foutafhandeling van een mislukte login. De focus ligt op de manier waarop WordPress de username verwerkt via meerdere stappen in PHP.
- De waarde gaat via functies die bedoeld zijn om input te saniteren (o.a. een pad met sanitize_user() en wp_strip_all_tags()).
- Volgens de onderzoekers kan een tag-achtige string met een specifieke spatiëring na het openen van “<” als tekst door het parser-proces glippen.
- Daarna wordt dezelfde input opnieuw verwerkt via wp_kses_post(), waardoor de interpretatie kan veranderen: wat eerder als tekst werd gezien, kan nu als toegestaan HTML of als DOM-structuur terugkomen.
Het resultaat: live DOM-elementen die de aanvaller beïnvloedt op de failed-login pagina. Dit vormt het startpunt voor de verdere interactie met WordPress-scripts die ook op loginpagina’s worden geladen.
Welke rol speelt user-profile.js op de loginpagina?
De onderzoekers wijzen erop dat WordPress op het login-scherm scripts laadt die normaliter horen bij profielbeheer. Omdat de loginpagina ook betrokken is bij wachtwoord-reset functionaliteit, komt user-profile.js op dezelfde pagina terecht.
In die context verwacht de JavaScript logica enkele profielvelden. Die zijn op de loginpagina niet beschikbaar. Daardoor kunnen bepaalde variabelen of inputs undefined worden, waardoor een gelijkheidscheck kan worden omzeild. Tegelijkertijd kan een variabele die normaliter verwijst naar de AJAX/REST-infrastructuur (ajaxurl) worden overschreven door geïnjecteerde DOM-elementen.
Zo stuurt de aanvaller de WordPress-side JavaScript richting een REST-request die overeenkomt met de aanvallerkeuze.
REST en JSONP: hoe de browser uiteindelijk JavaScript uitvoert
Voor het daadwerkelijk uitvoeren van code binnen dezelfde origin wordt gebruikgemaakt van het mechanisme rond REST JSONP. In het scenario dat de onderzoekers beschrijven kan een REST-aanroep die anders met HTTP 401 faalt, via een extra parameter (_envelope=1) worden “ingepakt” zodat jQuery de response als script blijft behandelen.
Daarnaast melden de onderzoekers dat een Content Security Policy op basis van nonce’s met een strict-dynamic configuratie in hun test de gedemonstreerde route niet heeft geblokkeerd. Dat betekent: je kunt je niet blindstaren op “CSP hebben we al”, omdat de kwetsbaarheid eerder in de keten kan plaatsvinden.
Hoe escalatie richting code execution in de praktijk kan verlopen
Een belangrijk onderdeel van de aanvalsketen draait om Application Passwords. In de demonstratie wordt de XSS gebruikt om in de browsersessie van een ingelogde administrator een controle voor het goedkeuren van Application Passwords aan te roepen.
Daarbij maakt WordPress vervolgens API-credentials aan en stuurt de browser door naar een aanvallergekozen success_url. Application Passwords zijn bedoeld als intrekbare credentials voor API-toegang, dus het doelwit hoeft niet het primaire adminwachtwoord te zijn.
Met die (intrekbare) credential voert de aanvaller vervolgacties uit via geauthenticeerde REST-toegang. In de beschrijving levert dit op een later moment het uploaden van een ZIP met plugin-inhoud op, waarbij de onderzoekers aangeven dat de plugin niet per se geactiveerd hoeft te worden voor de verdere stap richting PHP.
Tot slot wordt PHP-gevraagde code-uitvoering beschreven als een vervolg die kan leiden tot ernstige gevolgen, zoals het blootleggen van databasegegevens (o.a. via wp-config.php), het creëren van extra beheerders, het aanpassen van content en het uitvoeren van OS-commando’s met de rechten van de PHP-worker.
Patch: update direct naar WordPress 7.0.3
WordPress heeft de fix doorgevoerd op 6 augustus. De update staat in WordPress 7.0.3, met backports via de 4.7-branch. WordPress raadt aan om onmiddellijk bij te werken.
Als jouw WordPress-installatie ondersteuning biedt voor automatische achtergrondupdates, zou de beveiligingsrelease automatisch binnen moeten komen. Let wel: versies die ouder dan 4.7 zijn, blijven volgens het project buiten de backport-range en moeten daarom sowieso worden gemigreerd naar een ondersteunde versie.
WordPress hardening is geen vervanging voor de patch
De onderzoekers benadrukken dat bekende hardeningmaatregelen niet automatisch genoeg zijn om de onderliggende XSS volledig te neutraliseren. Met andere woorden: extra beveiligingslagen kunnen helpen, maar de update is verplicht om het kernprobleem op te lossen.
Als je beleid gericht is op governance en compliance rondom cyberrisk, kijk dan ook naar hoe je “patchen” vertaalt naar aantoonbare processen en risicobeheersing. Op onze site vind je hierover een achtergrondstuk: Governance vs compliance in cyberrisk: toekomstbestendig.
Praktische checklist voor beheerders
Wil je snel handelen? Gebruik deze korte checklist:
- Update WordPress naar 7.0.3 of hoger.
- Controleer of je site draait op een branch die nog security updates ontvangt. Voor versies ouder dan 4.7 geldt: plan een upgrade.
- Neem alertheid mee voor phishing/social engineering: de keten vraagt om expliciete interactie door een ingelogde administrator.
- Verifieer dat je beveiligingsinstellingen (CSP e.d.) getest zijn op jouw situatie, maar zie dit nooit als vervanging voor de patch.
- Laat je logging en monitoring meedraaien: houd failed logins en afwijkende admin-activiteiten bij.
Waarom dit nieuws ook relevant is voor bredere websecurity
Deze kwetsbaarheid laat zien hoe een “gewone” XSS kan uitgroeien tot server-impact wanneer er in de keten een brug wordt gevonden naar interne scripts, REST-gedrag en uiteindelijk PHP. Dat patroon past in een bredere les in websecurity: zolang onveilige inputverwerking samenkomt met kwetsbare componenten, kan de aanval zich doorontwikkelen.
Vergelijkbare ketenaanvallen en web-exploitroutes komen ook terug in andere recente kwetsbaarheidsverhalen. Als je wilt zien hoe onderzoekers soms verrassend ver gaan met exploit chains, lees dan ook: HTTP desync: AI vond Apache zero-day en nieuwe technieken.
Conclusie
WordPress heeft een ernstige WordPress pre-auth XSS gepatcht onder CVE-2026-64638. Hoewel de eerste stap al zonder authenticatie kan worden getriggerd, draait de grootste dreiging om de keten naar PHP-code-uitvoering—met als extra vereisten dat een administrator ingelogd is en expliciet een door de aanvaller gecontroleerde pagina bezoekt.
Daarom is de boodschap helder: voer de update naar WordPress 7.0.3 (of een ondersteunde backport) vandaag nog uit en vertrouw hardening niet als enige maatregel. Zo voorkom je dat je site onderdeel wordt van een aanval die van login-scherm tot server-impact kan oplopen.
Bron: https://thehackernews.com/2026/08/new-wordpress-pre-auth-xss-could-lead.html
