If your site runs WordPress 6.9 or 7.0, check your version before you finish reading this. A vulnerability chain in WordPress core, publicly known as wp2shell, lets an attacker with no account run code on a fully default, unpatched install. WordPress shipped fixes on July 17, 2026: versions 6.9.5 and 7.0.2. Working exploit code is already public, so the usual quiet window between disclosure and real attacks does not exist here. If your dashboard shows anything older than those versions, update now and come back to the rest of this post afterward.

How two harmless bugs became one serious one

Adam Kues, a researcher at Assetnote (Searchlight Cyber’s attack surface team), reported the chain through WordPress’s HackerOne program. It is tracked as two CVEs: CVE-2026-63030, a route confusion bug in the REST API’s batch endpoint, and CVE-2026-60137, a SQL injection in WP_Query.

What makes this one interesting is that neither bug is dangerous alone. The REST API sanitizes the input the SQL injection needs, and the batch endpoint rejects the request type that would normally reach it. The route confusion bug defeats both protections at once, so a request that should never get through arrives at the vulnerable query code intact. From there, unauthenticated SQL injection extends into full remote code execution. The WordPress release notes and the GitHub advisory describe the same combined chain.

Searchlight held back the technical details at first and published a free checker at wp2shell.com so site owners could test exposure without understanding the exploit. That head start is gone. Proof-of-concept code has surfaced publicly, and once that happens, mass scanning follows within hours, not days.

Which versions are exposed

  • WordPress 6.9.0 through 6.9.4: vulnerable to the full RCE chain, fixed in 6.9.5
  • WordPress 7.0.0 through 7.0.1: vulnerable to the full RCE chain, fixed in 7.0.2
  • WordPress 6.8.x: not exposed to the RCE chain, but affected by the standalone SQL injection (CVE-2026-60137), fixed in 6.8.6
  • Earlier branches: not affected

Note what is missing from that list: any mention of plugins or themes. A bare install with nothing else on it is exploitable if the core version falls in those ranges. One triage detail worth knowing: CVE-2026-63030 carries a CVSS score of 7.5 (High), even though most coverage is calling it critical. If your patching policy keys off a formal severity threshold, use the number, but treat the urgency as critical either way, because the exploitability in practice is what matters.

Patch first, then verify

Open Dashboard > Updates. You want to see 6.9.5, 7.0.2, or later. WordPress pushed the fix as a forced auto-update, but forced pushes do not reach everyone. Sites with auto-updates disabled, version-pinned deployments, staging pipelines that promote a frozen core, and managed hosts with manual review cycles are exactly the sites still sitting on vulnerable versions right now. If you manage more than one site, check each one individually rather than assuming the push landed. When in doubt, wp2shell.com will tell you whether a given site is exposed.

If you truly cannot update yet, block anonymous access to /wp-json/batch/v1 and ?rest_route=/batch/v1 at your firewall. Both paths, not one; blocking only the pretty permalink leaves the query-string route wide open. This buys time, nothing more.

That stopgap is also why SiteFort Security users who enabled Restrict REST API Access had protection before this vulnerability was ever disclosed. The entire wp2shell chain depends on an anonymous request reaching the batch endpoint, and that control blocks unauthenticated REST requests before they touch the vulnerable code. It is the same class of mitigation WordPress recommends for sites that cannot patch immediately, except already running. If you use SiteFort, take thirty seconds to confirm the control is on and glance at Endpoint Status to make sure it was not switched off for some integration months ago. And to be clear: hardening narrowed the attack surface here, but it does not replace the core update. Patch anyway.

If your site sat unpatched with the PoC public

Updating closes the door going forward, but it does not tell you whether someone walked through it first. If a vulnerable site was reachable between the public PoC and your patch, spend a few minutes looking for signs of compromise: admin accounts you did not create, PHP files in wp-content/uploads, recently modified core files, or scheduled tasks you do not recognize. Successful exploitation leaves attackers with code execution, and the usual follow-up is a persistent backdoor that survives the patch.

If you find anything suspicious, or you would rather have a second set of eyes confirm the site is patched and clean, our malware removal service handles exactly this: verify the fix, sweep for backdoors, and document what happened.

Either way, the order of operations today is simple. Version check, update, then look backward. The first two take five minutes.