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.

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.

What to actually verify — not just "did it update"

  1. 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.
  2. 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.
  3. Managing a site without direct login access? wp2shell.com hosts a public checker researchers published alongside the disclosure.
  4. 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.

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.