Critical Vulnerability · CVE-2026-63030

WP2Shell: Pre-Auth RCE in WordPress Core (CVE-2026-63030) Puts Sites One Request From a Shell

An unauthenticated attacker can reach code execution through the WordPress REST API batch endpoint on a default install, no account, no plugins, no user interaction. Patch to 6.9.5 or 7.0.2 now; researchers expect a public exploit within days.

Matt Lucas  |  July 18, 2026  |  5 min
A cracked iron padlock with a red command-line cursor bursting out, editorial hero illustration
CVEs in this postCVE-2026-42533CVE-2026-63030Live detections →All RedEye CVEs →
7.5
CVSS (GitHub: Critical)
0
authentication required
6.9.5 / 7.0.2
patched versions
500M+
sites running WordPress
TL;DR
  • What it is: CVE-2026-63030, nicknamed "WP2Shell," is a pre-authentication remote code execution flaw in WordPress core's REST API batch endpoint (/wp-json/batch/v1). It works against a stock install with no plugins, no valid account, and no user interaction. Found by Adam Kues at Searchlight Cyber.
  • Affected and fixed: WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 are vulnerable (7.1 betas too). Fixed in 6.9.5, 7.0.2, and 7.1 Beta 2. Anything 6.8.5 or earlier is not affected.
  • Status: No confirmed in-the-wild exploitation yet, and technical details are being held back to give defenders time, but Rapid7 assesses a public proof-of-concept is highly likely within days. Treat this as patch-now.

What WP2Shell is

CVE-2026-63030 lives in WordPress core, not a plugin or a theme, which is what makes it serious. The vulnerable path is the REST API batch endpoint at /wp-json/batch/v1 (also reachable as ?rest_route=/batch/v1), a feature that lets a client bundle several API calls into one request. An unauthenticated attacker can abuse that endpoint to reach code execution on the server. Rapid7 notes the flaw is reachable specifically when a persistent object cache is not in use, which describes the majority of ordinary WordPress installs.

Searchlight Cyber, who reported it, are deliberately withholding the exploit chain for now. That is the right call given the blast radius, but it does not buy you much time: the fix is public, and public fixes get reverse-engineered.

Why this one is bad

Three things stack up. It is pre-authentication, so an attacker needs nothing from you, no credential, no phished admin, no vulnerable plugin. It hits WordPress core, so a default install is enough; you do not have to have installed anything risky. And WordPress runs a large share of the entire web, so the population of exposed targets is enormous. A single crafted HTTP request to a public endpoint that ends in code execution, against that many sites, is exactly the shape of bug that mass-exploitation campaigns are built on.

The exploit-to-persistence pattern

An RCE like this almost always ends the same way: the attacker drops a PHP web shell into the webroot for persistence, then pivots, harvests credentials from wp-config.php, or stages ransomware. The initial request is the opening move; the web shell is the tell.

Affected and patched versions

Sites with automatic background updates enabled likely already received 6.9.5 or 7.0.2. Do not assume, confirm the running version.

Exploitation outlook

As of disclosure (GitHub Security Advisory, July 17, 2026), there is no confirmed exploitation in the wild, and Rapid7's vulnerability checks went live July 20. But Rapid7 Labs explicitly assessed that a public PoC is highly likely to appear quickly, and history agrees: internet-facing, unauthenticated core bugs in ubiquitous software are weaponized within days of the patch, not months. The safe assumption is that the window is now.

What to do now

  1. Immediate
    Update WordPress

    Upgrade to 6.9.5, 7.0.2, or 7.1 Beta 2. The maintainers recommend patching over any workaround. Verify the version after updating rather than trusting auto-update silently ran.

  2. If you cannot patch this hour
    Block the batch endpoint

    At your WAF or reverse proxy, deny requests to /wp-json/batch/v1 and ?rest_route=/batch/v1. Optionally disable the REST API via a trusted plugin, or add an authentication filter for the batch controller. Treat these as stopgaps until the update lands, not a permanent fix.

  3. Ongoing
    Watch for the shell

    Even a patched fleet should be monitored for the post-exploit artifact, unexpected PHP files in the webroot and anomalous requests to the batch endpoint, in case a site was hit before it was patched.

How RedEye and Caver catch it

Patching closes the door; monitoring tells you whether anyone got through first. Caver ingests web and server telemetry and flags the two halves of this attack: the exploitation attempt, unauthenticated POST requests to /wp-json/batch/v1 or ?rest_route=/batch/v1 and anomalous REST batch activity from unexpected sources, and the post-exploitation payload, a PHP web shell written to the webroot, which Caver detects by default (MITRE ATT&CK T1505.003). RedEye analysts triage and escalate, so an attempt against your WordPress estate is seen and acted on rather than discovered after the defacement or the data theft.

Sources

Rapid7, "ETR: CVE-2026-63030 WP2Shell," and Searchlight Cyber research by Adam Kues, "WP2Shell: Pre-Authentication RCE in WordPress Core" (July 17, 2026). Vulnerability portal: wp2shell.com. CVE tracked as CVE-2026-63030.

Is your WordPress estate exposed?

RedEye Security runs external exposure reviews and stands up Caver monitoring that flags exploitation attempts and post-exploit web shells in real time.

Talk to RedEye Security