On August 7, 2026, CVE-2026-64638 (XSS2Shell), a High-severity (CVSS 8.9) pre-authentication cross-site scripting exposure in WordPress Core, was disclosed. Update to WordPress 7.0.3 immediately: sites that support automatic background updates should receive the security release automatically, and the fix is backported through the 4.7 branch, so supported older versions have a patched build as well. Any instance you cannot patch straight away should block the exploit's delivery signature at the edge and cut the escalation surface (both covered under Mitigation), and anything running a version older than 4.7 should be moved onto a supported branch.

The flaw, discovered and named XSS2Shell by pwn.ai, lets an unauthenticated attacker inject attacker-chosen DOM into the login screen with a single failed login and drive WordPress's own JavaScript into script execution in the site's origin. Aimed at a logged-in single-site administrator, it chains through a Same Origin Method Execution technique to Application Password theft, plugin upload, and PHP execution on the server. WordPress shipped the patch in 7.0.3 the day before, on August 6, alongside advisory GHSA-52p2-r8wf-jcrf. WordPress powers more than 40% of all websites, so even a scoped exposure reaches an enormous install base. The reflected login-screen XSS affects WordPress 6.4 through 7.0.2 and needs no account, while the full path to PHP execution is narrower still and depends on several deployment conditions lining up. As of publication there is no report of in-the-wild exploitation.

Technical overview

• Vulnerability: Pre-auth reflected XSS on the login screen via a strip_tags / KSES parser differential, chaining to remote code execution
• CVE: CVE-2026-64638
• GHSA: GHSA-52p2-r8wf-jcrf
• Severity: High (CVSS 8.9)
• Impact: Unauthenticated JavaScript execution in the WordPress origin; against a logged-in single-site administrator, PHP execution as the web-server user
• Affected versions: WordPress 6.4 through 7.0.2. The path depends on the wp_kses_post() login-error rendering that arrived with wp_admin_notice() in 6.4; on 6.3 and earlier the surviving string is never re-parsed, so it stays inert. WordPress backported the fix to supported branches (through 4.7) as a precaution, not because pre-6.4 is exploitable through this path.
• Fixed versions: 7.0.3, plus backports to supported branches
• Discovery: pwn.ai, reproduced autonomously by a multi-agent system seeded with Paulos Yibelo's 2022 Same Origin Method Execution research
• Fix: Escapes the failed-login username at the interpolation site in wp-includes/user.php with esc_html(), so the value is HTML-encoded before it reaches either sanitizer. Neither tokenizer was changed.‍
• Exploitation: A single failed login delivers the reflected payload; the escalation to PHP additionally requires a logged-in administrator and specific deployment conditions.

Timeline

• July 26, 2026: pwn.ai discovers and reproduces the full pre-auth XSS to PHP-execution chain
• July 27, 2026: Reported to WordPress with browser evidence and PHP-execution proof; WordPress acknowledges the risk
• August 6, 2026: WordPress 7.0.3 released; CVE-2026-64638 / GHSA-52p2-r8wf-jcrf assigned; a bounty paid; backports through 4.7 in progress
• August 7, 2026: Coordinated public disclosure

Vulnerability scope and affected deployments

CVE-2026-64638 affects WordPress Core itself, not a plugin or theme, which is what makes it a mass-market event. The exploitable range is WordPress 6.4 through 7.0.2. The bug needs both sanitizers in sequence, and the login-error path only runs through wp_kses_post() from 6.4 onward, when the error rendering moved to wp_admin_notice(). On 6.3 and earlier the surviving < area string is never re-parsed into an element, and browsers do not treat < followed by a space as a tag start, so the payload stays inert text. The strip_tags() quirk itself is ancient, but the quirk alone is not the vulnerability; it becomes one only once a second parser promotes the survivor to live HTML. WordPress backported the fix to supported branches through 4.7 as a precaution rather than because those branches are exploitable through this path. WordPress runs more than 40% of all websites, so a 6.4-through-7.0.2 window still covers an enormous population, and version-matching alone over-reports it by flagging 6.3 and earlier where the path does not exist.

The two outcomes have different reach, and it is worth separating them when you assess exposure:

