Patchstack has published a useful, slightly uncomfortable timeline of the recent WordPress core RCE chain: real exploitation attempts started roughly 90 minutes after WordPress 7.0.2 was released. In the days after disclosure, Patchstack says it blocked more than 65,000 attempts from over 1,500 unique IP addresses, aimed at unpatched vulnerable sites.
For site owners, the practical message is not subtle: if a vulnerable WordPress site was left waiting for a convenient maintenance window, attackers may already have had plenty of time to test it.
Key Takeaways
- Exploitation attempts started about 90 minutes after WordPress 7.0.2 was released.
- The vulnerability chain affects WordPress 6.8 through 7.0.1, depending on the CVE.
- Fixed versions are WordPress 7.0.2, 6.9.5 and 6.8.6.
- Patchstack blocked more than 65,000 attempts from over 1,500 IP addresses.
- WAF rules that only check the URL may miss REST batch attacks hidden in POST bodies.
Which WordPress versions are affected
The chain combines two WordPress core issues. CVE-2026-60137 is a facilitated SQL injection in WP_Query through the author_exclude / author__not_in parameter, affecting WordPress 6.8 through 7.0.1. CVE-2026-63030 is a REST API batch endpoint route and handler confusion issue affecting WordPress 6.9 through 7.0.1.
Patchstack says both issues are fixed in WordPress 7.0.2, 6.9.5, and 6.8.6. It also notes that older branches such as 6.1 and 6.2 are not affected by this specific chain because the vulnerable code was introduced later.
What the attacks looked like
According to Patchstack, 97% of blocked attempts targeted the REST batch endpoint, usually through /?rest_route=/batch/v1 or /wp-json/batch/v1. Attackers also tried variants such as /index.php?rest_route=/batch/v1, /wp/?rest_route=/batch/v1, and /blog/?rest_route=/batch/v1.
Around three-quarters of the blocked requests carried SQL injection attempts in the author_exclude parameter. The payloads used the usual scanner tricks: mixed-case keywords, inline comments, MySQL conditional comments, URL encoding, boolean probes, and time-based probes.
Why this can turn into a full site takeover
The SQL injection alone is not described as a direct write-anything-you-want bug. The problem is the chain. Patchstack says the public exploit, circulating as a tool nicknamed wp2shell, can use the REST batch confusion and SQL injection together to reach administrator account creation and then remote code execution on unprotected WordPress 6.9 to 7.0.1 sites.
In plain English: this is not just someone reading a bit of data and going home. On an exposed affected site, the end state can be a new attacker-controlled admin account, a malicious plugin or webshell, and code execution.
The WAF detail many site owners will miss
Patchstack also points out a nasty mitigation problem. Many early WAF rules looked only for batch/v1 in the URL, because that is how the public proof-of-concept requests were shaped. But WordPress can read rest_route=/batch/v1 from the POST body before the query string.
That means a request can be sent as a plain POST to the site root, with the REST route hidden in the body. A URL-only rule may see nothing suspicious. Patchstack says it later observed exploitation attempts using these POST-body delivery shapes, and other hosts reported similar bypass patterns during coordinated disclosure.
What to check now
If you run or maintain WordPress sites, update affected installations to WordPress 7.0.2, 6.9.5, 6.8.6, or newer. Then do the boring checks that often matter most: look for unfamiliar administrator accounts, unexpected plugins, and stray PHP files in the uploads directory.
Logs should be checked for access to the REST batch endpoint in all forms, not only obvious URL patterns. That includes /wp-json/batch/v1, ?rest_route=/batch/v1, and rest_route=/batch/v1 appearing in POST bodies. If you rely on WAF rules, confirm they inspect the same places WordPress actually reads from, not only the address bar version of the request.
Source
This summary is based on Patchstack’s incident write-up. For the full timeline, payload details, and mitigation notes, check the original source: Patchstack Blog.
Frequently Asked Questions
Which WordPress versions fix this core RCE chain?
Patchstack says the issues are fixed in WordPress 7.0.2, 6.9.5, and 6.8.6. Site owners should update affected installations to one of those versions or newer.
Which WordPress versions are affected by the vulnerabilities?
CVE-2026-60137 affects WordPress 6.8 through 7.0.1, while CVE-2026-63030 affects WordPress 6.9 through 7.0.1. Patchstack says older branches such as 6.1 and 6.2 are not affected by this specific chain.
How fast did attackers start exploiting the patched WordPress bugs?
Patchstack reports that real exploitation attempts appeared roughly 90 minutes after WordPress 7.0.2 was released. In the following days, it blocked more than 65,000 attempts from over 1,500 unique IP addresses.
Why can this vulnerability chain lead to site takeover?
Patchstack says the public exploit nicknamed wp2shell can combine the REST batch confusion and SQL injection to create an administrator account and reach remote code execution on unprotected WordPress 6.9 to 7.0.1 sites.
Why are URL-only WAF rules not enough for this attack?
Patchstack says WordPress can read rest_route=/batch/v1 from the POST body before the query string. That means requests can target the REST batch endpoint even when batch/v1 does not appear in the URL.