WordPress’s wp2shell Flaw Is Rated Critical but Scored Just 7.5

WordPress patched a two-bug flaw known as wp2shell on July 17, letting anonymous attackers run code on any 6.9 or 7.0 site with zero plugins installed. A working exploit followed within a day. The chain’s own severity score, though, rates it just 7.5, only High.

That number matters more than it should. Scanners, ticketing queues and patch deadlines across the security industry sort vulnerabilities by score first and plain warnings second, and the score attached to WordPress’s worst core bug in years reads lower than plenty of routine plugin patches.

A Friday Patch, a Saturday Exploit

WordPress shipped versions 6.9.5 and 7.0.2 on July 17, with backports to 6.8.6 and the 7.1 beta. The release notes credit the fix to a REST API batch-route confusion and SQL injection issue reported by Adam Kues, a researcher at Assetnote, Searchlight Cyber’s attack surface management arm, and separately by TF1T, dtro and haongo. The update touched three files: the REST server class, the query builder, and the core REST API loader.

Two identifiers now track it in the Common Vulnerabilities and Exposures (CVE) system: CVE-2026-63030 covers the batch-route confusion that turns the bug unauthenticated, and CVE-2026-60137 covers the SQL injection underneath it. Kues reported his half through WordPress’s HackerOne bug bounty program. His writeup, published under the name wp2shell, states the attack has “no preconditions and can be exploited by an anonymous user.”

WordPress does not normally override a site owner’s choice to skip automatic updates. It did so anyway on Friday, forcing 6.9.5 and 7.0.2 onto every affected install through its auto-update system. Whether that push reaches sites that had disabled auto-updates entirely is something WordPress has not confirmed, so checking the version directly beats assuming the update landed. By Saturday, the mechanism was public and a working proof-of-concept exploit had gone up on GitHub, a day after the patch itself.

Scale is part of why this matters. WordPress runs something like 43 percent of the web, according to tracking firm W3Techs, and Searchlight Cyber estimates the installed base at more than 500 million sites. That figure covers every WordPress site ever set up, not the exposed population: the flawed code only exists from version 6.9 onward, which shipped in December 2025, so anything actually vulnerable to the code-execution half is running a release under eight months old.

The Score Doesn’t Match the Warning

WordPress’s GitHub security advisory for the chain calls it Critical. The CVE record for the same bug, CVE-2026-63030, carries a Common Vulnerability Scoring System (CVSS) base score of 7.5, which the framework grades only High. The SQL injection underneath it, CVE-2026-60137, scores 9.1, solidly Critical, because the framework rewards direct database access more heavily than an authentication bypass buried behind a parsing bug.

Rapid7, a vulnerability management firm, put the gap in plain terms in its own analysis: the official advisory calls the chain Critical, while the number attached to it reads High, a three-point gap on a ten-point scale wide enough to shuffle which patch queue a bug lands in first.

CVSS is not a measure of risk.

That line comes from the National Vulnerability Database’s own page describing CVSS as a factor in prioritization of vulnerability remediation, the same system scanners and ticketing queues use to decide what gets fixed first.

Security trackers are not reading this one the same way.

• WordPress’s own advisory: labels the chain Critical in its release notes and GitHub security advisory.
• The CVE record: assigns CVE-2026-63030 a base score of 7.5, which standard severity bands read as High, not Critical.
• Rapid7’s read: flags that exact split between label and number in its own customer advisory.

The bug everyone is calling a critical remote code execution flaw is, by its own number, graded below the SQL injection sitting in the same release. Ticketing systems built around CVSS thresholds, patch anything scored 9 or above within a day, for instance, will file the RCE chain two tiers lower, even though it is the half that needs no login at all.

One Array, Off by One

The chain starts with a type-confusion bug in WP_Query, the class that builds nearly every database query WordPress runs. Hand its author__not_in parameter a string instead of an array, and the code skips the check meant to sanitize it, dropping the raw value straight into a database clause. That is CVE-2026-60137, and on its own it has existed since WordPress 6.8.

Reaching that parameter without logging in is the other bug’s job. WordPress’s batch endpoint, reachable at /wp-json/batch/v1, packs several sub-requests into one call and tracks them in two parallel arrays. When a sub-request errors out, WordPress records the failure in one array but not the other, so every request after it gets checked against the wrong handler’s permissions, one slot removed from its own. A low-privilege request can end up passing a permission check meant for someone else entirely.

Security firm Hadrian, which published its own technical reconstruction of the bug, notes that the two-line fix that closes it keeps the two arrays aligned and blocks a sub-request from opening a fresh REST cycle mid-dispatch. WordPress’s advisory recommends updating your sites immediately, language the project reserves for its most severe releases. The batch endpoint itself is not new. It has shipped, on by default, since WordPress 5.6 in November 2020.

Who’s Actually Exposed?

Exposure splits cleanly along version lines. WordPress 6.8 carries the SQL injection alone, patched in 6.8.6. Versions 6.9.0 through 7.0.1 carry the complete, unauthenticated remote code execution (RCE) chain, closed in 6.9.5 and 7.0.2. Anything earlier than 6.8 is untouched by either bug.

