Severity: High (CVSS 8.9)

Status: Patched — update immediately

1. Summary
2. Impacted versions
3. Recommendations
4. References
5. Support

WordPress has remediated a reflected cross-site scripting vulnerability in the login interface (wp-login.php) affecting all releases. Exploitation requires neither authentication nor an existing session: an attacker who induces a target to request a crafted URL obtains JavaScript execution in that user’s browser under the site’s own origin. This permits credential harvesting presented on a legitimate institutional hostname, session token theft, and arbitrary same-origin requests issued in the target’s security context.

Under additional preconditions, the discovering researchers demonstrated escalation to PHP code execution. An authenticated Administrator who follows an attacker-supplied link causes an Application Password to be created in their own session; that credential is then used over the REST API to upload a plugin archive, and the extracted PHP is requested directly. The plugin is never activated. Successful execution exposes the database credentials in wp-config.php and yields command execution in the security context of the PHP worker process.

A nonce-based Content Security Policy employing strict-dynamic was tested against the demonstrated path and did not prevent exploitation, as the technique clobbers DOM properties consumed by already-trusted scripts rather than introducing new script sources; CSP is not a compensating control. Remediation priority should be assigned to internet-facing installations outside central patch management: departmental, laboratory, research group, and course sites, and installations where Administrator privilege is held by individuals who use the same browser profile for electronic mail.

The vulnerability arises from a parser disagreement between two sanitization routines. A username submitted to a failed login is processed by wp_strip_all_tags(), which delegates to PHP’s strip_tags(); a tag-like construct containing whitespace immediately after the opening angle bracket is not recognized as markup and survives as text. The same value is subsequently processed by wp_kses_post(), whose independent parser interprets that construct as permitted HTML, yielding attacker-controlled elements in the rendered document. Those elements are consumed by user-profile.js, which loads on the login interface because that page handles password reset. Two input elements the script expects are absent and both resolve to undefined, satisfying an equality comparison, while the otherwise undefined ajaxurl variable is clobbered by an injected element. Control flow is thereby directed to an attacker-selected same-origin REST request, which the REST JSONP support causes to be evaluated as script.

Escalation beyond the cross-site scripting requires all of the following to hold concurrently: Application Passwords enabled (the default since 5.6); a target holding single-site Administrator with the default unfiltered_html and upload_plugins capabilities; writable plugin storage; and no hardening preventing file modification or direct PHP execution from inactive plugin directories. Managed and hardened hosting environments frequently fail at least one of these; self-administered installations on departmental infrastructure typically satisfy all four. The full chain was demonstrated on an isolated local installation rather than against production infrastructure and should be characterized as proven under controlled conditions.

The same release remediates eleven further vulnerabilities, including stored cross-site scripting reachable at Contributor privilege and a privilege escalation affecting multisite networks. These are material on installations that accept external contributors or retain dormant author accounts.

• Impacted versions:
  • WordPress 4.7 – 7.0.2 (every release on every branch)
  • WordPress 4.6 and earlier — end of life, no patch available
• Fixed versions:
  • WordPress 7.0.3
  • WordPress 6.9.6
  • WordPress 6.8.7
  • Equivalent minor releases on every remaining supported branch back to 4.7

Installations with automatic background updates enabled should already have received the release. The running version should be verified rather than assumed. Installations on 4.6 or earlier require migration to a supported branch or decommissioning.

• Update WordPress core. Verify the running version directly rather than relying on the configured update policy. Managed hosting environments may already have applied the release; self-administered installations will require manual action.
• Disable Application Passwords where operationally unnecessary. This removes the demonstrated escalation path at no functional cost on installations without API integrations. It does not remediate the underlying cross-site scripting vulnerability.
• Define DISALLOW_FILE_MODS in wp-config.php. On installations where the plugin lifecycle is managed by deployment rather than through the administrative interface, this prevents the upload stage of the chain and constitutes sound configuration independent of this vulnerability.
• Do not treat Content Security Policy or web application firewall coverage as mitigation. A nonce-based policy with strict-dynamic was tested and did not block the demonstrated path. Reflected payloads delivered in query parameters are additionally resistant to signature-based inspection.
• Reduce the Administrator population. Accounts limited to content publication should hold the Editor role.

• WordPress 7.0.3 release announcement
• pwn.ai technical write-up (XSS2Shell)
• Application Passwords documentation
• NVD entry: CVE-2026-64638 detail

As always, please let us know if you have any questions or concerns or see unusual activity on your systems that you believe might be associated with this or any other vulnerability. Please send these communications to security.response@utoronto.ca.