• The reflected XSS (unauthenticated JavaScript execution in the WordPress origin) applies across 6.4 through 7.0.2 and needs no account, no cookies, and no prior knowledge of the target. pwn.ai reproduced the cookie-less login-screen XSS against two WordPress 7.0.2 deployments in fresh browser profiles with no WordPress session.
• The PHP-execution chain was demonstrated on a clean local WordPress 7.0.2 install and requires a logged-in single-site administrator plus additional deployment conditions. The 6.4-through-7.0.2 scope applies to the XSS; the escalation path is narrower still.

Configuration dependency

The feature the exploit relies on is enabled by default. WordPress enqueues its user-profile script on the login page (it is needed for the password-reset flow, which the login page also serves), and that script is what the injected DOM hijacks. There is no configuration switch that removes it from the login action, so any unpatched, network-reachable WordPress login screen is reachable by the reflected payload.

Detection and forensics

Server-side detection

The reflected payload is delivered to wp-login.php as a POST, and the reliable signal is blunt: a log parameter that contains a < at all. Valid usernames never contain a bracket, so any encoded < in that field is anomalous on its own.

• POST /wp-login.php where the log field contains %3C (an encoded <). Do not narrow this to a space plus area, div, or button. KSES matches < followed by any whitespace, so tab, newline, and carriage return (%09, %0a, %0d) work as well, and any KSES-allowlisted tag is usable, not only the three in the sample payload. A tag-specific or space-only rule is trivially evaded; flag the bracket itself.
• Higher-confidence variants of the same request also carry _jsonp=, _method=GET, rest_route=, or _envelope=1.
• Follow-on REST traffic to /?rest_route=/ or /wp-json/... with a _jsonp= callback that contains dots (for example window.opener.approve.click) is a strong indicator of the escalation stage.
• On the RCE path, look for hits to wp-admin/authorize-application.php carrying an off-origin success_url, and for POST /wp-admin/update.php?action=upload-plugin closely followed by a direct GET to a file under wp-content/plugins/<name>/.

Network-level detection

• Login-screen POSTs from external sources carrying a < in the log field, especially in bursts
• Requests that pair a _jsonp= callback with a same-origin REST endpoint shortly after a failed login
• Newly published pages or plugin uploads immediately following administrator activity that originated from an external referrer

A note on coverage: many WordPress deployments do not richly log the login POST body, and the JSONP and clobbering steps happen client-side and never appear in server logs at all. If you cannot inspect request bodies at the edge, add that logging on the login and REST paths before relying on the signatures above.

Recommended actions

Immediate (within 24 hours)

• Inventory every WordPress instance in your estate and record its Core version
• Update to WordPress 7.0.3 (or the latest patched release in your supported branch); confirm automatic background updates actually applied where you rely on them
• For any instance you cannot update this hour, apply the edge blocking under Mitigation and reduce the escalation surface

Short-term (within 48 to 72 hours)

• Move any instance older than 4.7 onto a supported, patched branch
• Add or verify request-body logging on the login and REST paths so the detection signatures above are usable
• Review administrator accounts and existing Application Passwords for entries you cannot account for, and revoke anything unexpected
• Confirm hardening that blocks direct PHP execution from inactive plugin directories is in place where feasible

Mitigation for deployments that cannot upgrade immediately

Edge and WAF blocking

The exploit's delivery signature is blunt and safe to block. Reject POST /wp-login.php where the log parameter contains a URL-encoded < (%3C) in any form, since valid usernames never contain a bracket, and separately flag REST requests whose _jsonp= callback contains a dot. Do not narrow the login rule to a space plus a specific tag name: KSES also accepts tab, newline, and carriage return after the bracket and allows any allowlisted tag, so a tag-specific rule is trivially bypassed. Blocking the bracket outright carries minimal false positives and does not require blanket-blocking the login page or REST API.

Constrain the escalation preconditions

Disabling Application Passwords breaks the demonstrated credential-theft step, and enforcing DISALLOW_FILE_MODS (or hardening that blocks PHP execution from inactive plugin directories) breaks the plugin-upload step. Neither closes the underlying XSS, so treat both as stopgaps that reduce blast radius, not as fixes. The only fix is 7.0.3.

Verification and detection

Organizations using Hadrian's continuous exposure management platform can:

• Automatically discover publicly reachable WordPress instances across their external attack surface
• Confirm the exploitable window (6.4 through 7.0.2) rather than flagging on version strings alone, which over-reports by catching 6.3 and earlier where the path does not exist
• Validate real-world exploitability of the login-screen exposure with agentic pentesting instead of version-matching
• Detect exploitation attempts targeting the login screen and the REST JSONP escalation path