WordPress Core Flaw Lets Anonymous Attackers Execute Code on Millions of Sites

A critical two-bug chain in WordPress core allows unauthenticated attackers to execute remote code on any default WordPress installation running versions 6.9 or 7.0 — no plugins required. WordPress shipped emergency patches on July 18, 2026.

The vulnerability, dubbed wp2shell, represents one of the most serious flaws ever discovered in WordPress core. With over 500 million websites running WordPress globally and a working proof-of-concept exploit now publicly available on GitHub, site owners face a narrowing window to patch before mass exploitation begins.

Two CVEs Chain Into Unauthenticated Remote Code Execution

wp2shell is not a single flaw — it is two distinct vulnerabilities that attackers chain together to achieve full code execution from a single anonymous HTTP request.

CVE-2026-63030 is a REST API batch-route confusion bug. WordPress's /wp-json/batch/v1 endpoint processes multiple sub-requests in one call and tracks them in two parallel arrays. When an error occurs in one sub-request, those arrays fall out of step by one position. That misalignment allows a request to run under a different request's handler, effectively walking past the endpoint's allow-list entirely.

CVE-2026-60137 is a SQL injection vulnerability buried in WordPress core's WP_Query function. Specifically, the author__not_in parameter fails to validate whether its input is an array. Pass it a string instead, and the type check is skipped, dropping raw attacker-controlled input directly into the database query.

Chained together, the batch-route confusion delivers unauthenticated attacker input into the vulnerable SQL parameter — turning a bounded database flaw into full remote code execution with zero preconditions.

Adam Kues at Assetnote, the attack surface management arm of Searchlight Cyber, discovered the batch-route bug and reported it through WordPress's HackerOne program. His published writeup states the attack has "no preconditions and can be exploited by an anonymous user." The SQL injection was reported separately by researchers identified as TF1T, dtro, and haongo.

Why This Chain Is Particularly Dangerous

What makes wp2shell unusually threatening is the combination of factors converging at once: a default-install attack surface, zero authentication requirements, and a working public exploit. Each of those conditions alone raises risk — together, they create the conditions for industrialised mass exploitation. Understanding why cybersecurity vulnerabilities at this scale demand immediate organisational attention has never been more relevant for WordPress site owners and the teams responsible for managing them.

Version Exposure and Patch Status

Not Every Version Faces the Same Risk

The two bugs do not affect identical version ranges, and that distinction matters enormously for site owners assessing their exposure.

The SQL injection reaches back to WordPress 6.8. The batch-route confusion that elevates it to unauthenticated RCE only exists from version 6.9 onward, which shipped December 2, 2025. The affected version ranges and their corresponding patches are:

• 6.8.0 through 6.8.5: SQL injection only — fixed in 6.8.6
• 6.9.0 through 6.9.4: Full RCE chain — fixed in 6.9.5
• 7.0.0 through 7.0.1: Full RCE chain — fixed in 7.0.2
• 7.1 beta2 carries both fixes

A site running 6.8 cannot be exploited for remote code execution through this specific chain. However, the SQL injection exposure remains real and warrants patching regardless.

WordPress pushed 6.9.5 and 7.0.2 through its forced auto-update system. The company has not confirmed whether that forced push reaches sites that disabled auto-updates. Owners should verify their actual running version rather than assume the patch landed automatically.

The Object Cache Condition

One environmental condition further narrows the blast radius for RCE specifically. Cloudflare, which deployed WAF rules alongside the disclosure, noted the code-execution path only functions when the site is not running a persistent object cache such as Redis or Memcached. A default WordPress install has no such cache, meaning default-install exposure stands fully.

Sites using a persistent object cache may sit off this particular execution path — but that is an incidental side effect, not a fix, and it does not address the SQL injection at all. Site owners should not treat cache configuration as a mitigation strategy.

Understanding the CVE Scoring Discrepancy

WordPress's own advisory rates the RCE chain Critical. The CVE record scores it 7.5 — only High — because the scoring methodology rewards the SQL injection's direct database reach and treats the route confusion as a parsing flaw in isolation. The injection scores above 9.1, Critical.

This discrepancy is worth understanding clearly: automated vulnerability dashboards pulling on a single CVE score will present an incomplete picture of the actual risk. Site owners should track both CVE-2026-63030 and CVE-2026-60137 rather than rely on either label alone.

Exploit Availability, Threat Landscape, and Immediate Actions

The Exploit Is Public and Scanners Are Activating

The disclosure timeline compressed quickly once patches shipped. WordPress releasing the update effectively published the map to the bug — researchers read the changed files, reconstructed the full mechanism, and posted a working proof-of-concept to GitHub within a day. Searchlight's decision to hold its own technical writeup became moot almost immediately.

Rapid7 confirmed that authenticated vulnerability checks for InsightVM and Nexpose will be available July 20. The flaw has not yet appeared on CISA's Known Exploited Vulnerabilities catalog, which requires confirmed in-the-wild exploitation. As of July 18 no active exploitation had been reported.

That comfort deserves scrutiny. Mass exploitation of WordPress vulnerabilities is effectively an industrialised operation. Before its own infrastructure was compromised in June, one threat group known internally as WP-SHELLSTORM used a separate caching-plugin flaw to compromise more than 17,000 sites — a bug that was already patched and only worked on non-default configurations. wp2shell is patched, public, and works on default configurations. The gap between "no confirmed exploitation" and "active mass exploitation" in scenarios like this is historically measured in days, not weeks.

For site owners who want broader context on hardening their installations against this class of threat, the fundamentals of securing a WordPress website against exploitation remain highly relevant alongside any emergency patching response.

Mitigations for Sites That Cannot Update Immediately

For sites that cannot update immediately, Searchlight recommends blocking both /wp-json/batch/v1 and rest_route=/batch/v1 at the WAF level. Both paths must be blocked since a rule covering only one leaves the other open. Cloudflare's managed WAF now blocks the chain for sites behind it. Disabling unauthenticated REST API access entirely is a more aggressive option but may break legitimate integrations.

All mitigations are stopgaps — the patch remains the only complete fix.

It is also worth noting that the broader principles of maintaining robust website security as an ongoing operational practice — rather than a reactive one — are precisely what reduce exposure windows when critical vulnerabilities like wp2shell emerge without warning.

How Site Owners Should Act on This Information

1. Log into your WordPress dashboard today and confirm you are running 6.8.6, 6.9.5, 7.0.2, or later — do not assume auto-update delivered the patch
2. If you manage WordPress behind Cloudflare or another WAF, verify that WAF rules blocking batch/v1 requests are active while you coordinate your update window
3. If your organisation runs WordPress at scale, add CVE-2026-63030 and CVE-2026-60137 to your vulnerability tracking immediately and prioritise Rapid7 authenticated scans once checks land July 20