WordPress shipped an emergency security release on August 6, 2026 for a bug researchers at pwn.ai are calling XSS2Shell — a pre-authentication cross-site scripting flaw on the login screen (CVE-2026-64638, CVSS 8.9) that chains into full server-side PHP code execution. No plugin, no theme, no prior account. A single crafted failed-login attempt is enough to run attacker JavaScript in the WordPress origin; against a session where an administrator is logged in, the same primitive escalates all the way to RCE.

What happened

The root cause is a parsing mismatch between two sanitizers that run in sequence on the login-error path. WordPress builds its “unknown username” error message by passing the submitted username through wp_strip_all_tags() and then rendering it through wp_kses_post(). Inserting a space between an opening angle bracket and a tag name — < area instead of <area — causes PHP’s strip_tags()-family parsing to treat the string as inert text, while the later wp_kses_post() pass interprets the same string as legitimate markup. The gap lets an attacker smuggle a <area id="ajaxurl"> element onto the page.

That element by itself is just DOM clobbering: it shadows the global ajaxurl variable that a WordPress core script reads and auto-executes against on page load, redirecting an AJAX call to attacker-controlled data. From there the published chain adds two more pieces — a REST API JSONP callback abused as a script-injection vector, and a Same Origin Method Execution (SOME) trick that reaches across browser windows/frames. Combined, an attacker who lures a logged-in Administrator to an attacker-controlled page can pivot the login-screen XSS into stealing that admin’s Application Password, then use it against the REST API to activate a plugin or otherwise reach PHP execution on the server.

Because the bug requires both sanitizers to run in sequence, and the login-error path has only gone through wp_kses_post() since 6.4, the practically exploitable range is WordPress 6.4 through 7.0.2. WordPress backported hardening to every branch still receiving security updates, going back to 4.7, out of caution given how central the shared login-rendering code is.

Impact

WordPress core runs a large share of the public web, and this bug needs nothing beyond a reachable wp-login.php — the default on essentially every install, including ones that are otherwise fully locked down with restrictive plugins disabled. The unauthenticated XSS alone is enough to phish credentials or plant further payloads against any visitor who hits a crafted login URL. The full chain to RCE requires social-engineering an already-authenticated Administrator into visiting an attacker page while their session is live — a realistic bar for targeted attacks against high-value WordPress properties (media outlets, e-commerce, membership sites) where admins are known and reachable. A working proof-of-concept chain (XSS2Shell-CVE-2026-64638) is already public on GitHub, and multiple independent write-ups (pwn.ai, Hadrian, SOCRadar) reproduced the full exploit within days of disclosure, so expect opportunistic scanning and weaponized payloads quickly.

Mitigation

  1. Update to WordPress 7.0.3 immediately. This was shipped as a forced/emergency security release; verify the version on every site rather than trusting background auto-updates, especially on managed hosts or installs where core auto-updates were disabled.
  2. 7.0.3 also fixes 11 other issues disclosed in the same release — stored XSS via emoji settings and the Post Content block, a Multisite privilege-escalation bug, information disclosure, CSS injection, an email-verification bypass, and an SSRF. Treat 7.0.3 as a full security baseline, not a single-CVE patch.
  3. Rotate Application Passwords for all Administrator accounts on sites that were running an affected version, since a successful chain prior to patching could have exfiltrated one without leaving obvious log signatures.
  4. Advise admins to avoid browsing untrusted links while logged into wp-admin as a stopgap on any site that can’t patch immediately — the RCE escalation depends on an authenticated admin session being active in the same browser.
  5. Audit for indicators of compromise: unexpected plugin activations, new Application Passwords you didn’t issue, and login-page traffic containing malformed username parameters (< area, encoded angle-bracket variants) in access logs predating the patch.

References: The Hacker News writeup, pwn.ai’s original technical disclosure, Hadrian’s exploit chain breakdown, Patchstack’s rundown of all 12 fixes in 7.0.3, and the WordPress 7.0.3 release notes.