On July 17, 2026, WordPress quietly patched two vulnerabilities that, individually, look unremarkable. CVE-2026-63030 carries a CVSS score of 7.5. CVE-2026-60137 scores 9.1 but requires conditions that shouldn’t be reachable by an unauthenticated attacker. Chained together, they produce something WordPress site owners can’t afford to shrug off: unauthenticated remote code execution. Researchers have named the chain wp2shell, and on July 21 CISA added CVE-2026-63030 to its Known Exploited Vulnerabilities catalog, confirming it’s already being used in the wild.
WordPress runs roughly 500 million websites, close to half of everything on the internet. A working RCE chain against the core platform is the kind of bug that can lead to massive damage if not quickly addressed. As we wrote about in the 1H 2026 ECHO report, modern threat actors don’t necessarily have to be more skilled, they just need to exploit vulnerabilities faster than you can patch them.
The affected versions
- 6.8.0 – 6.8.5
- 6.9.0 – 6.9.4
- 7.0.0 – 7.0.1
- 7.1 beta
How the chain works
wp2shell combines a REST API routing bug with an SQL injection that’s normally unreachable. WordPress’s batch endpoint (/wp-json/batch/v1) lets a client bundle multiple API calls into a single request. Internally, the handler builds two parallel arrays as it processes each sub-request: one tracking validation status, the other tracking which handler should process each request. The bug is that a malformed sub-request updates the validation array but never touches the handler-matching array, so the two arrays fall out of sync.
An attacker can exploit that desync deliberately. By sending one deliberately malformed request first, followed by a nested request that would normally be validated by a stricter handler, the mismatch causes the nested request to be routed to a more permissive handler instead – one that never applies the sanitization it should.
That misrouted handler is where the second vulnerability comes in. The /wp/v2/posts endpoint accepts an author_exclude parameter, which normally gets sanitized to an array of integers before being dropped into a SQL query. But if the input isn’t an array, that sanitization step is skipped entirely and the value goes straight into the query. Under normal conditions, WordPress’s validation prevents a non-array value from ever reaching that code path. The batch-route confusion bug is what makes it reachable, turning a dormant SQL injection into a live one – and from there, into code execution.
Once the validation check is bypassed, author_exclude flows unsanitized into the raw SQL query.
Who’s exposed
Every self-hosted WordPress site running core 6.8.0 through 7.1 beta is exposed by default. The REST API batch endpoint is enabled out of the box, no plugin required, so this isn’t a niche configuration issue. That’s a meaningful chunk of roughly 500 million WordPress sites worldwide: small business sites, media outlets, e-commerce stores on WooCommerce, and a large share of the sites that agencies and MSPs manage on clients’ behalf.
Because the chain grants full remote code execution without authentication, a successful exploit hands the attacker the same level of access a compromised admin account would give them: the ability to plant a webshell, create a rogue admin user, pivot into the hosting environment, or quietly inject a skimmer into checkout pages. BleepingComputer has reported that attackers are already doing exactly this, deploying persistent webshells and malicious plugins on compromised servers. Once a vulnerability like this is public and confirmed exploited, mass scanning for unpatched sites typically follows within days, and the sites that get hit first are rarely high-value targets picked by hand. They’re whatever the scanners find open.
Key takeaways for defenders
- Patch as soon as possible. WordPress has shipped fixes in 6.8.6, 6.9.5, 7.0.2, and 7.1 beta 2. Treat this as an emergency update.
- If you manage multiple WordPress installs (agencies, MSPs, hosting providers), run an inventory sweep first. You need to know which sites are still on 6.8.0–6.8.5, 6.9.0–6.9.4, or 7.0.0–7.0.1 before you can prioritize the patch rollout.
- If immediate patching isn’t possible on a given site, put a WAF rule in front of it that blocks or inspects nested requests to /wp-json/batch/v1, since that’s the specific endpoint the chain relies on.
- Review REST API access logs for malformed batch requests or unusual author_exclude parameter values, both of which are signatures of exploitation attempts against this chain.
- Treat any unexplained new admin user, unfamiliar file in wp-content, or unexpected outbound connection from a WordPress host as a potential indicator of compromise, and validate against this chain specifically if the site was running an affected version.
Neither CVE looked urgent on their own. Chained exploits have changed the risk calculus in scenarios like these. A 7.5 and a conditionally-reachable 9.1 don’t get triaged with the same urgency as a standalone critical, but chained together they added up to a full site takeover. Vulnerability chains like this are becoming more common precisely because attackers are looking for that gap between what a CVSS score suggests and what’s exploitable end to end.
Looking for more in-depth analysis of wp2shell, along with other CVEs and noteworthy cybercriminal activity? Download the complete July Cyberthreat Intelligence Report, where we cover what our researchers are tracking and how to stay one step ahead of threat actors.
