CVE-2026-64638 is a high-severity (CVSS 8.9) reflected cross-site scripting (XSS) bug in WordPress’s login screen that requires no attacker privileges — and, under a narrow set of additional conditions, can be chained into server-side PHP execution.
Scope: versions, patching, and exposure
WordPress patched the flaw on August 6 in WordPress 7.0.3 and backported fixes through the 4.7 branch. Versions older than 4.7 remain affected but fall outside the project's current backport range. WordPress recommends updating immediately; sites that support automatic background updates should receive the security release automatically. According to W3Techs, WordPress powers 41.2% of all websites, a figure that underlines the scale of potential exposure.
How the login-page XSS works: sanitize_user(), wp_strip_all_tags(), wp_kses_post()
The vulnerability begins with how WordPress handles the username field after a failed login. The input is passed through sanitize_user() and wp_strip_all_tags(), which in turn relies on PHP’s strip_tags(). A tag-like string that includes whitespace after the opening “<” can survive that parser as text. Later, the same value is passed through wp_kses_post(), whose separate parser interprets the same input as permitted HTML. That mismatch can leave attacker-controlled live DOM elements on the failed-login page.
Those injected elements then interact with WordPress’s own user-profile.js, a profile-management script that is also loaded on the login page because it handles password resets. Two expected profile inputs are absent on the login page; both resolve to undefined and thereby allow an equality check to pass. The normally defined ajaxurl variable can be clobbered by an injected DOM element, steering WordPress’s JavaScript toward an attacker-selected same-origin REST request.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleFrom XSS to PHP execution: the XSS2Shell chain demonstrated by pwn.ai
The research team at pwn.ai — which named the chain XSS2Shell — used Paulos Yibelo’s 2022 Same Origin Method Execution (SOME) research as a starting point. Their autonomous system discovered and reproduced the chain after nearly four days of work using open-source models and a multi-agent workflow. They reproduced the cookie-less login-page XSS on two WordPress 7.0.2 deployments in fresh Chrome profiles with no WordPress cookies or credentials; the production evidence supplied to The Hacker News stops at that XSS.
The path to code execution that pwn.ai demonstrated builds on SOME and uses WordPress’s REST JSONP support. The researchers showed how the XSS can steer a same-origin JSONP response into executing JavaScript in the site’s origin. For deployments where anonymous REST requests return HTTP 401, the _envelope=1 parameter can wrap that denial in an outer HTTP 200 response, allowing jQuery to continue processing the response as script. In their testing, a nonce-based Content Security Policy using strict-dynamic did not block the demonstrated path.
In the full local demonstration on a clean WordPress 7.0.2 install, the login-page XSS invoked the Application Password approval control inside a logged-in single-site Administrator’s session. WordPress then created an API credential and redirected it to an attacker-selected HTTPS success_url. The researchers used that credential to publish a WordPress page containing same-origin JavaScript; when the retained Administrator session opened the page, the page’s script acquired the plugin-upload nonce and uploaded an attacker-supplied ZIP. PHP could then be requested directly from the extracted plugin, and the plugin did not need to be activated for execution.
Patch status, immediate remediation, and limits of the escalation
WordPress credited pwn.ai with responsibly disclosing the vulnerability. As of August 7, the project's advisory does not report in-the-wild exploitation. The underlying reflected XSS applies to all WordPress versions, while the full PHP-execution escalation demonstrated by pwn.ai depends on additional factors: Application Passwords (introduced in WordPress 5.6), the Administrator account’s unfiltered_html and upload_plugins capabilities, writable plugin storage, and a deployment that does not harden against file modifications or direct PHP execution from inactive plugin directories. Disabling Application Passwords would break that particular escalation path but would not remove the underlying pre-auth XSS.
What this means for site operators, single-site Administrators, and end users
- Site operators: Apply the WordPress 7.0.3 update or the backports provided through the 4.7 branch immediately. Relying on automatic background updates will deliver the security release where enabled.
- Single-site Administrators: Be aware that the most dangerous escalation demonstrated requires an Administrator session and several permissive deployment conditions (application-passwords enabled, upload and unfiltered_html capabilities, writable plugin directories); review and tighten those settings where possible.
- End users: The immediate threat is the pre-auth reflected XSS on the login page, which requires no account to trigger; administrators should ensure their installations are patched to prevent even this initial vector.
WordPress sites should be updated without delay. The all-version scope of the login-page XSS makes the bug broadly relevant; the even more serious server-side PHP execution requires a confluence of features and permissive configuration but was demonstrated end-to-end by the researchers on a local 7.0.2 instance. As of August 7, there is no public evidence of active exploitation, but the combination of a pre-auth XSS and usable escalation techniques places a premium on rapid patching and configuration hardening.
Original reporting: https://thehackernews.com/2026/08/new-wordpress-pre-auth-xss-could-lead.html
