An Unauthenticated Path to Code Execution in WordPress Core, Already Being Exploited

WordPress runs a large share of the web, which means a flaw in its core is never a small event. On July 17, 2026 the WordPress security team shipped an emergency release to close a pair of vulnerabilities that, used together, let an attacker with no account and no plugin dependency reach a WordPress site’s database and, from there, a full takeover. The chain has been named wp2shell. The headline flaw, CVE-2026-63030, is a REST API batch-route confusion bug that disables an authorization check; the second, CVE-2026-60137, is a SQL injection in WordPress core that was previously reachable only by logged-in users. Chained, the first unlocks the second for anyone on the internet. This is not a theoretical write-up: a public proof-of-concept is circulating, and security vendor Patchstack reported active exploitation beginning the same evening the patch landed.

• Two CVEs, one chain. CVE-2026-63030 is a REST API “batch-route confusion” flaw in WordPress core’s /wp-json/batch/v1 endpoint. CVE-2026-60137 is a SQL injection in the author__not_in parameter of WP_Query. The first bypasses the check that limited the second to authenticated users.
• Unauthenticated. No account, no user interaction, and no non-default plugin or configuration is required to begin the attack.
• Affected versions. The SQL injection (CVE-2026-60137) reaches back further, affecting WordPress 6.8.0 through 6.8.5, 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1. The batch-route confusion (CVE-2026-63030) affects 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1, because the batch endpoint was added in the 6.9 line. Installations before 6.8 are not affected.
• Fixed versions. Update to 6.8.6, 6.9.5, 7.0.2, or 7.1 Beta 2. All were released on July 17, 2026.
• Forced auto-updates were pushed. WordPress.org enabled forced updates through the auto-update system for affected sites, but administrators should confirm the update actually applied rather than assume it did.
• Severity. WordPress described the release as fixing one critical and one high severity issue. Scoring bodies disagree on the exact numbers: the NVD/CNA entry rates CVE-2026-63030 at CVSS 9.8 (Critical), while a separate CISA-ADP assessment lists 7.5; CVE-2026-60137 is scored around 9.1. Treat the chain as critical regardless of the number.
• It is being exploited. Patchstack reported exploitation of CVE-2026-63030 starting shortly before 7:00 PM ET on Friday, July 17, 2026, and a public proof-of-concept exists. There was no known in-the-wild exploitation at the moment of disclosure, but that window closed within hours.

One Malformed Request Knocks the Guard Out of Line

WordPress 6.9 introduced a REST API batch endpoint, reachable at /wp-json/batch/v1 or through the ?rest_route=/batch/v1 parameter, so a client can bundle several API operations into a single request. Internally the handler tracks that bundle with three parallel lists that are meant to stay in lockstep: one for the requests themselves, one for their validation results, and one for the route matches that tell WordPress which handler and which permission check apply to each entry. The vulnerability, as documented by researchers at Hadrian, is that these lists can fall out of alignment. When a malformed sub-request fails early, for example an entry with a broken URL such as http://:, the failure is recorded in the validation list but nothing is recorded in the matches list. From that point on the matches list is one element shorter than the others.

That off-by-one is the whole problem. During dispatch the handler walks the requests and indexes straight into the now shorter matches list, so each remaining request is evaluated against the next request’s route: its handler and, critically, its permission callback. An attacker crafts a batch where a deliberately malformed first entry triggers the desync, and a following low-privilege request is then checked using a different request’s permission logic. The authorization decision no longer matches the operation being performed. In effect, the guard that is supposed to ask “are you allowed to do this?” ends up answering a question about a different action entirely.

The Injection That Was Waiting Behind a Login

On its own, CVE-2026-60137 is a SQL injection in the author__not_in parameter handled by WP_Query, the core class behind most WordPress content queries. What kept it from being an immediate crisis is that WordPress core already restricted the vulnerable path to authenticated users through a blocklist, so an attacker first needed valid credentials. This is where the two bugs become dangerous together. The batch-route confusion in CVE-2026-63030 bypasses exactly that blocklist, letting an unauthenticated request reach the SQL injection that was meant to be off limits without a login. One flaw is a lock that was quietly picked; the other is the door it was guarding.

