WordPress has released security fixes for a serious issue in its login process. The problem is a pre-authentication reflected XSS flaw that affects the WordPress login screen and was tracked as CVE-2026-64638 with a CVSS score of 8.9. While the entry point does not require attacker privileges or authentication, the full risk involves a chain that can escalate to PHP code execution under certain conditions.
This article explains what the vulnerability is, how the attack chain works at a high level, and—most importantly—what you should do to protect your site. The core message is simple: apply the patch immediately.
What is the WordPress pre-auth XSS vulnerability?
The flaw is a reflected XSS in the login screen. Researchers demonstrated that an attacker can craft a value—specifically reaching the failed-login error page—so that JavaScript executes in the visitor’s browser. Because the issue sits on the login screen, the attack does not require the attacker to be logged in, and it does not rely on unusual hosting setups.
WordPress’s advisory and the researchers’ technical description both emphasize that the initial XSS requires no authentication. However, the step from XSS to server-side impact depends on additional conditions.
How the exploit chain can reach PHP code execution
The researchers describe an approach they call XSS2Shell, which builds on earlier research concepts. The key idea is that the malicious script, once running in the context of a logged-in administrator, can interact with WordPress’s own client-side logic and then drive server-side actions.
From crafted username to live DOM elements
According to the researchers, WordPress processes the “username” value from a failed login through multiple functions. The path includes sanitization steps that are intended to remove or strip HTML-like content. In this case, a tag-like string can survive part of the parsing logic due to how certain text patterns are handled.
After that, a different processing step treats the same input as allowed content, resulting in attacker-controlled DOM elements on the failed-login page. In other words, what should be inert text ends up becoming active, scriptable markup in the browser.
Using WordPress scripts loaded on the login page
Those injected elements then interact with JavaScript that WordPress loads for profile-management behavior. The login screen also loads scripts used for password reset flows, so the page has more client-side functionality than you might expect.
The researchers note that certain inputs the script expects are absent in the login-page context, which creates logic paths where checks can be satisfied unintentionally. Additionally, variables that should not be controllable may be influenced by the injected elements, steering WordPress’s JavaScript toward attacker-selected same-origin REST requests.
Turning REST responses into script execution
To push the chain further, the researchers leverage WordPress’s REST JSONP support as a way to execute JavaScript that runs in the site’s origin. In setups where anonymous REST requests return HTTP 401, they also describe using an envelope parameter to get the response wrapped so the client continues processing it as script via jQuery.
In testing, they also observed that a nonce-based Content Security Policy using strict-dynamic did not block the demonstrated path.
What conditions are required for the full impact?
WordPress’s own assessment is more cautious about exploitability of the full chain. The core points are:
- The attacker does not need a special account or privileges to trigger the initial XSS.
- Server-side outcomes require that the victim is already logged in as an administrator.
- The attacker must then get the administrator to explicitly interact with an attacker-controlled page.
The researchers’ demonstration included a simple, ordinary click by the administrator on an attacker-controlled page.
One demonstrated route: abuse of Application Passwords
One of the researchers’ paths uses the XSS to invoke approval controls for Application Passwords within an administrator session. Because Application Passwords are designed for API access and can be revoked, this route does not require stealing the administrator’s primary password.
In their described workflow, WordPress creates an API credential and redirects it to an attacker-selected success_url. The credential can then be used for authenticated REST access to publish content that includes JavaScript.
When the retained administrator session opens that content, the script can retrieve a plugin-upload nonce and upload a ZIP supplied by the attacker. The researchers note that the plugin does not need to be activated for the next step in their demonstration. From there, PHP can be requested directly from the extracted plugin to continue the chain toward server-side execution.
Patch status and version guidance
WordPress patched the issue on August 6 in WordPress 7.0.3. Fixes were also backported through the 4.7 branch.
WordPress recommends updating immediately. If your site supports automatic background updates, the security release should arrive automatically.
Versions older than 4.7 remain affected, and they fall outside the project’s current backport range.
What a successful PHP execution could enable
A successful end state in the described chain would be far beyond a typical browser-side XSS. The researchers outline that PHP code execution could allow attackers to:
- Expose database credentials in wp-config.php
- Create persistent administrator accounts and modify content
- Read files and secrets accessible to the PHP worker
- Execute operating-system commands with the privileges of the PHP worker
That is why the update is urgent even though the attack starts without authentication.
Additional notes on mitigation
The researchers stress that relying only on general hardening measures is not sufficient. Because the root cause is the pre-authentication XSS, applying the security update remains required.
As of August 7, the available advisory did not report active exploitation in the wild.
Responsible disclosure and how the chain was developed
WordPress credited the team at pwn.ai for discovering the vulnerability and responsibly disclosing it. The researchers reportedly used open-source models and a multi-agent workflow and reproduced the chain on July 26, then reported the details the next day.
Conclusion: update your WordPress site now
The WordPress pre-auth XSS flaw in the login screen (CVE-2026-64638) may start with a crafted failed-login value, but under specific administrator-focused conditions it can be chained toward serious server-side outcomes, including PHP code execution. WordPress has already patched the issue, so the most practical and safest step is to update immediately to the patched versions.
If you manage a site, verify your WordPress version today and confirm that your update process is working. When it comes to XSS-to-RCE chains, waiting is not worth the risk.
Source: https://thehackernews.com/2026/08/new-wordpress-pre-auth-xss-could-lead.html
