A bare WordPress site with zero plugins was open to attack from a single, anonymous web request until yesterday. The wp2shell vulnerability chained a REST API route confusion bug with SQL injection. That gave an unauthenticated attacker remote code execution on core. No login. No third-party code. WordPress patched it in 6.9.5 and 7.0.2.
What the wp2shell vulnerability actually is
WordPress’s own security release notes track it as CVE-2026-63030. The notes describe it as “REST API batch-route confusion and SQL injection” that chains into remote code execution. The entry point is the batch endpoint. It sits at /wp-json/batch/v1, or the older query-string alias ?rest_route=/batch/v1. Rapid7’s advisory says the bug bites hardest when persistent object caching is off, which describes a lot of ordinary shared hosting.
Adam Kues at Assetnote, Searchlight Cyber’s attack surface management arm, found and reported the flaw. He used WordPress’s HackerOne program. Searchlight Cyber published a summary but held back the exploitation detail on purpose. As the firm put it in its own writeup, “given the severity of the bug and to give defenders time to patch, we are not releasing technical details at this time.”
A second bug in the same release
A second, unrelated critical SQL injection, CVE-2026-60137, landed in the same release. WordPress credited researchers TF1T, dtro and haongo for that report. It reaches further back than wp2shell, so it was also backported to 6.8.6. The wp2shell vulnerability itself only touches 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1.
The severity labels are worth untangling too. They conflict depending on where you look. WordPress’s own release notes file the batch-endpoint chain as “high severity.” But the GitHub Security Advisory for the same bug, GHSA-ff9f-jf42-662q, rates it Critical. Its CVSS score is 7.5. Rapid7 uses that GHSA framing throughout its advisory. Don’t triage patches by WordPress’s internal severity field alone. That risks under-ranking the wp2shell vulnerability against CVE-2026-60137, the bug WordPress itself calls critical. Both deserve equal urgency. wp2shell needs no authentication at all.
Why the patch mattered so fast
WordPress runs on roughly four in ten websites. A pre-auth core RCE with no preconditions is about as bad as this ecosystem gets. So the project’s response was to flip on forced updates through its auto-update system. Every site still running an affected branch got pushed, whether the owner clicked update or not. WordPress 7.1 beta2 also got the backport, closing off the pre-release channel too.
Rapid7 says it found no confirmed in-the-wild exploitation as of its July 17 report. But it isn’t betting on that lasting. WordPress core is open source, so the firm’s assessment is blunt: “Rapid7 Labs believes it is highly likely that a public PoC will be made available in a short period of time.” The diff between 7.0.1 and 7.0.2 went public the moment the patch shipped. Modern tools can turn that diff into a working exploit fast, in hours, not weeks.
The bug also lands on a familiar fault line for core software. WordPress’s REST API batch endpoint bundles several sub-requests into one call. It’s a convenience feature. Convenience features tend to arrive well after the authentication and routing logic around them was built and reviewed. That gap is a recurring source of exactly this class of bug: a route the framework trusts more than it should.
What defenders should do about the wp2shell vulnerability now
Confirm every internet-facing WordPress install actually pulled the forced update. Don’t just assume it did. Some sites have auto-updates turned off at the host level. Others are pinned to one release by a management tool. Those sites may have missed the push entirely. A public checker at wp2shell.com lets site owners test exposure directly. Rapid7 also says its Exposure Command and InsightVM tools will add checks for CVE-2026-63030 from July 20. Teams that already run those tools will get a fast, fleet-wide way to confirm patch status.
Can’t update core right away? Rapid7 recommends blocking the batch endpoint at the WAF layer as a stopgap. Block both the REST path and the query-string alias. Either one reaches the same vulnerable code. That buys time, but it’s not a substitute for patching. Rapid7’s own guidance is clear: don’t lean on workarounds as a long-term fix. Treat any WAF rule as a bridge to an update, not a replacement for one.
Anyone running fleets of WordPress sites should also check something simpler: would your monitoring even catch a wave of anonymous POST requests to a batch endpoint most admins never think about? The wp2shell vulnerability shows that the parts of core nobody looks at are exactly where a critical bug hides. The next one probably won’t announce itself any louder than this one did.
