wp2shell: One Anonymous Request Can Take Over an Unpatched WordPress Site. Here's What to Check.

On 17 July, WordPress shipped an emergency security release for a flaw its researchers named wp2shell. The short version: on a vulnerable site, a single HTTP request from someone with no account, no plugin dependency, and no special access can run code on your server. Default install, zero plugins, still exploitable.

If your site is on an affected version, treat it as compromised-until-proven-otherwise and patch today. Everything below is detail on how to check and what to do.

Am I actually affected?

This is where a lot of the early social-media chatter got sloppy, so be precise about versions. The full remote-code-execution (RCE) chain affects:

6.9.0 through 6.9.4
7.0.0 through 7.0.1

The fixes are 6.9.5 and 7.0.2. A separate SQL injection bug from the same release round reaches back to the 6.8 branch, patched in 6.8.6. Anything older than 6.8 isn't affected at all, because the vulnerable code only arrived with 6.9, which shipped in December 2025.

So a site already sitting on 6.9.5 or 7.0.2 is fine. "6.9 or 7.0" as a blanket claim overstates it. Check the actual point release.

WordPress considers this its highest-severity class of issue and has force-pushed automatic updates to affected sites, so most will patch themselves. Do not take that on faith. If a site has auto-updates disabled, is behind an unusual deployment pipeline, or is one of those "we forgot that subdomain existed" installs, the background update may never land. Verify each instance:

# On any host with WP-CLI
wp core version
# expect 6.9.5, 7.0.2, or later

wp core verify-checksums --include-root

No WP-CLI? Log into wp-admin and read the version in the footer, or check Dashboard → Updates.

Can't patch this minute? Stopgaps only.

Every mitigation the researchers offer comes down to keeping anonymous callers off the REST API batch endpoint. They are bridges until you update, not replacements for it, and each can break legitimate integrations:

WAF rule: block both /wp-json/batch/v1 and ?rest_route=/batch/v1. You need both patterns; blocking one leaves the other open.
Plugin: the "Disable WP REST API" plugin, or the drop-in plugin the researchers published on wp2shell.com, which rejects anonymous batch requests.

If your traffic is proxied through Cloudflare, its WAF picked up rules for this on 17 July at 17:03 UTC across all plan tiers. One catch worth knowing: that only covers proxied traffic. A DNS-only record, a direct origin IP, or an alternate hostname that bypasses the proxy gets no protection. The patch is the only thing that protects the code itself.

The technical detail

wp2shell isn't one bug. It's two, and the way they combine is what makes it dangerous.

CVE-2026-60137 is a SQL injection in the author__not_in parameter of WP_Query, the core class behind nearly every database query WordPress runs. The fix normalises author IDs to integers before they reach the query. This is the piece that also touches the 6.8 branch.

CVE-2026-63030 is a route-confusion condition in the REST API batch endpoint at /wp-json/batch/v1. Attacker-controlled input gets misrouted and interpreted in a way it shouldn't be. On 6.9 and above, chaining the batch confusion with the SQL injection turns "read data you shouldn't" into "execute code on the box."

Two things senior engineers will want to note:

First, the batch endpoint isn't exotic. It's been in core since WordPress 5.6 in November 2020 and is enabled by default. This isn't a niche configuration that most sites will have switched off. The patched files in 7.0.2 are class-wp-rest-server.php, class-wp-query.php, and rest-api.php, if you want to diff the change yourself.

Second, on the CVE tracking: the IDs exist, but as of 18 July the CVE records had not fully propagated. That means CVE-keyed scanners and asset inventories may not flag this yet, and CISA can't add it to the KEV catalogue until the record lands. Track it by WordPress version number, not by waiting for your scanner to light up. Some early write-ups claimed "no CVE exists," which is wrong; the honest caveat is that the records are still catching up to the disclosure.

One nuance Cloudflare surfaced that's easy to misread: the disclosed RCE path applies when a persistent object cache (Redis or Memcached) is not in use. Do not turn that into "Redis fixes wp2shell." An object cache is not a vendor patch, the SQL injection is still present, and treating a cache backend as your fix is exactly the kind of assumption that leaves a site exposed.

At the time of writing there's no public proof-of-concept and no confirmed exploitation in the wild. Given the install base and the trivial attack precondition, that window is unlikely to stay quiet. Full technical details are being withheld to give defenders time. We saw a similar escalation pattern with the JADEPUFFER AI ransomware attack earlier this month, where five-year-old CVEs and default credentials were the actual entry points, not sophisticated new techniques.

Where OrionX comes in

If you manage a handful of WordPress sites, patching is an afternoon. If you're a small business with a marketing site, a client portal, and two staging boxes nobody's logged into since 2023, the risk isn't the patch itself. It's that you don't have a reliable inventory of what's running where, or proof that the forced update actually landed on every instance.

That's the work we do. Our cybersecurity services include auditing every WordPress instance you own, confirming the patched version and checksums on each, applying stopgap WAF rules where an update can't ship immediately, and reviewing your logs for any activity during the exposure window. If you'd rather this not be a fire drill next time, we also run ongoing managed maintenance so critical patches like this one are verified within hours, not whenever someone happens to notice.

If you're not sure whether you're exposed, that uncertainty is the thing to fix. Get in touch with OrionX and we'll check it for you.