A critical pre-authentication remote code execution flaw in WordPress Core — nicknamed wp2shell — was disclosed on July 17, 2026, along with patches for all affected branches. The bug requires no login, no plugins, and no special configuration: a default, bare WordPress installation running 6.9 or 7.0 is fully exploitable by anyone on the internet. WordPress patched the issue in 6.9.5 and 7.0.2, which were released the same day as disclosure and pushed via the auto-update system. No confirmed in-the-wild exploitation has been reported as of July 18, but a public proof-of-concept is expected imminently given the open-source codebase and the number of researchers now studying the patch diff.

What the Vulnerability Is

CVE-2026-63030 is a chain of two weaknesses in WordPress Core that together allow an unauthenticated attacker to execute arbitrary server-side code.

The entry point is the REST API Batch Endpoint (/wp-json/batch/v1 or via query string as ?rest_route=/batch/v1). This endpoint, present in WordPress since version 5.6 (November 2020), normally accepts batches of REST requests. Something changed in the 6.9 codebase that introduced a route confusion condition: by nesting a crafted request twice, an attacker can bypass the endpoint's method allow-list and slip a rogue parameter into WP_Query — WordPress's core database query builder.

That rogue parameter reaches the database as a string without proper sanitization, producing a blind SQL injection (CVE-2026-60137 is the companion SQL injection bug and is also patched in WordPress 6.8.6 for the 6.8 branch). WordPress's release notes describe the full chain as "a REST API batch-route confusion and SQL injection issue leading to Remote Code Execution."

Cloudflare's analysis notes that the vulnerable code path is reachable when a persistent object cache is not in use — meaning sites running Memcached, Redis, or similar persistent object cache backends may have reduced exposure, but this is not a reliable mitigation.

The bug only exists from WordPress 6.9 onward. WordPress 6.9.0 shipped on December 2, 2025, so every affected site is running a release less than eight months old.

Why It Matters

  • No prerequisites. Unauthenticated, no plugins required, no misconfiguration required. A stock install is enough.
  • Scale. WordPress powers roughly 43% of all websites on the internet. While only sites on 6.9.0–6.9.4 or 7.0.0–7.0.1 are in range, those branches are relatively recent, meaning a large population of active, maintained sites is affected.
  • PoC pressure. Searchlight Cyber (who found the bug) has withheld full technical details, but the three files changed by the WordPress 7.0.2 patch are public in the release archive. Researchers routinely produce working PoCs from patch diffs within hours.
  • CISA lag. Because the advisory did not initially carry a CVE ID and NVD indexing takes time, automated CVE-keyed scanners may not flag unpatched sites immediately. Version-based detection is required.
  • Historical parallel. A prior WordPress core-level attack campaign (WP-SHELLSTORM) compromised 25,000+ sites using an already-patched plugin flaw. A core-level pre-auth RCE is a significantly more powerful primitive.

Am I Affected?

You are affected if your WordPress installation is running any of the following:

BranchAffected VersionsFixed Version
6.8Not affected by CVE-2026-63030 (but patch 6.8.6 for companion SQL injection CVE-2026-60137)6.8.6
6.96.9.0 through 6.9.46.9.5
7.07.0.0 through 7.0.17.0.2
7.1 betaAffected beta versions7.1 Beta 2

You are not affected if you are running WordPress 6.8.x or earlier (for CVE-2026-63030 specifically).

WordPress pushed auto-updates to sites with automatic updates enabled. However, auto-updates can be disabled by theme or plugin code, or by hosting environment configuration. Do not assume the update landed — log in and verify the version on every internet-facing site.

What to Do About It: Step-by-Step

1. Patch first — everything else is a stopgap.

# Via WP-CLI (recommended for all sites you manage)
wp core update --version=7.0.2   # or 6.9.5 for sites on the 6.9 branch
wp core verify-checksums

# Verify the exact installed version
wp core version

Update the site and confirm the version shown is 6.9.5, 7.0.2, or later before moving on.

2. If you cannot patch immediately, implement WAF rules.

Searchlight Cyber explicitly warns that you must block both URL paths for the batch endpoint — blocking only the /wp-json/ path leaves the query-string route open:

  • Block requests matching /wp-json/batch/v1
  • Block requests matching rest_route=/batch/v1 (query string form)

This can break legitimate REST API clients and headless/block-editor usage; it is a temporary measure only.

3. Alternative: disable unauthenticated REST access.

Install the "Disable WP REST API" plugin to block unauthenticated REST API access wholesale. This is heavier-handed than a targeted WAF rule and will break the block editor for logged-out users, but it fully closes the attack surface until you can patch.

4. Monitor batch endpoint traffic.

After patching, check access logs for anomalous traffic against /wp-json/batch/v1 that predates your patch. Any hits from unfamiliar IPs may warrant a site integrity check.

5. Run a file integrity check.

wp core verify-checksums
wp plugin list --update=available

If core checksums fail, assume compromise and restore from a known-good backup taken before any suspicious access.

6. Check for rogue admin accounts.

wp user list --role=administrator

Pre-auth RCE is typically weaponized to create a backdoor admin account or plant a webshell. Audit your admin list and compare against known-good.

Quick-Win Checklist

  • Log into wp-admin on every site and confirm the version is 6.9.5, 7.0.2, or later
  • Run wp core update on all sites you manage via WP-CLI
  • Enable automatic core updates if not already on (WP_AUTO_UPDATE_CORE = true in wp-config.php)
  • If patching is delayed: block /wp-json/batch/v1 AND rest_route=/batch/v1 at your WAF
  • Audit administrator accounts for unexpected additions
  • Run wp core verify-checksums to confirm file integrity
  • Review access logs for hits against the batch endpoint prior to patching

Sources