WordPress has patched a flaw in the one page nearly every WordPress site leaves open to the internet: the login screen. Tracked as CVE-2026-64638 and nicknamed XSS2Shell by the team that found it, the bug lets an attacker run JavaScript in a site's own origin with no account, no password and no prior access. One failed login attempt is enough to set it off.
The fix went out on 6 August 2026 in WordPress 7.0.3, one of twelve security issues in that release, and it was backported unusually far: 24 separate releases reaching back to the 4.7 branch. Sites that take automatic background updates should already have it.
Is my site affected?
The GitHub Security Advisory puts the vulnerable range at WordPress 4.7.0 through 7.0.2, which in practice covers almost every site that had not updated by Thursday. pwn.ai, the research outfit credited with the find, put the number at more than 500 million sites, though that figure is derived from WordPress's share of the web rather than from any count of reachable, unpatched installations. No vendor or vulnerability database publishes an affected-install figure, so read it as the finder's estimate.
The authoritative answer is duller and needs nobody else's servers: open your dashboard and read the version number. Anything below 7.0.3, or below the patched release on your branch, needs updating.
How it works
WordPress's own advisory is deliberately spare. It describes a pre-auth reflected XSS on the login screen which, via a specially crafted malicious third-party website, can be escalated to remote code execution under "conditions outside of the attackers control", requiring "successful social engineering of and explicit interaction by the target victim". Everything more detailed than that comes from pwn.ai, and nobody outside pwn.ai has published a mechanism.
By that account the root cause is a disagreement between two of WordPress's own sanitizers. Submit a username that does not exist and WordPress builds an error message with your input inside it. The input first passes through PHP's strip_tags(), which only treats something as a tag when the opening angle bracket is immediately followed by a letter. Leave a space after the bracket and the string survives as inert text. It is then handed to KSES, WordPress's own HTML sanitizer, whose separate parser does tolerate that space and turns the string back into real elements. One sanitizer calls it text, the other calls it markup, and the browser receives live page structure the attacker chose.
The rest of the chain leans on WordPress's own front-end code: a profile script the login page loads anyway because that page also handles password resets, a check inside it comparing two values that are both absent from the login screen and therefore both undefined, and a missing JavaScript variable that the injected element can quietly supply. That yields script execution in the site's origin. Reaching PHP on the server is a separate matter, and pwn.ai's route there needs a logged-in administrator to visit an attacker page and click, after which it mints an Application Password inside that session and ends at an uploaded plugin archive. We are not reproducing the payloads: a working proof of concept for the first half is already public, and the patch is a day old.
How bad is it really
Serious enough to patch today, and not the drive-by catastrophe the bigger numbers imply. The XSS half genuinely requires no account. The server-takeover half does not happen to a site by itself; it needs one specific, already-authenticated administrator to be talked into a click. That is written into the scoring. HackerOne, which assigned the CVE, rates it 8.9 High on CVSS 4.0, with a vector that flags both high attack complexity and required user interaction. Patchstack and WPScan both score it lower at 7.1, and WPScan credits markedly less impact, a real disagreement about whether the code-execution outcome should count at all.
No exploitation in the wild has been reported by anyone, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. WordPress itself goes no further than calling it a potential to lead to PHP code execution, a more careful claim than its finder's.
One thing to keep straight
XSS2Shell is not wp2shell. That is the separate WordPress pair from July, which is under mass exploitation and sits in CISA's KEV catalog. Any figure circulating about millions of blocked WordPress attacks belongs to that older pair, not to this one.
Who found it
WordPress credits "the team at pwn.ai", and the CVE record names the company as finder. pwn.ai says the work was done autonomously by its own AI agents over nearly four days, building on a Same Origin Method Execution technique Paulos Yibelo published on the same blog in 2022. That is worth flagging as a claim rather than a fact: nobody independent corroborates it, pwn.ai sells an autonomous AI security product, and WPScan's database credits a human handle, paulos__, as the original researcher.
What you should do
Update to WordPress 7.0.3 or the patched release on your branch, and confirm it rather than assuming auto-updates fired. Anything below 4.7 sits outside the backport range and will never be patched. Because exploitation needs an administrator to click an outside link, tell the people holding admin accounts that this is live, and review your site's Application Passwords and installed plugins for anything you do not recognise. The official release note is at wordpress.org, and pwn.ai's account of the research is on its own blog.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.