CVE-2026-64638: WordPress "XSS2Shell" Preauth Bug Enables Full Site Takeover

A newly disclosed vulnerability chain, tracked as CVE-2026-64638 and nicknamed “XSS2Shell,” allowed attackers to hijack any WordPress site’s administrator session and execute arbitrary PHP code on the server without ever having an account.

Researchers at PwnAI say the flaw affected every actively maintained WordPress version, putting an estimated 500 million-plus sites at risk before an emergency patch, WordPress 7.0.3, shipped on August 6, 2026.

The bug’s origin is almost absurdly simple. When a visitor submits a nonexistent username on wp-login.php, WordPress echoes that username back into an error message after running it through wp_strip_all_tags().

WordPress “XSS2Shell” Preauth Bug

That function relies on PHP’s native strip_tags(), which only recognizes a tag if < is immediately followed by a letter a space in between, like < area>, sails through untouched.

The surviving string then passes through wp_kses_post(), WordPress’s own sanitizer, which uses a separate tokenizer that does tolerate the whitespace and happily treats < area> as a legitimate <area> element one that’s on its allowlist alongside <div> and <button>.

Two sanitizers, two different interpretations of the same string, and the browser ends up rendering live, attacker-controlled DOM elements on the login page.

Injected HTML alone isn’t code execution. The chain’s next step exploits a legacy script, user-profile.js, that WordPress loads on the login page purely to support password resets.

Its click handlers were written assuming they’d only ever run on the real profile page, so they search for elements like .reset-pass-submit and #color-picker elements that don’t normally exist on the login screen, but do once the attacker injects them.

This triggers a chain reaction: a fabricated button auto-clicks, a POST request fires to ajaxurl except ajaxurl isn’t defined on the login page, so JavaScript falls back to a DOM-clobbering trick, resolving it to an injected <area> tag whose href becomes the destination URL.

That request lands on WordPress’s REST API with _jsonp and _method=GET parameters, which WordPress obligingly wraps into an executable JavaScript callback achieving script execution in the WordPress origin, pre-authentication.

The real danger emerges when the JSONP callback isn’t alert() but a property chain window.opener.approve.click built on a Same-Origin Method Execution technique researcher Paulos Yibelo first documented on PwnAI’s blog in 2022.

By opening a child window and redirecting the parent to WordPress’s Application Password approval screen, the exploit remotely clicks “Approve” inside a genuine administrator session, silently minting API credentials.

From there, the attack escalates fast: the stolen Application Password authenticates a REST call that publishes a page containing attacker JavaScript (administrators have unfiltered_html by default), that script then uploads a malicious plugin ZIP through the standard upload flow, and PHP files inside execute immediately no activation required.

WordPress backported the fix to every maintained branch back to version 4.7, reported the researchers moved from discovery to disclosure in roughly two weeks, working with WordPress’s security team throughout.

There is no viable workaround short of updating site owners should upgrade to 7.0.3 immediately and audit for unexpected Application Passwords, plugins, or published pages as a precaution.