New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code

A Critical Flaw in WordPress Core

A new WordPress core flaw, dubbed wp2shell, has been discovered, allowing unauthenticated attackers to run code on a WordPress site. The bug is in core, making a bare install with zero plugins exploitable. This means that even a default install with no plugins is vulnerable to the attack.

The flaw was found by Adam Kues at Assetnote, Searchlight Cyber's attack surface management arm, and reported through WordPress's HackerOne program. The technical details of the flaw are being kept under wraps, and a checker has been set up at wp2shell.com to allow site owners to test their own instance.

WordPress has released 6.9.5 and 7.0.2 to fix the issue, which affects two ranges of versions: 6.9.0 through 6.9.4, fixed in 6.9.5, and 7.0.0 through 7.0.1, fixed in 7.0.2. The forced push to update sites that have auto-updates enabled has been done, but it's unclear whether sites that have turned off auto-updates will receive the update.

The flaw is described by WordPress 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, but it 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, having been shipped since 5.6 in November 2020 and documented publicly ever since. However, 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, Searchlight offers three mitigation options, all of which are stopgaps until you update: At a WAF, block both /wp-json/batch/v1 and rest_route=/batch/v1. 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.