New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code

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.