An anonymous HTTP request can run code on a WordPress site. The bug is in the core, so a bare install with zero plugins can be exploited.
Every 6.9 and 7.0 site was in range until Friday, when WordPress shipped 6.9.5 and 7.0.2 and enabled forced updates through its auto-update system.
Adam Kues at AssetNote, the attack surface management arm of Searchlight Cyber, found the flaw and reported it through WordPress’s HackerOne program. Articles published under the name wp2shellsays the attack “has no prerequisites and can be exploited by an unknown user.”
The company is currently mulling over the technical details and has instead put up a checker on wp2shell.com so owners can test their own instance.
WordPress released 6.9.5 and 7.0.2 on July 17, 2026, turning off pre-auth RCE in core that an anonymous request could trigger against the default install of the plugin. Two categories are affected:
- From 6.9.0 to 6.9.4, fixed in 6.9.5
- From 7.0.0 to 7.0.1, fixed in 7.0.2
WordPress hasn’t said whether forced pushes extend to sites that turn off auto-updates. Instead of assuming that’s what you’re actually driving, check it.
7.1 beta2 has a similar fix. Sites on 6.8 are still waiting for the update, but 6.8.6 is home to a second SQL injection bug in the same round, reported by a different team.
Searchlight’s post estimates that more than 500 million websites run WordPress. That figure is the total install base, not the vulnerable population: the flawed code has only existed since 6.9, and 6.9 shipped on December 2, 2025. So each affected site is running a release less than eight months old, and nor does the advisory specify how many sites it covers.
WordPress is more specific about the bug category than the researcher. In its release post Kues’ discovery is described as “a REST API batch-route confusion and SQL injection issue that leads to remote code execution.” The release covers one critical and one high severity flaw, and WordPress doesn’t say which one.
The versions page lists three files touched by 7.0.2, which cover both improvements: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php, and /wp-includes/rest-api.php. Batch endpoint is not new. WordPress shipped this with 5.6 in November 2020 and has publicly documented the request format since then. Nothing published so far suggests what was changed in 6.9 to open it.
None of the advisories have a CVE ID or CVSS score, and as of July 18, no CVE records were reported. CVE-keyed scanners and inventories will not flag it, and CISA requires a CVE before adding anything to the CVE catalog. Instead track it by version number.
If you can’t update today
Every mitigation Searchlight offers comes with a way to keep anonymous callers away from batch endpoints. Three options, they all stop until you update, and they are all capable of breaking legitimate integrations:
- On WAF, block both /wp-json/batch/v1 and rest_route=/batch/v1. The firm clearly says both have to go, as the rule covering only the /wp-json path leaves the query-string path open.
- Disable the WP REST API, which eliminates unauthenticated REST access.
- A small drop-in plugin that publishes and rejects anonymous /batch/v1 requests on rest_pre_dispatch.
No attempts of exploitation have been reported as of July 18. There’s no CVE to tag and no public signature to match, no one’s really looking yet.
Large-scale exploitation of WordPress is now an industry. Before its servers were leaked in June, a caching-plugin flaw alone had taken the WP-SHELLSTORM crew down to more than 17,000 sites by their count. That bug was already public, already patched, and only worked on a non-default setting.
When Drupal patched an unknown SQL injection in its core in May, Searchlight tore down that public fix with two working proofs of concept the same day. That was someone else’s bug and someone else’s patch, and nothing forces a company to do the same to itself. But it took a day, and the same people who set that clock are now betting that silence buys the defenders time.
WordPress core is open source, and both 7.0.1 and 7.0.2 are in the public release repository, so the comparison is available to anyone who wants it. This is a compulsion for every open-source project: You can’t ship a fix without mapping bugs to it, and the only lever left is how fast the patch reaches sites before anyone reads it.
WordPress pulled that lever on Friday. Traffic against batch/v1 will be visible when attackers arrive, and WordPress’s own version statistics will show whether the patch got there first or not. Only a number of them ever make news.