One more condition narrows the field further. Cloudflare, which shipped web application firewall (WAF) rules alongside the disclosure, says the code-execution path only opens when a persistent object cache is not in use. Most WordPress installs skip that layer by default, so the out-of-the-box configuration stays exposed. A site running Redis or Memcached as a persistent cache may sit outside this particular path, but that is a side effect of a performance setup, not a security fix, and it does nothing for the SQL injection underneath.

Hosting setup decides who has to act and who does not. Site owners running their own WordPress VPS hosting setup had nobody upstream to push the fix on their behalf, so checking the installed version was on them alone.

WordPress Has Been Here Before

Mass exploitation of WordPress sites is already a going business, not a hypothetical one. In June, a cybercrime crew tracked as WP-SHELLSTORM left its own staging server open for roughly three weeks, and SOCRadar’s investigation into the exposed server found target lists naming more than 1.4 million domains across WordPress and Joomla. The single biggest producer in that campaign was a bug in the Breeze caching plugin, fired at more than 45,000 targets and, by the crew’s own logs, used to backdoor over 17,000 sites.

That Breeze bug needed a non-default setting switched on, was already public, and already had a patch available months earlier. wp2shell needs none of that: no setting to flip, no plugin to install, just a reachable site running an affected core version. If a gated, already-patched plugin bug reached tens of thousands of sites, a default-on, unauthenticated core bug with a public proof-of-concept starts from a wider door.

Managed hosts responded to wp2shell differently than they did to that earlier campaign. Providers running managed WordPress cloud hosting pushed 6.9.5 and 7.0.2 to customer sites without anyone asking, the kind of automatic patching that self-managed setups do not get by default.

The Stopgaps, and Their Limits

Searchlight’s guidance for anyone who cannot patch immediately comes down to one idea: keep anonymous callers off the batch endpoint entirely. Every option below is temporary, and each one can break something else that depends on the REST API.

• Block both endpoint forms at the firewall, covering /wp-json/batch/v1 and the query-string form ?rest_route=/batch/v1 together, since a rule covering only one leaves the other reachable.
• Turn off the REST API entirely, which kills unauthenticated access outright but breaks any plugin, app or integration that depends on it.
• Install a drop-in mitigation plugin that Searchlight publishes at wp2shell.com, rejecting anonymous batch requests at the point WordPress first dispatches them.

All three buy time. The update itself is the only thing that actually closes the chain, and Searchlight’s own checker at wp2shell.com exists to tell owners whether they still need the bridge at all.

Two Numbers Will Decide How This Is Remembered

Two figures will settle how this turns out. WordPress’s own version statistics will show how many sites actually took the patch, and scan traffic aimed at /wp-json/batch/v1 will reveal how many attackers came looking for the ones that did not.

Neither number is public yet. Rapid7 says authenticated checks for InsightVM and Nexpose customers land in its July 20 content release, three days after the patch itself. Until then, teams relying on CVE-keyed scanning have a gap to cover by hand.

The chain is not on CISA’s Known Exploited Vulnerabilities (KEV) catalog. That list requires confirmed activity in the wild, and none had been reported as of July 18. WordPress patched its worst core flaw in years on a Friday. By Saturday, the patch was public too, and so was everything needed to build the attack it was meant to stop.

Frequently Asked Questions

How Do I Check What WordPress Version My Site Is Running?

Log into wp-admin and check the Dashboard or Updates screen, which lists the installed version at the top. Site owners with server access can run wp core version through WP-CLI instead. Either way, confirm the result reads 6.9.5, 7.0.2, 6.8.6 or later before assuming a forced update already landed.

Does a Persistent Object Cache Actually Protect My Site?

Only against the code-execution half, and only as a side effect. A site running Redis or Memcached as a persistent object cache falls outside the specific path Cloudflare described, but the underlying SQL injection, CVE-2026-60137, still works regardless of caching setup. Treat a cache as a performance tool that happens to help here, not a substitute for updating.

Is a Working Exploit for wp2shell Actually Public?

Yes. Once both bugs carried CVE identifiers, researchers outside the original discovery team reconstructed the mechanism from the published patch and posted a working proof-of-concept on GitHub, even though Searchlight held its own technical write-up back. That is the tradeoff with open-source fixes: the code that patches a bug also shows how the bug worked.

Is WordPress 6.8 Actually Safe From This?

Partly. WordPress 6.8 is exposed to the SQL injection alone, CVE-2026-60137, fixed in 6.8.6, but not to the remote code execution chain, which needs code introduced in version 6.9. Versions before 6.8 are not touched by either bug, but a 6.8 site should still update to 6.8.6 rather than skip it.

Will My Host Patch This for Me Automatically?

It depends on the hosting arrangement. Many managed and cloud WordPress hosts apply core security releases to customer sites without any action from the owner, sometimes within hours. Self-managed setups, including most VPS installs, rely on WordPress’s forced auto-update mechanism or on someone manually running the update, so confirming the version directly is worth the two minutes it takes.