Same Story, Different Layer: WP2Shell and the WordPress Core RCE Chain

We've spent the last few months writing about kernel and control-panel bugs — Copy Fail, DirtyFrag, GhostLock  — all of them living below the layer Monarx primarily defends. This week the bug landed exactly where we live: WordPress core itself, in a chain researchers are calling WP2Shell. An anonymous HTTP request against a stock install, no plugins, no login, ends in remote code execution. That's about as close to home as it gets for our customer base. The good news for Monarx customers - ThreatShield’s behavioral detection for this exploitation pattern was already active in production before the issue was publicly disclosed, giving them coverage during the exposure window.

What WP2Shell is

WordPress shipped version 7.0.2 on July 17, along with backports to 6.9.5 and 6.8.6, to fix two vulnerabilities reported independently through the project's HackerOne program:

• CVE-2026-63030 — a REST API batch-route confusion issue, rated Critical, discovered by Adam Kues of Assetnote (Searchlight Cyber). Affects 6.9.0–6.9.4 and 7.0.0–7.0.1.
• CVE-2026-60137 — a facilitated SQL injection in the author__not_in parameter of WP_Query, rated Moderate on its own, reported by TF1T, dtro, and haongo. Affects the wider range 6.8.0–6.8.5, 6.9.0–6.9.4, and 7.0.0–7.0.1.

Neither bug is severe by itself. The SQL injection normally needs an authenticated session to reach. The batch-route confusion is what turns that into a problem for everyone: it's used as an authentication bypass, smuggling an anonymous request into the vulnerable query path. Chained, an unauthenticated visitor can pull database contents, crack an admin password offline, log in, and drop a webshell, VulnCheck's technical writeup walks through this path in detail, and Searchlight Cyber's own advisory is where the WP2Shell name comes from, along with a free checker tool for testing whether a given site is exposed.

A useful technical note from Hadrian's research: the vulnerable batch endpoint doesn't require pretty permalinks to reach. It answers on both /wp-json/batch/v1 and the always-available ?rest_route=/batch/v1 query-string form, so sites that disabled rewrite rules are still exposed on the second path. Any WAF rule or mitigation plugin has to block both, or it isn't a real block.

One mitigating factor worth knowing about: coverage citing Cloudflare notes the RCE path depends on the target not running a persistent object cache (Redis or Memcached). A default install has none, so out-of-the-box exposure stands, but sites already running one of those in front of WordPress may sit outside this specific path  though not outside the underlying SQL injection.

Affected versions

• < 6.8.0 — Not affected.
• 6.8.0 – 6.8.5 — SQL injection only, requires authentication. Fixed in 6.8.6.
• 6.9.0 – 6.9.4 — Full unauthenticated RCE chain. Fixed in 6.9.5.
• 7.0.0 – 7.0.1 — Full unauthenticated RCE chain. Fixed in 7.0.2.
• 7.1 beta2 — Both issues present in beta. Patched in 7.1 beta2.

If you're tracking a fleet, 6.9.x and 7.0.x are the priority tier. That's where the chain runs unauthenticated end to end. 6.8.x sites still need the injection fix, but the batch-route bypass that makes it reachable without a login doesn't exist on that branch.

Given the severity, WordPress.org enabled forced updates via the auto-update system for affected versions — but don't take that as guaranteed. Confirm the version actually running in wp-admin rather than assuming the background update landed, especially on sites with auto-updates disabled or version-controlled deployments.

What we're seeing on the exploit side

Public reporting already points to activity: VulnCheck noted a report of exploitation of the RCE chain within hours of disclosure, and a working proof of concept is reportedly public on GitHub as of July 18. That's a short window between disclosure and weaponization, even by this year's standards.

On our own sensors, over the disclosure weekend:

• Requests blocked: +2,198,884
• Unique source IPs observed: +1000

Top source IPs we saw hitting the batch endpoint pattern:

‍

‍

‍

We'll keep this list updated as the picture firms up over this week.

What Monarx did

ThreatShield's detection logic for anomalous REST batch requests, unauthenticated writes into core query parameters, and post-exploitation webshell drops was already active in production ahead of Friday's disclosure, which means Monarx customers had behavioral coverage for this exploitation pattern before the official WordPress patch published.

That said, ThreatShield is a compensating control during the exposure window, not a substitute for the patch. Update regardless of your Monarx coverage. Same as we said with Copy Fail and GhostLock: we can catch the foothold and the post-exploitation artifacts, but we can't patch WordPress core for you, and a site that's already been compromised through this chain needs a real look at what an attacker did with database access and any admin credentials recovered not just a malware sweep.

What to do

1. Update WordPress to 7.0.2 (or 6.9.5 / 6.8.6 on older branches) immediately. Verify the running version rather than trusting the forced auto-update reached the instance.
2. If you can't patch yet, block both /wp-json/batch/v1 and ?rest_route=/batch/v1 at the WAF layer — both paths, or the block is incomplete.
3. Disable unauthenticated REST API access entirely if the site doesn't need it for integrations.
4. Watch for webshells and anomalous admin logins in the days following disclosure. Credential cracking from a dumped database is part of the documented attack path, so a clean file scan isn't the whole story if credentials were already exposed.

We're here to help

If you're a Monarx customer and want to check your current coverage status for WP2Shell-pattern detections, reach out to your account team or contact us directly. If you're not a customer and you're running WordPress at any scale, this is a reasonable moment to find out what's actually hitting your REST API.

‍

We'll keep tracking what surfaces next.

‍