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 enabled what it calls forced updates through its auto-update system.
Adam Kues at Assetnote, Searchlight Cyber’s attack surface management arm, found the flaw and reported it through WordPress’s HackerOne program. The writeup, published under the name wp2shell, says the attack has “no preconditions and can be exploited by an anonymous user.”
The firm is sitting on the technical details for now and has put up a checker at wp2shell.com instead, so owners can test their own instance.
WordPress released 6.9.5 and 7.0.2 on July 17, 2026, closing a pre-auth RCE in core that an anonymous request can trigger against a default install with no plugins. Two ranges are affected:
- 6.9.0 through 6.9.4, fixed in 6.9.5
- 7.0.0 through 7.0.1, fixed in 7.0.2
WordPress has not said whether the forced push reaches sites that turned auto-updates off. Check what you are actually running rather than assume it landed.
7.1 beta2 carries the same fix. Sites still on 6.8 have an update waiting too, but 6.8.6 is for the second SQL injection bug in the same round, reported by a different team.
Searchlight’s post estimates that over 500 million websites run WordPress. That figure is the total install base, not the vulnerable population: the flawed code only exists from 6.9 onward, and 6.9 shipped on December 2, 2025. So every affected site is running a release less than eight months old, and neither advisory says how many sites that covers.
WordPress is more forthcoming about the bug class than the researcher is. Its release post describes Kues’s finding as “a REST API batch-route confusion and SQL injection issue leading to Remote Code Execution.” The release covers one critical and one high severity flaw, and WordPress does not say which is which.
The version page lists the three files 7.0.2 touched, covering both fixes: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php, and /wp-includes/rest-api.php. The batch endpoint is not new. WordPress has shipped it since 5.6 in November 2020 and documented the request format publicly ever since. Nothing published so far explains what changed in 6.9 to open it.
Neither advisory carries a CVE ID or a CVSS score, and no CVE record had appeared by July 18. CVE-keyed scanners and inventories will not flag this one, and CISA needs a CVE before it can add anything to the KEV catalog. Track it by version number instead.
If you can’t update today
Every mitigation Searchlight offers comes down to keeping anonymous callers off the batch endpoint. Three options, all of them stopgaps until you update, and all of them capable of breaking legitimate integrations:
- At a WAF, block both /wp-json/batch/v1 and rest_route=/batch/v1. The firm is explicit that both have to go, because a rule covering only the /wp-json path leaves the query-string route open.
- Disable WP REST API, which kills unauthenticated REST access wholesale.
- A short drop-in plugin that publishes and rejects anonymous /batch/v1 requests at rest_pre_dispatch.
No exploitation attempt has been reported as of July 18. With no CVE to tag and no public signature to match, nobody is really looking yet.
Mass exploitation of WordPress is an 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. That bug was already public, already patched, and only worked on a non-default setting.
When Drupal patched an anonymous SQL injection in its own core in May, Searchlight turned that public fix into a same-day teardown with two working proofs of concept. That was someone else’s bug and someone else’s patch, and nothing obliges the firm to do the same to its own. But a day is what it took, and the people who set that clock are the ones now betting silence buys defenders time.
WordPress core is open source, and 7.0.1 and 7.0.2 both sit in the public release archive, so the comparison is available to anyone who wants it. That is the bind for every open-source project: you cannot ship the fix without shipping the map to the bug, and the only lever left is how fast the patch reaches sites before someone reads it.
WordPress pulled that lever on Friday. Traffic against batch/v1 will show when the attackers arrive, and WordPress’s own version stats will show whether the patch got there first. Only one of those numbers ever makes the news.
