A WordPress administrator opens a link, the page loads, nothing looks particularly suspicious, and the attacker gains a route to execute code on the server.
The administrator never entered a password into a fake login page. And the attacker never needed an account.
Instead, a flaw in WordPress's login screen allows malicious HTML to interact with existing JavaScript, turning a browser-level vulnerability into remote code execution (RCE).
Known as XSS2Shell (CVE-2026-64638), the vulnerability shows how a small mistake in handling user input can become considerably more dangerous when combined with legitimate application features.
XSS2Shell at a Glance
The vulnerability was disclosed in August 2026 by researchers at pwn.ai, who demonstrated how a reflected XSS issue in WordPress core could be chained with several browser and application behaviours to achieve server-side code execution.
WordPress confirmed the finding in its 7.0.3 security release, which addressed the login-screen vulnerability alongside other security issues.
Although the initial XSS can be triggered without an attacker account, the demonstrated RCE chain requires an administrator to be authenticated and interact with a crafted link.
The Vulnerability Was Hiding in a Login Error
The attack begins with something WordPress does routinely: displaying an error when somebody attempts to log in using an invalid username.
The submitted username can appear in the error message, making it a natural place for an attacker to test whether malicious input can reach the page.
WordPress normally sanitises that input before displaying it. The problem was that two functions involved in the process interpreted the same malformed HTML differently.
The first function, PHP's strip_tags(), removes recognised HTML tags. However, a specially formed tag containing whitespace immediately after the opening angle bracket could survive this filtering.
Later, WordPress passed the value through wp_kses_post(), its own HTML sanitisation function.
That function interpreted the surviving input differently, treating parts of it as permitted HTML.
The result was a parser differential: one component considered the input harmless text, while another allowed it to become live HTML in the rendered login page.
This gave attackers a way to introduce carefully constructed elements into a page they did not control.
Crucially, the vulnerable output lacked the appropriate final HTML escaping. WordPress's own secure output guidance recommends context-appropriate escaping, including esc_html() when displaying untrusted text inside an HTML element.
In this case, that missing protection helped turn a failed login into the starting point for a much larger attack.
The JavaScript That Made the Bug Exploitable
Getting attacker-controlled HTML onto a page is serious, but it doesn't automatically mean arbitrary JavaScript can execute.
The researchers needed another way to make the injected elements do something useful. And they found it in WordPress's existing JavaScript.
The login page loaded a script originally designed to support user-profile functionality, including password generation and interface controls. Some of its behaviour depended on particular HTML elements being present.
Those elements weren't normally available on the login page. The vulnerability allowed an attacker to introduce elements with the names and attributes the script expected.
When the page loaded, the existing JavaScript interacted with those injected elements and triggered functionality that had been designed for a different context.
The attacker could influence how trusted application code behaved without directly inserting an ordinary script tag.
DOM Clobbering: Making HTML Behave Like JavaScript State
One technique involved was DOM clobbering.
Browsers can expose certain HTML elements as named properties on the window object. JavaScript that relies on those names can behave unexpectedly when attacker-controlled elements are present.
In the XSS2Shell chain, the researchers used this behaviour to influence a variable that WordPress's JavaScript expected to reference a request destination.
The application then made a request using the attacker-influenced value.
The important weakness was the trust placed in a value that could be affected by the document's HTML structure.
For security practitioners exploring the fundamentals, the Cross-Site Scripting room covers reflected, stored and DOM-based XSS, including why apparently small input-handling mistakes can have significant consequences.
XSS2Shell takes that principle further by chaining the browser behaviour into an authenticated WordPress workflow.
How the Attack Crosses Into an Administrator's Session
The next stage used Same Origin Method Execution (SOME), a technique that can abuse legitimate methods exposed within a browser's origin.
The researchers combined the earlier DOM manipulation with WordPress's legacy support for JSONP callbacks.
JSONP allows a server response to be wrapped in a JavaScript callback. In the affected workflow, the response could be interpreted as executable JavaScript.
By manipulating the callback mechanism, the attack could reach a method associated with another browser window.
The researchers used this to interact with WordPress's Application Password authorisation interface.
The attacker had initiated the chain without knowing the administrator's credentials, but the malicious workflow could influence actions taken through that existing authenticated session.
Application Passwords Turn Browser Access Into Persistent API Access
WordPress Application Passwords allow users to create separate credentials for external applications and integrations.
They are legitimate, revocable credentials intended for programmatic access through interfaces such as the WordPress REST API.
An administrator might use one to connect a publishing tool or automation service without sharing their main account password. The XSS2Shell exploit abused the authorisation process.
Through the browser interaction described earlier, the attacker could cause an authenticated administrator's session to approve a new Application Password.
The resulting credential was then returned through the authorisation flow to an attacker-controlled destination.
At that point, the attacker had obtained an API credential associated with the administrator's account. This did not require knowing or resetting the administrator's primary password.
WordPress documents how these credentials work, including how administrators can review and revoke Application Passwords.
In the demonstrated attack, their legitimate functionality became the bridge between the browser exploit and further actions within WordPress.
From an API Credential to Code Execution
The final stage turned the newly obtained access into server-side impact. Using the administrator's Application Password, the researchers demonstrated how the attacker could make authenticated WordPress REST API requests.
That capability allowed the creation of a published WordPress page containing attacker-controlled JavaScript.
The attack then returned to the administrator's authenticated browser session.
When the crafted page was opened, its JavaScript could interact with WordPress's administrative plugin-upload functionality using the permissions and security tokens available to that session.
The researchers demonstrated the upload of a malicious PHP plugin archive.
Once extracted into the WordPress plugin directory, the relevant PHP file could be accessed on the server without requiring the plugin to be activated through the normal interface. That completed the chain from reflected XSS to remote code execution.
In the research demonstration, code executed with the privileges of the web server user. The actual consequences of a compromise would depend on the server's configuration, filesystem permissions and available access.
Successful code execution could nevertheless expose application files, sensitive configuration information and other resources accessible to the web server process.
The complete technical sequence is documented in pwn.ai's original XSS2Shell research.
Which WordPress Versions Need Attention?
WordPress released version 7.0.3 on 6 August 2026, addressing CVE-2026-64638.
The project also provided security backports for eligible older branches, including versions dating back to WordPress 4.7.
For example, WordPress 6.9.6 and 6.8.7 are among the older releases containing relevant security fixes.
Organisations running WordPress should confirm that their installation includes the corrected core code, rather than relying on a major version number alone.
The official WordPress 7.0.3 documentation lists the release and the backported security updates.
What Security Teams Should Check
For organisations operating WordPress websites, the immediate response is straightforward: establish whether the site is affected and apply the relevant security update.
Teams should also consider whether any activity warrants investigation.
A practical review includes:
- Verify the WordPress core version. Confirm that the affected installation has received WordPress 7.0.3 or the appropriate security backport. Include staging sites and less visible WordPress deployments in the review.
- Review administrator Application Passwords. Look for unfamiliar credentials, unexpected creation times and usage that cannot be explained by authorised integrations.
- Check for unexpected content and plugins. Investigate unfamiliar published pages, new plugin archives and suspicious PHP files where the available evidence supports further review.
- Examine relevant access records. Review unusual login-page requests, Application Password authorisation activity and subsequent administrative changes, recognising that available logs may not capture every stage of the chain.
- Assess potential compromise separately from patching. If exploitation is suspected, preserve relevant evidence and investigate possible access before assuming the update alone has removed an attacker's foothold.
Take XSS2Shell Apart in a Controlled Lab
XSS2Shell is a useful case study because it combines several concepts that security practitioners often learn separately.
A parser disagreement introduces attacker-controlled HTML. DOM clobbering changes how existing JavaScript behaves. SOME and JSONP extend the impact into an authenticated browser workflow. Application Passwords then provide a path towards administrative actions that culminate in code execution.
Understanding that progression is much more useful than memorising a single proof-of-concept payload.
The hands-on XSS2Shell: CVE-2026-64638 room brings those stages together in a controlled WordPress environment.
You'll explore how the initial login-page vulnerability works, investigate the DOM and browser behaviour behind the chain, and follow the escalation towards RCE.
It's an opportunity to understand how attackers combine otherwise ordinary application features into a much more serious vulnerability.
Ayomide Joseph A.
