Introduction

WordPress shipped version 7.0.3 on August 6, 2026 as a security-only release. The headline fix is CVE-2026-64638, a pre-authentication reflected XSS bug on the login screen that researchers turned into PHP code execution on the server. The team at pwn.ai found it and named the full chain WordPress XSS2Shell. The advisory is published as GHSA-52p2-r8wf-jcrf and the severity is rated high at CVSS 8.9, with fixes backporting through every supported branch down to WordPress 4.7.

As of August 7 no cases of in-the-wild exploitation have been reported. WordPress also notes that the code execution stage depends on conditions outside the attacker's control, because it needs a logged-in administrator to visit an attacker-controlled page and click once. That does not make this bug a paper tiger. The XSS stage itself requires no account at all, and WordPress runs roughly 43 percent of the public web, so the patch is urgent.

Why This Matters

Reflected XSS bugs show up often, but they rarely grow into a path to code execution. This one is different for two reasons. First, the flaw lives in a parser disagreement inside WordPress's own sanitization pipeline, which makes it invisible to most rule-based filters. Second, pwn.ai demonstrated a working route from the XSS to a PHP shell using only legitimate WordPress APIs, and they say their setup replayed the chain after starting from Paulos Yibelo's 2022 Same Origin Method Execution (SOME) research.

WordPress and pwn.ai do not fully agree on severity. pwn.ai reported multiple paths from the XSS to code execution, including variants that install a plugin or upload an arbitrary ZIP package. WordPress's advisory frames the escalation as needing social engineering plus explicit victim interaction. Both sides agree on the remedy: update right away.

The Technical Breakdown: Two Parsers, One Input

The bug starts at wp-login.php. When a client submits a username that does not exist, WordPress echoes that username back into the error message after running it through sanitize_user() and wp_strip_all_tags(). The latter calls PHP's strip_tags(), and that is where the parser split appears.

If the crafted username contains a space between an opening angle bracket and a tag name, a string like "< area", then PHP's strip_tags() treats the input as inert text and lets it pass. The same bytes later go through wp_kses_post(), and that separate parser reinterprets the identical string as allowed live HTML: elements such as <area>, <div>, and <button> land in the page DOM of the failed-login screen.

Those elements do nothing by themselves. They are crafted to match selectors that user-profile.js scans for automatically when the login page loads. That script is present because the login screen also handles the password reset flow. Two inputs the script expects are missing on this page, so both resolve to undefined and an equality check passes. At the same time, the global ajaxurl variable, which would normally point to the admin AJAX endpoint, is also undefined here, which allows an injected DOM element to clobber it. WordPress's own JavaScript now hands the attacker control of the request destination.

The AJAX call is aimed at the WordPress REST API with method-override and JSONP parameters. With the JSONP handler, the response arrives wrapped in executable JavaScript. On installations where anonymous REST requests return HTTP 401, the _envelope=1 parameter wraps the denial in an outer HTTP 200, and jQuery keeps processing the response as a script. The result is script execution inside the WordPress origin with no account and no victim interaction at this stage. pwn.ai also notes that a nonce-based Content Security Policy using strict-dynamic did not block the flow.

From XSS to Server Code Execution

The jump from browser XSS to PHP execution builds on Yibelo's SOME technique. The WordPress-origin script invokes the native Application Password approval control inside the session of a logged-in Administrator. WordPress then creates an API credential and redirects it to an attacker-chosen HTTPS success_url.

Application Passwords are revocable credentials made for API access, so this stage never needs the administrator's actual password. The attacker uses the fresh credential over the authenticated REST API to publish a page that hosts same-origin JavaScript. When the administrator's browser later opens that page (the click the advisory keeps mentioning), the script reads the plugin upload nonce and pushes an attacker-provided ZIP to the site. PHP code from the uncompressed plugin can then be requested directly, and no plugin activation is required.

Impact: What an Attacker Gains

According to the pwn.ai research shared with The Hacker News, a completed chain gives the attacker:

• The database credentials stored in wp-config.php
• Persistent administrator accounts and unapproved site content
• Any files and secrets readable by the PHP worker process
• Operating system commands under the web server's user

The exploit does not rely on unusual hosting. It works against default WordPress installations. WordPress hardening measures such as login limiters or security extensions treat the symptoms but not the parser disagreement, so the security update remains the only complete fix.

Affected Versions and Support

Component	Status
WordPress 4.7 to 7.0.2	vulnerable, safe only after update
WordPress 7.0.3	patched
WordPress 7.1 RC2	contains all fixes
Versions below 4.7	outside backport range, upgrade

The backports are shipped as they are released, so administrators on maintained branches should track the 7.0.3 (and later) release lines.

How to Patch

• Open Dashboard, Updates and run the update now button, or download the archive from wordpress.org and replace the files.
• Sites with automatic background updates enabled will download 7.0.3 themselves; self-hosted installs often need a manual nudge.
• After the update, verify the version on a terminal: locate the wp-includes/version.php file and confirm the version string reads 7.0.3.
• Check the users profiles for Application Passwords you never created, and list freshly uploaded plugins in Plugins.
• Managed hosts: track the provider's maintenance window because the vendor may apply the update for you.

Detection and Indicators

No known malicious indicators exist because no in-the-wild attack has been documented yet. Still, look for these signs after the incident window:

• Unexpected Application Passwords in any admin profile
• Plugins that appear without a matching admin action in the activity log
• Failed login noise targeting wp-login.php suggests attackers exploring the XSS surface
• REST API requests with _method or JSONP style parameters in access logs belonging to no automation

Frequently Asked Questions

What is the CVE for the WordPress XSS2Shell?

CVE-2026-64638, published with advisory GHSA. The CVSS score is 8.9.

Does the bug require a logged-in account?

The XSS reads no authentication. Code execution needs a logged-in Administrator to click once on an attacker-owned page.

Which versions of WordPress are at risk?

Every supported version before 7.0.3, with the fix backported through the 4.7 branch. Sites under 4.7 are outside support and should be upgraded to a supported version.

Can a web application firewall or Content Security Policy protect a site?

Partially at best. A nonce-pointed strict-dynamic Content Security Policy did not block the pwn.ai route. The authenticated API calls used in the chain look legitimate, so treat these filters as first response, not as replacements for the update.

Has XSS2Shell been used in attacks?

No cases are confirmed as of the advisory publication in August 2026.

What if I cannot update WordPress right now?

Restrict access to wp-login.php where possible, keep an eye on failed login traffic, and treat any odd REST calls with JSONP parameters as suspicious. Close the window for the update as soon as it opens, because the XSS stage needs no authentication and the chain is likely to be adapted once more details circulate.

Key Takeaways

• Update to WordPress 7.0.3 immediately; it is an emergency security release and covers backports from 4.7.
• CVE-2026-64638 is a login-page reflected XSS that pwn.ai chained to remote code execution.
• The bug is a parser disagreement between strip-tags style functions and wp-kses, which makes it hard to catch with signatures.
• Code execution closes an Administrator click, but the XSS itself is unauthenticated and affects the majority of the web.
• Keep an eye on Application Passwords and plugin uploads as leading indicators of abuse.

---

Sources: WordPress 7.0.3 release notes | GHSA advisory for CVE-2026-64638 | The Hacker News: pre-auth XSS chain report | GBHackers: XSS2Shell technical summary | pwn.ai research blog