XSS2Shell: A Pre-Authentication Chain Can Turn WordPress into a Gateway to the Server

From the Login Page to DOM Clobbering

Pwn researchers recently disclosed XSS2Shell, a critical attack chain that starts from the WordPress login page and requires no initial authentication.

The attack uses a nonexistent username, which is reflected in the error message. The first filter, applied by PHP through strip_tags(), does not recognize elements written with a space between the < character and the tag name:

< area id=ajaxurl>

The subsequent wp_kses_post() call interprets the string as a valid HTML element, turning it into active content in the DOM.

The id="ajaxurl" attribute then enables DOM clobbering: the browser exposes the element as the window.ajaxurl property, altering the behavior expected by the page’s scripts.

Abusing user-profile.js and the REST API

The login page also loads user-profile.js, which is used to manage password resets. The script can automatically locate and activate a manipulated reset button without an explicit administrator click.

The chain then exploits a JSONP response from the REST API. The callback parameter accepts dots, allowing property chains to be traversed across browser windows. The researchers reused a technique first made public in 2022 to trigger a cross-window click within the active session of an authenticated administrator.

The browser is redirected to a WordPress screen for approving an Application Password. The administrator’s session cookies and nonce allow the approval button to be activated automatically.

The result is a valid Application Password for the administrator account.

From the Credential to Potential Code Execution

WordPress accepts the Application Password through HTTP Basic authentication on the REST API. The CORS configuration reflects the request origin and permits the Authorization and Content-Type headers, enabling authenticated cross-origin API calls.

On single-site installations, administrators normally have the unfiltered_html capability. Arbitrary JavaScript can therefore remain in published content.

The attacker can publish a page containing JavaScript, use it to load a plugin, and achieve arbitrary PHP code execution. In the proof of concept, a JSON response confirmed execution under the web server user’s identity.

Potential impact includes:

• compromise of the administrator’s session;
• fraudulent issuance of Application Passwords;
• publication of JavaScript content;
• installation of malicious plugins;
• Remote Code Execution;
• possible full server takeover.

The proof of concept left no persistence: the researchers revoked the credential, deleted the page, and removed the plugin directory.

What Administrators Should Check

No CVE identifiers or vulnerable and fixed version numbers have been provided for WordPress, PHP, browsers, or the components involved.

Administrators should:

1. update WordPress to the vendor’s latest fixed versions;
2. apply security updates to WordPress, PHP, and installed components;
3. revoke suspicious or unnecessary Application Passwords;
4. inspect published pages, plugins, plugin directories, and REST API logs;
5. look for anomalous requests to Application Password approval endpoints;
6. monitor JSONP traffic and cross-origin requests containing the Authorization header;
7. reduce administrative privileges and restrict the use of unfiltered_html where possible.

The affected versions are unknown. Consequently, the absence of observable anomalous activity is not sufficient to rule out a compromise.