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. Under additional conditions, the bug can be chained into PHP code execution on the server.

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 can execute without an account or additional victim interaction once the crafted request is delivered.

The code-execution path is harder: its demonstrated chain requires a victim already logged in as a single-site Administrator, one ordinary click on an attacker-controlled page, and several WordPress features and deployment conditions to line up.

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. WordPress powers 41.2% of all websites, according to W3Techs.

pwn.ai, which calls 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.

In pwn.ai's demonstration, the WordPress-origin XSS invokes 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 the chain 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 all-version scope therefore applies to the underlying XSS, not automatically to this specific PHP-execution path. The demonstrated escalation requires Application Passwords, which were introduced in WordPress 5.6 and are normally used over HTTPS. It also requires the Administrator's usual unfiltered_html and upload_plugins capabilities and writable plugin storage.

The deployment must also lack hardening that blocks file modifications or direct PHP execution from inactive plugin directories. Disabling Application Passwords would break this particular escalation path, but would not fix the underlying XSS.

The researchers said 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.