New WordPress Pre-Auth XSS Could Lead to PHP Code Execution

WordPress has fixed a pre-authentication reflected cross-site scripting (XSS) flaw in its login screen that affects every version of the content management system. pwn.ai demonstrated how the flaw can be chained into PHP code execution on the server when a logged-in administrator interacts with an attacker-controlled page.

Tracked as CVE-2026-64638 (CVSS score: 8.9), the high-severity vulnerability requires no attacker privileges. According to pwn.ai, which discovered the flaw and shared technical details with The Hacker News, the login-page XSS requires no authentication. Once a crafted username reaches the failed-login error page, the resulting JavaScript executes in the visitor's browser with no further interaction required on that page.

The code-execution path requires a victim already logged in as an Administrator and explicit interaction with an attacker-controlled page. In pwn.ai's demonstration, that interaction is one ordinary click.

The researchers told The Hacker News that the attack works against default WordPress installations and does not require unusual hosting or deployment settings. The researchers said they have multiple paths from the XSS to code execution, including variants that install a plugin or upload an arbitrary ZIP.

WordPress's own advisory takes a more cautious view of exploitability, noting that escalation to RCE involves conditions outside the attacker's control and requires successful social engineering plus explicit victim interaction.

The issue was patched on August 6 in WordPress 7.0.3, with fixes backported through the 4.7 branch. WordPress recommends updating immediately, and sites that support automatic background updates should receive the security release automatically. Versions older than 4.7 remain affected but fall outside the project's current backport range.

The researchers, who call the attack chain XSS2Shell, said its autonomous system discovered and reproduced the vulnerability chain after being given Paulos Yibelo's 2022 Same Origin Method Execution (SOME) research as a starting point.

The company said the work took nearly four days using open-source models and a multi-agent workflow. It said the chain was reproduced on July 26 and reported to WordPress the following day.

The flaw starts in the way WordPress handles the username from a failed login. According to the researchers, the value passes through sanitize_user() and wp_strip_all_tags(), which relies on PHP's strip_tags(). A tag-like string containing whitespace after the opening < can survive that parser as text. Later, WordPress passes the value through wp_kses_post(), whose separate parser interprets the same input as permitted HTML. The result is attacker-controlled live DOM elements on the failed-login page.

Those elements then interact with WordPress's own user-profile.js, a profile-management script that is also loaded on the login page because the page handles password resets.

Some profile elements the script expects are absent there: two missing inputs both resolve to undefined, allowing an equality check to pass, while the otherwise undefined ajaxurl variable can be clobbered with an injected DOM element. That steers WordPress's own JavaScript toward an attacker-selected same-origin REST request.

The researchers use WordPress's REST JSONP support to turn that request into JavaScript executing in the site's origin. For deployments where anonymous REST requests return HTTP 401, the _envelope=1 parameter can wrap the denial in an outer HTTP 200 response, allowing jQuery to continue processing the response as script.

The researchers also found in their testing that a nonce-based Content Security Policy using strict-dynamic did not block the demonstrated path.

The path from XSS to PHP execution builds on Yibelo's earlier SOME technique, which uses a permitted JSONP property chain to invoke a method in another browser window.

One path demonstrated by pwn.ai uses the WordPress-origin XSS to invoke the native Application Password approval control inside a logged-in Administrator's session. WordPress then creates an API credential and redirects it to an attacker-selected HTTPS success_url.

Application Passwords are revocable credentials intended for API access, so this path does not need to steal the administrator's primary password. The researchers used the credential for authenticated REST access to publish a WordPress page containing same-origin JavaScript. When the retained administrator session opened that page, its script obtained WordPress's plugin-upload nonce and uploaded an attacker-supplied ZIP. PHP could then be requested directly from the extracted plugin. The plugin did not need to be activated.

The production evidence supplied to The Hacker News stops at the XSS. The researchers separately reproduced the cookie-less login-page XSS against two WordPress 7.0.2 deployments in fresh Chrome profiles with no WordPress cookies or credentials.

They did not attempt Application Password creation, file upload, persistence, or PHP execution on those systems. The complete PHP-execution chain was demonstrated separately on a clean local WordPress 7.0.2 installation.

The researchers said known WordPress hardening measures should not be treated as a complete mitigation for the underlying XSS and that applying the security update is required.

A successful PHP execution would expose WordPress database credentials in wp-config.php, allow persistent administrator creation and content changes, expose files and secrets readable by the PHP worker, and permit operating-system commands with that worker's privileges.

WordPress credited the team at pwn.ai with discovering and responsibly disclosing the vulnerability. As of August 7, the project's advisory does not report in-the-wild exploitation.

Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.