The route from database access to the “shell” in wp2shell is worth stating plainly, because it shapes how urgently different sites should react. According to analysis from VulnCheck, researchers did not find a single clean jump straight to code execution. Instead the practical attack uses the unlocked SQL injection to read the database, extract an administrator’s password hash, crack it offline, log in as that administrator, and then upload a web shell or take any other action an admin can. Rapid7 separately notes a code-execution path that depends on whether a persistent object cache is in use. The takeaway for operators is that even where full remote code execution is not instant, unauthenticated database read access alone is a severe breach, exposing user records, password hashes, secrets stored in options, and anything else the site keeps in its tables.

Default Code Means Millions of Identical Targets

The reason this matters so much to hosting providers and to anyone managing WordPress at scale is arithmetic. The batch endpoint ships in WordPress core, so no unusual plugin or theme is needed to be vulnerable, and the affected 6.8, 6.9 and 7.0 branches cover the versions most actively maintained sites are running right now. A managed WordPress fleet, a shared-hosting estate, and a single self-hosted blog are all exposed by the same default code. The SQL injection’s reach back to 6.8 widens the blast radius further, because plenty of sites that have not yet moved to 6.9 or 7.0 are still exposed to the injection component even if the batch endpoint itself is newer.

Timing makes it worse. WordPress disclosed and patched on July 17, 2026, and by that same evening Patchstack was already reporting exploitation of CVE-2026-63030 in the wild, with a public proof-of-concept available. Attacks against WordPress core flaws tend to be automated within hours precisely because the target population is so large and so uniform, and this case followed that pattern almost immediately. The forced auto-update WordPress.org pushed will have protected many sites without any human action, which is a genuine strength of the platform, but forced updates do not always complete: sites with disabled auto-updates, file-permission problems, or heavily customized deployments can silently miss them. An administrator who assumes the update happened, without checking, may be running a vulnerable core for days.

Read the Version Number, Do Not Trust the Updater

The fix is to be on a patched version. Confirm that every WordPress installation you are responsible for is running 6.8.6, 6.9.5, 7.0.2, or 7.1 Beta 2, and verify it by looking at the actual reported version rather than trusting that the auto-updater ran. On the 6.8 branch, 6.8.6 closes the SQL injection; the 6.9 and 7.0 branches need 6.9.5 and 7.0.2 respectively to close both bugs. If you operate many sites, treat version verification as the deliverable, not the update trigger, since the forced push has already fired and the question now is which sites it missed.

Where an immediate update genuinely is not possible, several vendors published stopgaps that reduce exposure while you patch, though none is a substitute for the patch itself. Cloudflare deployed managed WAF rules, blocking by default, for both the SQL injection and the RCE chain. Responders also recommend blocking access to the batch route directly, either the /wp-json/batch/v1 path or the ?rest_route=/batch/v1 parameter, or restricting REST API access more broadly through a WAF or security plugin such as Wordfence. Because the chain depends on that specific batch endpoint, closing it off blocks the currently known attack path even if the underlying SQL injection remains present. Given that exploitation is already live, the honest sequencing is simple: patch first, use the endpoint block or WAF rule only to buy time on the small number of sites you cannot update yet, and then audit those sites for signs they were reached before the fix went in, starting with unexpected administrator accounts and unfamiliar files in the uploads directory.

Where Each Claim Here Comes From

The two CVE identifiers, the affected and fixed version ranges, the description of the release as fixing one critical and one high severity issue, and the confirmation that WordPress.org enabled forced auto-updates are taken from the official WordPress 7.0.2 security release announcement on WordPress.org, retrieved July 18, 2026. The batch-route confusion mechanism, including the three parallel arrays, the malformed first sub-request that desyncs the matches list, and the resulting permission-callback mismatch, is from Hadrian’s technical write-up. The relationship between the two bugs, specifically that CVE-2026-63030 bypasses the blocklist restricting the CVE-2026-60137 SQL injection to authenticated users, the identification of that injection in the author__not_in parameter of WP_Query, and the database-dump-to-admin-credential attack path are from VulnCheck. The persistent-object-cache condition on the code-execution path is from Rapid7. The CVSS scoring disagreement between the NVD/CNA figure of 9.8 for CVE-2026-63030 and the separate CISA-ADP assessment of 7.5, and the roughly 9.1 score for CVE-2026-60137, are from the National Vulnerability Database entries. The active-exploitation report attributed to Patchstack, beginning shortly before 7:00 PM ET on July 17, 2026, is from VulnCheck’s account, and the WAF mitigation details, along with the recommendation to block the batch route or restrict the REST API, are from Cloudflare’s blog and Wordfence’s advisory. Severity ratings, scores and exploitation status reflect these sources as of publication and may change.