WordPress Core XSS2Shell — pre-auth login-screen reflected XSS chaining via DOM clobbering and a JSONP callback to Application-Password minting and plugin upload (CVSS 4.0 8.9); fixed 7.0.3 with backports to 4.7.34

CVE-2026-64638 (XSS2Shell) — WordPress Core: a sanitiser disagreement on the login screen chains through DOM clobbering and a JSONP callback into administrator-minted Application Passwords and plugin upload

WordPress shipped 7.0.3 on 2026-08-06 fixing CVE-2026-64638, a pre-authentication reflected cross-site scripting flaw on the login screen that the vendor says carries "potential to lead to PHP code execution" (WordPress.org, 2026-08-06). The advisory lists 24 separate affected-and-patched branch ranges, from 4.7.0–4.7.33 up to 7.0.0–7.0.2, which is the practical scope statement for anyone maintaining an estate of sites on pinned branches (WordPress, 2026-08-07).

The root cause is a disagreement between two sanitisers about the same bytes. A failed-login error message runs the submitted username through wp_strip_all_tags(), which wraps PHP's strip_tags() and only recognises a tag when the angle bracket is immediately followed by a letter; the message later reaches wp_kses_post(), WordPress's own tokenizer, which tolerates whitespace between the bracket and the tag name and renders it as a live element (pwn.ai, 2026-08-06). The login page therefore ends up carrying real, attacker-specified DOM nodes that the first function had already certified as inert text. From there the chain is a sequence of legitimate mechanisms used in order: a clobbered ajaxurl global redirects a script's own request to a same-origin REST route; the REST JSONP callback pattern permits property-chain traversal, so the callback names a method on the opener window and clicks the Application-Password authorization button inside a genuinely logged-in administrator's session; the minted credential then uploads a plugin ZIP, which WordPress extracts into the plugins directory with the nonce and capability checks both passing correctly. The researcher's point is that the extracted PHP is reachable by URL without the plugin ever being activated.

The precondition is worth stating precisely, because it sets the priority: WordPress records that escalation "requires successful social engineering of and explicit interaction by the target victim" — an administrator has to open the attacker's page while logged in. The reflected XSS underneath needs no authentication at all. No party reports exploitation, the flaw was reported on 2026-07-27 and patched on 2026-08-06, and a bounty was paid.

This is not the WP2Shell chain this pipeline tracks as actively exploited against Swiss websites. That chain is CVE-2026-63030 with CVE-2026-60137, found by a different team through a REST batch route confusion into pre-authentication SQL injection; the shared "2Shell" branding is coincidence, not a common root cause. Estates that patched for WP2Shell are not covered for this.

Detection, telemetry class first. The discriminating artifact for delivery sits in web and application access logs: a login POST whose username parameter contains an angle bracket followed by whitespace, since that exact sequence is what defeats one sanitiser while surviving the other, and no legitimate username contains it. Downstream, the escalation signature is an Application Password creation event immediately after an authorization-page view with no prior credential-management activity in the session, followed by a plugin upload from the same session. Where REST audit logging exists, requests carrying a JSONP callback parameter are a low-noise hunt query because ordinary WordPress clients rarely use one. Triage: the injected elements are themselves on the allowlist, so their presence in a rendered admin notice is not anomalous on its own — the discriminator is that they originate from the login error path, an unauthenticated pre-session context, rather than from authenticated content editing.