On July 17, 2026, WordPress released versions 6.9.5 and 7.0.2 to fix two vulnerabilities in WordPress core, now tracked together under the nickname wp2shell. Four days later, on July 21, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added one of them to its Known Exploited Vulnerabilities catalog, confirming that attackers are already using it against live sites.
What sets wp2shell apart from most WordPress security news is where the bug lives: in WordPress core itself, not in a plugin, and it needs no password to trigger. We’ve dug into the technical writeups, the patch notes, and the exploitation reports published since, to give you a clear picture of what happened and what to do about it.
What exactly is wp2shell?
wp2shell combines two separate WordPress core bugs into a single attack chain. The first, CVE-2026-63030, sits in the REST API’s batch endpoint (/wp-json/batch/v1), the door WordPress uses to process several API requests in one call. A parsing error inside that endpoint can desynchronize two internal tracking lists, so a request ends up handled by the wrong permission check. The second, CVE-2026-60137, is a SQL injection in WP_Query‘s author__not_in parameter: pass it a string instead of the array WordPress expects, and validation gets skipped.
On their own, neither bug is catastrophic. Chained together, the route confusion strips away the authentication check that would normally block the injection, so an anonymous visitor can push a SQL injection straight into the database and, from there, run their own code on the server.
Do you need a plugin, or a password, to be at risk?
No. wp2shell reaches a stock WordPress install, with zero plugins active and zero credentials involved. Adam Kues, the Assetnote researcher (Searchlight Cyber’s attack-surface division) who reported the batch-route bug, describes it as having no preconditions: any site running an affected core version is exposed, editorial team or not, plugin-heavy or not.
What’s changed since the patch: confirmed exploitation
When The Hacker News first covered wp2shell on July 17, no exploitation had been reported yet. That changed within days. CISA’s July 21 listing confirms active use in the wild, and security vendor Wiz has since published concrete evidence of what attackers do once inside: dropping small PHP backdoors (Wiz found examples as simple as eval($_POST['[REDACTED]']??'http_response_code(404);')), planting a disguised 150 KB webshell packaged to look like a plugin named “CMSmap,” and registering a fake REST endpoint to run base64-encoded commands. Wiz also observed attackers using the flaw to list every user account and to probe for the wp-config.php file that holds a site’s database credentials.
The same report estimates that roughly 60% of scanned WordPress instances still carried at least one vulnerable version on the day the fix shipped, a share that fell to about 50% within 24 hours. Mass scanning for unpatched sites started almost immediately after the disclosure.
Is your site actually affected?
It depends on which branch you are running.
- WordPress 6.8.0 to 6.8.5: exposed to the SQL injection only, fixed in 6.8.6.
- WordPress 6.9.0 to 6.9.4 and 7.0.0 to 7.0.1: exposed to the full, unauthenticated code-execution chain, fixed in 6.9.5 and 7.0.2 respectively.
- WordPress 7.1 beta2 already ships both fixes.
One detail narrows the risk without removing it: according to Cloudflare’s analysis, the code-execution step only works when the site is not running a persistent object cache. Searchlight Cyber does not treat that detail as a safety net in its own advisory: the SQL injection itself is unaffected by caching, and the advisory still calls for an immediate update regardless.
What to do now, in order
- Check your version (Dashboard > Updates) and update to 6.9.5, 7.0.2, or 6.8.6, whichever branch you are on.
- Do not assume a forced update already handled it if you have auto-updates turned off. WordPress has not said whether the forced push it enabled for this release reaches sites where automatic updates were disabled, so check manually if that applies to you.
- If you cannot update immediately, Searchlight Cyber recommends blocking requests to
/wp-json/batch/v1(and its query-string form,?rest_route=/batch/v1) at your firewall, or installing a plugin that disables the REST API for anonymous visitors. Searchlight Cyber is explicit that these are stopgaps: they can break legitimate integrations, and none of them replace the update. - If your site was reachable and unpatched between July 17 and your update, look for signs of compromise: unfamiliar plugins (Wiz flagged one disguised as “CMSmap”), unexpected admin accounts, or PHP files you did not create. Assetnote’s free checker at wp2shell.com can tell you whether a site is currently vulnerable, though it cannot tell you if it was already compromised in the meantime.
Our take on wp2shell
Most WordPress security stories trace back to a plugin. wp2shell traces back to WordPress itself, and it reaches every site on an affected version by default, plugin-heavy or not. Our usual advice is to test a new version on staging before touching a live site. For a patch this urgent, we would still keep a fresh backup before updating, but we would not delay the update itself to check compatibility first: with active exploitation already confirmed, applying the fix comes first, and checking your theme and plugins comes right after. If you are not sure which version your site is running, that is the first thing to check today.
If you have not read our WordPress 7.0 “Armstrong” overview yet, this is a good moment: it covers the version wp2shell affects.
Sources: WordPress.org (official 6.9.5/7.0.2 release notes), NVD/CVE record for CVE-2026-63030 and CVE-2026-60137, CISA Known Exploited Vulnerabilities Catalog, Searchlight Cyber / Assetnote research advisory, Wiz threat research.
