wp2shell

An anonymous HTTP request can run code on a WordPress site. The bug is in core, so a bare install with zero plugins is exploitable. Every 6.9 and 7.0 site was in range until Friday, when WordPress shipped 6.9.5 and 7.0.2 and pushed them through forced auto-updates. Since then the full mechanism has been published and a working proof-of-concept has gone up on GitHub, so the window between disclosure and mass scanning is effectively closed.

wp2shell is two bugs, not one. CVE-2026-63030 is a REST API batch-route confusion, found by Adam Kues at Assetnote (Searchlight Cyber's attack surface management arm) and reported through WordPress's HackerOne program. CVE-2026-60137 is a SQL injection in core, reported separately by TF1T, dtro, and haongo. Chained, they take an anonymous request all the way to code execution. Searchlight's writeup states the attack has "no preconditions and can be exploited by an anonymous user."

Who is exposed to what

The two bugs do not reach the same versions, and that split is the whole story of your exposure. The SQL injection goes back to 6.8. The batch-route confusion, the half that turns a bounded injection into unauthenticated RCE, only exists from 6.9 onward. So a 6.8 site is not exploitable for RCE through this chain, which is exactly why 6.8.6 patches the injection alone.

• 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

Searchlight estimates over 500 million websites run WordPress, but that is the total install base, not the exposed set. The RCE chain only exists from 6.9, which shipped December 2, 2025. Every site on the code-execution path is running a release less than eight months old, and no advisory says how many that is. WordPress has not confirmed whether the forced push reaches sites that turned auto-updates off, so check what you are actually running rather than assume it landed.

How the chain works

The chain is two small mistakes stacked. The injection lives in WP_Query's author__not_in parameter: hand it a string instead of an array and the check that expects an array is skipped, dropping the raw value into the query. Reaching that parameter without a login is the batch endpoint's job. WordPress's /wp-json/batch/v1 route runs several sub-requests in one call and tracks them in two parallel arrays; an error in one sub-request knocks the arrays out of step by one, so a request executes under a different request's handler. Nested, that confusion walks past the endpoint's allow-list and lands attacker input in the vulnerable query, unauthenticated. The batch endpoint has shipped since 5.6 in 2020; the confusion that abuses it is new to 6.9.

The one condition that narrows the blast radius

The code-execution path works only when the site is not running a persistent object cache, per Cloudflare, which shipped WAF rules alongside the disclosure. A default install has no such cache, so default-install exposure stands. A site 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 nothing for the SQL injection. With CVE IDs assigned, scanners can finally see it: Rapid7 says authenticated checks for InsightVM and Nexpose land July 20. It is not 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 an industry. Before its server leaked in June, the WP-SHELLSTORM crew got into more than 17,000 sites off a single caching-plugin flaw 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 can't 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, so validate before you deploy them wide.

• 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's managed WAF now blocks the chain for sites behind it.
• Disable the WP REST API, which kills unauthenticated REST access wholesale.
• Deploy Searchlight's short drop-in plugin that rejects anonymous /batch/v1 requests at rest_pre_dispatch.