WordPress XSS Vulnerability: Five Checks to Run This Week

If you run a WordPress site, or several, here’s the short version: update to WordPress 7.0.3 today. A newly disclosed WordPress XSS vulnerability, tracked officially as CVE-2026-64638, lets an attacker run code in a visitor’s browser. The attacker doesn’t even need to log in. Under the right conditions, that access can turn into full control of the server.

This explainer skips the exploit-development detail. It focuses on what a business owner or IT manager needs to know: how to close the door, and how to check whether it was already open.

What actually happened

Security researchers at pwn.ai found a way to smuggle working HTML past WordPress’s login-page filters. They added a stray space inside a tag, something PHP’s own sanitiser lets through but WordPress’s filter still renders as valid markup. It’s a cross-site scripting technique applied somewhere few site owners think to check: the login page itself, before anyone has signed in. That let the researchers run JavaScript on the login page without any account at all.

Paired with an administrator clicking one malicious link elsewhere, the same WordPress XSS vulnerability goes further. It can reach Application Passwords, a plugin upload, and code execution on the server.

WordPress fixed the flaw in version 7.0.3, released 6 August. The patch was backported to every branch still supported, back to version 4.7. The vulnerable code had been there since 4.7. That means this WordPress XSS vulnerability touched nearly every actively maintained install before the fix shipped.

The same 7.0.3 release closed ten other issues too. These include several stored XSS bugs in post content and Quick Edit, a privilege escalation route on multisite networks with open registration, and a server-side request forgery weakness in URL validation. None of them needs the same login-page trick to work. That’s still a reason to run the full update, rather than hunting for a narrower patch that covers just this one bug.

Do you need to worry about this WordPress XSS vulnerability?

Yes, if any of the following is true:

• You run WordPress yourself, on a server you or an IT contractor manages directly (not a fully managed host that patches automatically).
• You’re on a WordPress version older than 4.7 that’s no longer supported at all.
• Multiple people, including non-technical staff, have administrator accounts on the site.
• Nobody currently owns “check for WordPress updates” as a routine task.

You’re in reasonable shape if your host applies core updates automatically. Most managed WordPress hosting does this within hours of a security release. Just confirm the version number reads 7.0.3, or the equivalent patched point release for an older supported branch.

Five checks to run this week

1. Check the version. Log into wp-admin and look at the dashboard, or ask whoever manages hosting to confirm. Anything below 7.0.3 needs updating now.
2. Audit Application Passwords. Under Users, each account can have API-style passwords issued to it. Revoke any you don’t recognise; this is the credential the attack chain targets.
3. Trim administrator accounts. Anyone who doesn’t need full admin rights to do their job shouldn’t have them. Fewer admin sessions means fewer people who can be tricked into the click that completes this chain.
4. Check plugin upload permissions. If your workflow lets non-essential staff install plugins, that’s another rung on this particular ladder worth removing.
5. Set a patching owner. If step one took more than a phone call to answer, that’s the real finding here. Someone specific should be accountable for treating patch management as an ongoing job, not a one-off fire drill.

Why this WordPress XSS vulnerability is more urgent than the average patch

Most WordPress core vulnerabilities need a plugin misconfiguration or an already-compromised account to matter. This one starts from zero access and a login page every visitor can already reach. That’s the detail that should move it up the priority list. So even organisations that treat “we’ll patch on the next maintenance window” as good enough for routine updates should treat this WordPress XSS vulnerability differently.

No active exploitation had been reported when the fix shipped. Working proof-of-concept detail is now public, though, and that changes the timeline. The gap between disclosure and exploitation is now measured in days, not months, for a bug this well documented.

Once this update is done, it’s worth going further than one CVE. Our rundown of the WordPress weaknesses attackers check first covers the ones that don’t come with a headline.

If you can’t patch today

Some organisations run WordPress behind a change process. It won’t let anyone push an update the same day it lands, even a security one. So if that’s you, ask whoever manages your web application firewall or CDN whether a rule for CVE-2026-64638 is available. Turn it on while the update goes through approval.

Where your setup allows it without breaking legitimate access, also consider restricting who can reach the login page. An IP allowlist or a basic-auth wall in front of wp-admin narrows the same window.

Neither of those replaces the actual update. They buy time, and only for the pre-auth part of the chain. If an attacker already has an administrator’s cooperation, the second half of the route is still open. Treat any workaround as a bridge to 7.0.3, not a substitute for it.