Unauthenticated Attackers Can Execute Code via New WordPress Flaw

An anonymous web request can now achieve remote code execution on millions of WordPress sites, thanks to a newly disclosed vulnerability chain in the core software itself. No plugins are required, meaning even a bare installation is exploitable. Every site running WordPress 6.9 or 7.0 was at risk until Friday, when the project released emergency patches (6.9.5 and 7.0.2) alongside a forced auto-update mechanism.

The attack, dubbed wp2shell, is actually a combination of two distinct flaws, each now assigned their own CVE identifier. CVE-2026-63030 covers a REST API batch-route confusion, while CVE-2026-60137 is a SQL injection vulnerability in WordPress core. When chained together, these bugs allow an unauthenticated attacker to escalate from a simple HTTP request to full code execution on the server.

Since Friday, the full technical mechanism has been published online, and a working proof-of-concept exploit has appeared on GitHub. The batch-route flaw was discovered by Adam Kues at Assetnote, the attack surface management arm of Searchlight Cyber, and reported through WordPress’s HackerOne program. The SQL injection was reported separately by researchers TF1T, dtro, and haongo.

Searchlight’s writeup, published under the wp2shell name, describes the attack as having “no preconditions” and being exploitable by any anonymous user. While Searchlight has held back its own detailed technical analysis, the cat is out of the bag: the patch is public, and other security researchers have already reverse-engineered it.

Understanding the version split is critical. The two bugs do not affect the same versions, which determines your actual exposure. The SQL injection goes back to version 6.8. The batch-route confusion, which turns a bounded injection into unauthenticated RCE, only exists from 6.9 onward.

Here is the breakdown of affected ranges:

• 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

Version 7.1 beta2 includes both fixes. Sites on 6.8 are not exploitable for full RCE through this chain, which is why the 6.8.6 patch addresses only the injection.

A critical question remains: Has the forced update reached sites that disabled auto-updates? WordPress has not confirmed this. Site owners should check their actual running version rather than assume the patch landed.

Searchlight estimates that over 500 million websites run WordPress, but that figure represents the total install base, not the exposed set. The RCE chain only exists from version 6.9, which shipped on December 2, 2025. This means every site vulnerable to code execution is running a release less than eight months old. No advisory states how many sites that actually is.

The chain relies on two small but devastating mistakes. The SQL injection lives in `WPQuery`’s `authornotin` parameter. When an attacker passes a string instead of an array, the validation check that expects an array is skipped entirely, dropping the raw value directly into the database query.

Reaching that parameter without authentication is the batch endpoint’s job. WordPress’s `/wp-json/batch/v1` route processes several sub-requests in a single call, tracking them in two parallel arrays. A single error in one sub-request knocks the arrays out of sync by one position, causing a subsequent request to execute under a different request’s handler.

Nested, that confusion bypasses the endpoint’s allow-list and lands the attacker’s input in the vulnerable query, completely unauthenticated. The batch endpoint has existed since version 5.6 in 2020, but the specific confusion that enables this attack is new to 6.9.

The CVSS scores deserve close scrutiny. WordPress’s own advisory rates the RCE chain as Critical, yet the CVE record scores it at only 7.5 (High). The impact metrics only credit data access, not the integrity or availability loss you would expect from code execution. Meanwhile, the SQL injection alone scores higher than 9.1 (Critical).

The bug everyone is calling a critical RCE is, by its own number, the lesser of the two flaws. The scoring rewards the injection’s direct reach into the database and treats the route confusion on its own as a mere parsing flaw. Track both CVEs, not the label on either.

One condition narrows the blast radius. The code-execution path works only when the site is not running a persistent object cache. Cloudflare, which shipped WAF rules alongside the disclosure, confirmed this. A default WordPress install has no such cache, so default-install exposure remains full.

Sites fronting WordPress with Redis or Memcached as a persistent object cache may be off this particular path, but that is a side effect, not a fix, and it does not cover the underlying SQL injection.

With CVE IDs now assigned, the scanners are finally catching up. Rapid7 says authenticated checks for InsightVM and Nexpose will land on July 20. The flaw is not yet on CISA’s KEV catalog, which requires confirmed exploitation, and none has been reported as of July 18. That comfort is thinner than it reads.

Mass exploitation of WordPress is a mature industry now. Before its server leaked in June, one caching-plugin flaw alone got the WP-SHELLSTORM crew into more than 17,000 sites by its own count. They used a bug that was already public, already patched, and only worked on a non-default setting. This one is public, patched, and works on the default setting.

If you cannot update today, every mitigation Searchlight offers comes down to keeping anonymous callers off the batch endpoint. All are stopgaps until you update, and all can break legitimate integrations:

• At a WAF, block both `/wp-json/batch/v1` and `rest_route=/batch/v1`. A rule covering only the `/wp-json` path leaves the query-string route open. Cloudflare says its managed WAF now blocks the chain for sites behind it.WordPress core is open source, and the release names the files it changed. That was always going to be enough. Searchlight held its write-up, but within a day, other researchers had read the patch, published the mechanism, and put an exploit on GitHub. That is the exact shape the disclosure was racing against.You cannot ship the fix without shipping the map to the bug. The only lever left is how fast the patch reaches sites before someone reads it, and WordPress pulled it hard on Friday.Now the exploit is public, and the update is still rolling. WordPress’s version stats will show how many sites took the patch; scan traffic against batch/v1 will show how many attackers came looking. Whichever curve is steeper decides how this one gets remembered.