WordPress has patched a high-severity security flaw in its login screen that affects every version of the content management system and could enable attackers to execute PHP code on servers, according to a disclosure published by pwn.ai. The vulnerability, tracked as CVE-2026-64638 with a CVSS score of 8.9, is a pre-authentication reflected cross-site scripting (XSS) weakness that requires no attacker privileges. Researchers at pwn.ai showed how the flaw can be linked into a complete attack chain that delivers PHP code execution when a logged-in administrator interacts with a page controlled by the attacker.
The login-page XSS requires no authentication, pwn.ai told The Hacker News. Once a specially crafted username reaches the failed-login error page, the resulting JavaScript runs in the visitor's browser with no additional interaction needed 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 attack works against default WordPress installations and doesn't 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 file. WordPress's own advisory takes a more cautious view of exploitability, noting that escalation to remote code execution 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 their 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 work took nearly four days using open-source models and a multi-agent workflow, the company said. The chain was reproduced on July 26 and reported to WordPress the following day. WordPress credited the team at pwn.ai with discovering and responsibly disclosing the vulnerability. As of August 7, the project's advisory doesn't report in-the-wild exploitation.
The flaw starts in the way WordPress handles the username from a failed login, the researchers explained. The value passes through sanitize_user() and wp_strip_all_tags(), which relies on PHP's strip_tags() function. A tag-like string containing whitespace after the opening < character 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, resulting in 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's 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 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. 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 without needing to activate it. 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. Known WordPress hardening measures shouldn't be treated as a complete mitigation for the underlying XSS and applying the security update is required, the researchers said. The threat surfaces a category of parser-mismatch vulnerabilities that can bypass multi-layer sanitization when different validation steps interpret the same input differently, turning what appears to be safe text into executable code down the chain.

