WordPress does not force-push updates onto sites that have opted out of them. Doing so overrides an administrator's explicit choice, and the project treats it as a measure of last resort.
On July 17, it did exactly that, shipping versions 7.0.2 and 6.9.5 and enabling forced auto-updates across affected installs to close a pre-authentication remote code execution flaw in core. That single decision says more about the bug's severity than any advisory has.
Tracked publicly as wp2shell, the vulnerability requires no authentication, no plugins, and no non-default configuration. An anonymous HTTP request against a stock install is sufficient to achieve code execution on the underlying server — the worst outcome a web application can offer an attacker, reachable by anyone who can send a request.
The flaw was found by Adam Kues of Assetnote, the attack-surface-management arm of Searchlight Cyber, and reported through WordPress's HackerOne program.
In its disclosure, the firm states the attack has "no preconditions and can be exploited by an anonymous user." Searchlight is deliberately withholding technical details to give defenders room to patch, and has instead published a checker at wp2shell.com so WordPress admin can test their own sites.
At the time of writing, the site was unreachable with a 404 error.
Two bugs, chained
wp2shell is not one vulnerability but two, and their relationship is what makes it dangerous.
The first, CVE-2026-60137, is an SQL injection in the author__not_in parameter of WP_Query, the core class that builds nearly every database query WordPress issues. It carries a CVSS base score of 9.1 (Critical) and is classified as CWE-89. It reaches back to WordPress 6.8, the widest exposure of the two. On its own, it is a data-integrity problem — serious, but bounded by what the database can be coerced into returning.
The second, CVE-2026-63030, is a REST API batch-route confusion issue — an interpretation conflict (CWE-436) in the /wp-json/batch/v1 endpoint that has shipped with WordPress since version 5.6 in 2020. Its base score is 7.5 (High). This is the component that turns a confined injection into full compromise: routed through the batch endpoint on WordPress 6.9 and later, the SQL injection escalates to remote code execution.
There is a notable inconsistency in how the two are ranked. WordPress's GitHub advisories label the batch-route bug "Critical" and the injection "Moderate"; the CVSS scores assigned through NVD invert that order, making the injection the more critical of the pair. The disagreement reflects a genuine difference in what each party is measuring — chain potential versus standalone impact —, but for a site operator, it is academic. Both are patched in the same release, and the combined result is server compromise from an unauthenticated request.
Scale, and the limits of the scale
Searchlight notes that WordPress runs on more than 500 million websites, and the platform accounts for roughly 40 percent of the web overall. Those figures describe the install base, not the exposed population, and the distinction matters.
The vulnerable code path only exists from WordPress 6.9 onward, and 6.9 shipped on December 2, 2025. Every affected site is therefore running a release less than eight months old — a meaningful constraint, though one offset by how aggressively WordPress users tend to stay current.
The affected and fixed versions are precise:
- 6.9.0 – 6.9.4 are vulnerable to the RCE; fixed in 6.9.5.
- 7.0.0 – 7.0.1 are vulnerable to the RCE; fixed in 7.0.2.
- 7.1 beta is affected; fixed in 7.1 beta2.
- 6.8.x is exposed only to the SQL injection, not the RCE chain; fixed in 6.8.6.
Anything older than 6.8 is unaffected by either issue.
Response
The priority is unambiguous: update to 7.0.2, or to 6.9.5 on the 6.9 branch. Operators should verify the running version in the dashboard rather than assume the forced push landed — WordPress has not confirmed whether the mechanism reaches sites with background updates fully disabled, and a forced update is only as good as the sites it actually touches.
Where an immediate update is not possible, every mitigation Searchlight offers reduces to the same principle: deny anonymous callers access to the batch endpoint. At the WAF layer, that means blocking both /wp-json/batch/v1 and the equivalent querystring route rest_route=/batch/v1 — a rule covering only the path leaves the second route open.
Alternatively, unauthenticated REST access can be disabled outright, or a must-use plugin can reject anonymous /batch/v1 requests at rest_pre_dispatch. Each carries a cost to legitimate REST traffic and integrations, and none is a substitute for the patch.
The window is closing on its own
No exploitation had been observed as of July 18, and with technical details still private, broad scanning has yet to materialize. That quiet is temporary.
WordPress core is open source; releases 7.0.1 and 7.0.2 both sit in the public archive, and comparing two versions is the standard route by which a silent patch is reverse-engineered into a working exploit.
Searchlight has demonstrated the pattern itself: when Drupal patched an analogous anonymous SQL injection in May, the firm converted the public fix into a same-day analysis with two functioning proofs of concept.
That is the structural bind of open-source security — a project cannot distribute the fix without also distributing the diff that points to the flaw. The only remaining variable is time: whether the patch reaches a given site before someone else reads the change.
WordPress spent its most disruptive update mechanism to weigh that race in defenders' favor. Confirming the version on your own site is the last step you can't take.