no login. no plugin. no weird setup. one anonymous request and a stranger owns a default WordPress site. the fix is out — here's exactly what to check before you assume you're safe.
WordPress shipped emergency releases 6.9.5 and 7.0.2 on July 17 for a bug researchers named wp2shell — a pre-authentication remote code execution flaw that needs no login, no plugin, and no misconfiguration. A completely default install is exploitable through a single anonymous HTTP request. We ran this site on WordPress for years before this rebuild, so a core-level bug like this one isn't an abstract story for us.
0.0/ 10
CVSS severity: Critical
Rated 9.8 by WPScan — near the maximum a vulnerability can score.
REST API batch route confusion
CVE-2026-63030
the entry point
SQL injection in WP_Query
CVE-2026-60137
author__not_in parameter — the payload
6.9.0–6.9.4, 7.0.0–7.0.1
Affected
fixed in 6.9.5 / 7.0.2
None
Auth required
anonymous, default install, no plugins
How the chain actually works, in plain terms
The REST API's batch endpoint gets confused about which route a request is actually meant for, letting an anonymous request get processed as something more privileged than it should be. That mis-routed request reaches WP_Query's author__not_in parameter, which turns out to be vulnerable to SQL injection. Chain the two together and an attacker with no account at all can get code execution on the server. Neither half of the chain touches a plugin — this is core WordPress, on a stock install. If you want the step-by-step version of how that misrouting reaches the SQL injection, we broke down how wp2shell works in detail.
How the wp2shell chain reaches code execution
Anonymous request
One HTTP call to the REST API batch endpoint. No login, no plugin.
Route confusion
wp_parse_url() fails mid-batch, so later requests run under the wrong handler (CVE-2026-63030).
SQL injection
The misrouted request reaches WP_Query's author__not_in parameter (CVE-2026-60137).
Code execution
Database write is escalated to running the attacker's own code — a shell.
Full takeover
The attacker controls the site and the server under it.
Anonymous request
One HTTP call to the REST API batch endpoint. No login, no plugin.
Route confusion
wp_parse_url() fails mid-batch, so later requests run under the wrong handler (CVE-2026-63030).
SQL injection
The misrouted request reaches WP_Query's author__not_in parameter (CVE-2026-60137).
Code execution
Database write is escalated to running the attacker's own code — a shell.
Full takeover
The attacker controls the site and the server under it.
Each stage feeds the next — neither half is a full takeover alone. That's what makes it a chain.
What to actually verify — not just "did it update"
Log into wp-admin → Updates and confirm the version reads 6.9.5 or 7.0.2. Don't assume a background auto-update silently succeeded.
If a host or a security plugin disables core auto-updates on your site, it did not get the automatic fix — that site needs a manual update now. (This is exactly the gap the forced auto-update can miss — and why managed vs self-hosted sites fared so differently.)
Managing a site without direct login access? wp2shell.com hosts a public checker researchers published alongside the disclosure.
Running an affected version that sat unpatched through the disclosure window? Treat it as potentially compromised — check for unfamiliar admin accounts or files, don't just patch and move on. Our 10-minute security audit walks through checking for compromise.
Discovered by Adam Kues at Assetnote (Searchlight Cyber), reported through WordPress's HackerOne program — the kind of responsible disclosure that got a fix shipped before mass exploitation, not after.
WordPress.org has turned on forced automatic updates for sites running affected versions, which will quietly close this for most of the web. The gap that matters is the sites where auto-updates are disabled by a host, a plugin, or an admin setting — that's exactly who this piece is for.
wp2shell: quick answers
What versions of WordPress does wp2shell affect?
The full remote-code-execution chain affects WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1. It's fixed in 6.9.5 and 7.0.2. Versions 6.8.0–6.8.5 have only the SQL-injection half and need a facilitating plugin; 6.8 and earlier lack the vulnerable batch endpoint. Update to a patched version regardless of which you run.
How do I know if I'm already patched?
Log into wp-admin and check the version in the footer, or go to Dashboard → Updates. 6.9.5, 7.0.2 or higher means you're safe. Don't assume a background auto-update ran — if your host or a plugin disabled core auto-updates, you need to update manually. Our security audit covers verifying this properly.
What does 'wp2shell' mean?
It's a nickname: 'WordPress to shell,' where a shell is the ability to run commands on a server. It refers to going from an anonymous web request to full code execution. The official identifiers are CVE-2026-63030 and CVE-2026-60137. We explain the full picture in what is wp2shell.
For the complete picture, start with what is wp2shell — the plain-English overview — or the technical how it works breakdown. And if you run login or SSO plugins, note a separate critical WordPress flaw landed the same week that updating core does nothing for.
