WordPress login XSS patched after PHP code execution chain

A WordPress login XSS flaw that needs no account, password or privilege to trigger has been fixed in WordPress 7.0.3, after researchers at pwn.ai showed the bug can be chained into PHP code execution on the server. The vulnerability is tracked as CVE-2026-64638 and carries a CVSS score of 8.9, placing it in the high severity range. The patch was released on August 6 and has been backported through the 4.7 branch of the content management system, so the fix reaches sites running releases as old as that branch. Versions older than 4.7 remain affected but fall outside the project's current backport range.

Cross-site scripting, usually shortened to XSS, means getting an attacker's JavaScript to run inside someone else's browser while that person is visiting a website. It is called reflected when the malicious input is sent in a request and then echoed back into the page the victim loads. Here the flaw sits on the WordPress login screen and, according to pwn.ai, which discovered it and shared technical details with The Hacker News, no authentication is required. A crafted username sent to the login page ends up on the failed-login error page, and the resulting JavaScript executes in the visitor's browser. That page needs no further interaction from the victim: visiting it is enough.

Turning that script injection into code running on the server is a much longer road. It requires a victim who is already logged in as an Administrator and who interacts with a page the attacker controls. In pwn.ai's demonstration that interaction was one ordinary click, exactly the kind of step social engineering is designed to produce. The researchers told The Hacker News the attack works against default WordPress installations and does not require unusual hosting or deployment settings, and that they have multiple paths from the XSS to code execution, including variants that install a plugin or upload an arbitrary ZIP archive.

WordPress's own advisory takes a more cautious view of exploitability. It notes that escalation to remote code execution, meaning the ability to run commands on the server, involves conditions outside the attacker's control and requires successful social engineering plus explicit interaction from the victim. The two positions are not contradictory. The script injection itself demands nothing from the target, while the jump to running code depends on a logged-in administrator being tricked into a click.

pwn.ai traces the flaw to the way WordPress handles the username from a failed login attempt. The value passes through sanitize_user() and wp_strip_all_tags(), the second of which relies on PHP's strip_tags() function. A tag-like string containing whitespace after the opening angle bracket can survive that parser and be treated as ordinary text. Later, WordPress passes the same value through wp_kses_post(), a function that filters content against a list of allowed HTML, and this separate parser reads the identical input as permitted HTML. The two parsers disagree about the same characters, and the result is attacker-controlled live DOM elements on the failed-login page. DOM elements are the pieces a browser assembles into a page, so the attacker has effectively placed their own pieces into the page WordPress is displaying.

Those elements then interact with WordPress's own user-profile.js, a profile-management script that is also loaded on the login page because that page handles password resets. Some of the profile elements the script expects are absent there. Two missing inputs both resolve to undefined, which allows an equality check to pass, and the otherwise undefined ajaxurl variable, the address the script uses to talk to the site, can be clobbered with an injected DOM element. The effect is to steer WordPress's own JavaScript toward a same-origin REST request chosen by the attacker, where same-origin means the request appears to come from the site itself. The researchers use WordPress's REST JSONP support to convert that request into JavaScript executing in the site's origin. For deployments where anonymous REST requests return HTTP 401, the unauthorized response code, the _envelope=1 parameter can wrap the denial in an outer HTTP 200 response, which lets jQuery, the JavaScript library involved, keep processing it as a script. The researchers also found in their testing that a nonce-based Content Security Policy using strict-dynamic did not block the path they demonstrated. A Content Security Policy is a list of rules a site sends to the browser saying which scripts may run, and a nonce is a one-time code that marks a script as trusted.

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. Application Passwords are revocable credentials intended for API access, so this route does not need the administrator's primary password to be stolen. WordPress then creates an API credential and redirects it to an HTTPS success_url selected by the attacker. The researchers used that 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 archive. PHP could then be requested directly from the extracted plugin, and the plugin did not need to be activated. This stage builds on Paulos Yibelo's 2022 Same Origin Method Execution research, a technique that uses a permitted JSONP property chain to invoke a method in another browser window.

The researchers call the attack chain XSS2Shell. They say their autonomous system discovered and reproduced the vulnerability chain after being given Yibelo's 2022 SOME research as a starting point, that the work took nearly four days using open-source models and a multi-agent workflow, and that the chain was reproduced on July 26 and reported to WordPress the following day. It matters where each link was proven. 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. WordPress credited the team at pwn.ai with discovering and responsibly disclosing the vulnerability, and as of August 7 the project's advisory does not report in-the-wild exploitation.

What would a successful PHP execution mean in practice? It would expose the WordPress database credentials stored in wp-config.php, allow persistent administrator accounts to be created and content to be changed, expose files and secrets readable by the PHP worker, and permit operating system c