WordPress Shipped Two Core Security Patches in Eight Days: XSS2Shell, an Author-Level RCE, and What to Verify Before 7.1 Drops

digital interactive web development hero image

Two Consecutive Core Patches, One Critical Window

WordPress shipped two security releases in eight days. Version 7.0.3 landed on August 6 with twelve vulnerability fixes. Version 7.0.4 followed on August 12, addressing a remote code execution vulnerability affecting every WordPress installation running version 4.7 or above. WordPress 7.1 ships August 19 at WordCamp US in Phoenix. Both patches need to be confirmed before that release arrives.

XSS2Shell: The Login Screen Flaw That Needs No Credentials

The headline fix in 7.0.3 is CVE-2026-64638, scored CVSS 8.9. Discovered and responsibly disclosed by the team at pwn.ai, the vulnerability lives in wp-login.php and exploits a parser disagreement between two sanitization functions: wp_strip_all_tags() and PHP’s native strip_tags(). A tag-like construct containing whitespace immediately after the opening angle bracket survives as text rather than being stripped, letting a crafted username inject JavaScript into the failed-login error page.

No authentication required. No existing session needed. An attacker sends a target a crafted URL, JavaScript executes in the browser under the site’s own origin, and credential harvesting begins on a legitimate hostname.

The escalation path goes further. For targets already logged in as Administrator, the XSS is weaponized through WordPress’s Application Password system. An attacker-controlled link triggers the native Application Password approval control inside an active admin session, creates an API credential, redirects it to an attacker-selected success_url, then uses the REST API to upload a plugin archive. The extracted PHP is requested directly. Full code execution on the server.

A nonce-based Content Security Policy using strict-dynamic does not block this path. The University of Toronto’s Information Security advisory is explicit: the technique “clobbers DOM properties consumed by already-trusted scripts rather than introducing new script sources.” CSP is not a compensating control here, and neither is WAF coverage alone.

What 7.0.3 Fixed Beyond the Headline

Twelve vulnerabilities total. Alongside CVE-2026-64638, the release addressed:

  • Contributor+ stored XSS in the Post Content block
  • Contributor+ stored XSS in Quick Edit on large-user sites
  • Contributor+ stored XSS in the Post Date block
  • Privilege escalation on Multisite networks with user registration enabled — registered users could create sites they have no business creating
  • Author+ CSS injection bypassing the safe CSS attribute filter (credited to Anthropic)
  • An email address confirmation bypass
  • A server-side request forgery bug in URL validation

The SSRF is worth calling out on its own. Patchstack describes it as “the first step in an attacker going from ‘just your WordPress site’ to digging around in your internal network.” For sites running on shared or cloud infrastructure with access to link-local metadata endpoints — common in AWS and GCP environments — SSRF is a lateral movement primitive, not just a site-level risk.

7.0.4: An Author-Level RCE That Arrived Six Days Later

Before teams had finished verifying 7.0.3 deployments, WordPress released 7.0.4 on August 12. CVE-2026-65640 is a remote code execution vulnerability exploitable by any user logged in at Author level or above, spanning every WordPress version from 4.7 through current 7.0.3. Managed hosting providers pushed patches immediately across shared and standalone installs. Self-managed installs on cloud infrastructure require manual action.

If your site grants Author access to contributors, guest writers, or freelance editors — and especially if those accounts share credentials or skip two-factor authentication — this is a live code execution path right now.

AI Is Finding These Faster Than Teams Can Patch Them

The pace deserves direct acknowledgment. The wp2shell chain patched in 7.0.2 was found by Searchlight Cyber running OpenAI’s GPT-5.6 Sol model against WordPress Core in ten hours for roughly $25. The XSS2Shell chain followed from pwn.ai’s autonomous pentesting system. The Author+ CSS injection in 7.0.3 is credited to Anthropic.

WordPress’s HackerOne intake hit 450 reports in July 2026 alone. Historically the monthly count sat in the dozens. The pipeline from patch publication to weaponized exploit has compressed. Once a high-impact diff is public, the patch itself reconstructs the vulnerability. Attackers using the same AI tooling that found these bugs can reproduce them faster than most teams can confirm auto-updates ran.

What to Verify on Your Site Right Now

Check your WordPress version directly at Dashboard > Updates or via wp core version --allow-root in WP-CLI. Do not trust what your hosting control panel reports without a direct verification.

For 7.0.4 specifically: audit every account holding Author, Editor, or Administrator roles. Remove unused accounts. For 7.0.3’s XSS2Shell chain, disable Application Passwords under Settings > General if your site has no active REST API integrations — this removes the demonstrated escalation path at no operational cost.

On deployments where plugin management is handled through CI/CD pipelines rather than the WordPress admin, define DISALLOW_FILE_MODS true in wp-config.php. This blocks the plugin-upload stage of the XSS2Shell chain and is sound hardening independent of this specific vulnerability.

The Multisite privilege escalation in 7.0.3 only affects networks with user registration enabled. Check Network Admin > Settings > Allow new registrations if you run a multisite install and have not already confirmed the patch is live.


Sources: