wp2shell: Unauthenticated WordPress RCE and How to Block It
wp2shell is an unauthenticated remote code execution chain in WordPress core that combines two bugs, CVE-2026-63030 and CVE-2026-60137. WordPress fixed it on 17 July 2026 in versions 7.0.2, 6.9.5 and 6.8.6, and attackers began exploiting it within hours.
Update WordPress core first, because only the core patch removes the bug. ReportedIP Hive blocks the attack pattern on every plan, the free plan included, since version 2.1.25 from 19 July 2026. That covers sites that are not patched yet and variants of the attack.
What is wp2shell?
wp2shell is the name for two WordPress core vulnerabilities used together. Neither one gives an attacker code execution on its own. Chained, they take an anonymous request all the way to a new administrator account.
- CVE-2026-60137 (SQL injection). WordPress does not properly sanitise the
author__not_inparameter ofWP_Query. In the REST API it is fed byauthor_exclude. On its own, the bug is only reachable when a plugin or theme passes untrusted input to that parameter. - CVE-2026-63030 (REST batch route confusion). The batch endpoint
/wp-json/batch/v1validates and dispatches sub-requests in two separate loops. A sub-request with a malformed path knocks the two lists out of step, so a request runs under the handler of a different route. That lets the injectable parameter reach the posts query without a login.
Which WordPress versions are affected?
The route confusion was introduced in WordPress 6.9, so the full chain only works on 6.9 and 7.0. The SQL injection alone reaches back to 6.8. The official WordPress 7.0.2 release notes list the fixes.
| Branch | Affected | Fixed in | Full chain |
|---|---|---|---|
| 7.0 | 7.0.0 to 7.0.1 | 7.0.2 | Yes |
| 6.9 | 6.9.0 to 6.9.4 | 6.9.5 | Yes |
| 6.8 | 6.8.0 to 6.8.5 | 6.8.6 | No |
WordPress.org pushed forced updates through the auto-update system to affected sites. Sites with auto-updates turned off, or with a host that holds back core updates, stay exposed until someone updates them by hand. CISA added both CVEs to its catalogue of known exploited vulnerabilities on 21 July 2026, and the NVD entry for CVE-2026-63030 tracks the details.
How does the attack reach a shell?
Every step of the chain is a POST request to the batch endpoint, sent either to /wp-json/batch/v1 or to ?rest_route=/batch/v1. Inside the request, a malformed sub-request path causes the route confusion and a nested batch carries the SQL injection. The injection reads data out of the database, and the following requests create a new administrator through the REST user route. With an admin account, uploading a plugin gives the attacker code execution on the server.
Patchstack saw the first exploitation attempts roughly 90 minutes after the 7.0.2 release. By 22 July 2026 it had blocked more than 65,000 attempts from over 1,500 IP addresses, 97 percent of them aimed at the batch endpoint.
How many wp2shell attacks does ReportedIP see?
Our honeypot servers have recognised wp2shell requests as their own attack type since 5 September 2026. Between 5 and 28 September 2026 they filed 601 reports against 347 distinct IP addresses, covering 3,196 logged requests. 580 of the 601 reports contained the nested batch that the attack depends on. On 29 September 2026, 51 of the 347 addresses had a confidence score of 75 or higher, the threshold for the ReportedIP blacklist.
The attack is still running more than two months after the patch. Scanners keep testing every WordPress site they find, because some sites are still unpatched. The May to July attack report covers the weeks around the disclosure.
How does ReportedIP Hive block wp2shell?
The Hive firewall checks every request from visitors who are not logged in. It looks at the URL, the user agent and the request body before WordPress handles the request. With Extended Protection turned on, the check runs even before WordPress loads. Since version 2.1.25 the firewall reads the body both raw and URL-decoded, so an encoded payload inside a JSON batch is visible to the same signatures.
Version 2.1.25 added two rules that target the structure of the attack rather than a single keyword:
waf_rest_batch_desyncmatches the malformed sub-request paths that the batch parser rejects, such as several leading slashes or a scheme with an empty host. Swapping one malformed path for another does not get past it.waf_rest_batch_nestedmatches a sub-request whose body is itself a batch. The attack cannot drop this nesting without losing the route confusion.waf_sqli_unionalready blocked theUNION SELECTinjection that the admin-creation step relies on before 2.1.25.
All three rules belong to the free baseline that ships inside the plugin, so they work on every plan and without a rule sync. Sites with Priority Sync on the Professional plan receive the same rules through the signed ruleset delivery and can add the deeper signatures of paranoia level 2 and 3. In our test suite, normal batch calls, protocol-relative URLs and absolute URLs pass both batch rules. The WordPress firewall guide explains the rule levels, exceptions and the block page.
What should WordPress admins do now?
- Check the core version on every site and update to 7.0.2, 6.9.5 or 6.8.6 or later.
- Look for administrator accounts that nobody on your team created, and for plugins you did not install.
- Update ReportedIP Hive to the current version from Plugins, or click Check for updates in the plugin row.
- On Professional sites, click Sync now on the rules page to pull the current ruleset right away.
The firewall documentation describes the rule delivery and how to allow a request that the firewall blocked by mistake.
Frequently asked questions
Does ReportedIP Hive replace the WordPress core update?
Hive does not replace the core update, because only the patch removes the bug. The firewall blocks the request pattern before it reaches the vulnerable code. That protects a site during the time until it is patched and catches variants of the attack. Every site should still run WordPress 7.0.2, 6.9.5 or 6.8.6 or later.
Are free Hive sites protected against wp2shell?
Free sites are protected as soon as they run Hive 2.1.25 or later. Both batch rules and the UNION SELECT rule are part of the baseline that ships inside the plugin, so no paid plan and no rule sync is needed. The Professional plan adds deeper signatures and daily rule updates on top of that baseline.
Will the new rules block legitimate REST batch requests?
Normal batch requests pass, because the rules only match malformed sub-request paths and a batch nested inside a sub-request body. Batch calls from the block editor do not have either shape. If a plugin on your site sends one, you can add an exception for that rule from the Hive event log.