wp2shell: The WordPress Core Bug That Needed No Password and No Plugin

wp2shell: The WordPress Core Bug That Needed No Password and No Plugin

What Happened

On July 17, 2026, WordPress shipped an emergency security release patching a two-bug chain researchers named wp2shell — a pre-authentication remote code execution path built into WordPress core itself, not a third-party plugin. The chain combines CVE-2026-63030, a route confusion flaw in the REST API's batch endpoint, with CVE-2026-60137, a SQL injection issue — a flaw that lets an attacker sneak database commands in through a field meant to hold ordinary data. An attacker needs no account, no installed plugin, and no action from a site visitor to take over a default WordPress site this way.

The chain affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 for the full remote-code-execution path. Sites on 6.8.0 through 6.8.5 carry only the SQL injection half, which can leak data but can't run code on its own. WordPress fixed all three lines in versions 6.9.5, 7.0.2, and 6.8.6 — and, given the severity, turned on forced automatic updates for every affected install, whether or not the site owner had auto-updates enabled.

NVD lists two severity scores for CVE-2026-63030 from two different assessors: WPScan rates it 9.8 out of 10, while CISA's own published rating (listed separately on the same NVD record) puts it at 7.5 out of 10. Either number lands the same place: critical.

On July 21, 2026, CISA added CVE-2026-63030 and CVE-2026-60137 — the two flaws behind wp2shell — to its Known Exploited Vulnerabilities catalog, confirming the WordPress core RCE chain was already being exploited against live sites — not a theoretical risk, an active one. CISA's remediation deadline for federal systems was July 24, 2026. That deadline has already passed. If a site hasn't updated since mid-July, it has been sitting exposed past the date the U.S. government itself required a fix.

The bug was found by Adam Kues at Assetnote, working with Searchlight Cyber — using an AI-assisted vulnerability research tool as part of the discovery process. That detail matters beyond trivia: it's a preview of how fast the gap between "a bug exists" and "a bug is found" is shrinking.

How the Chain Actually Works

wp2shell works by chaining two WordPress core bugs: a route-confusion flaw in the REST API's batch endpoint (/wp-json/batch/v1) that lets an unauthenticated request be treated as authenticated, combined with a SQL injection in WP_Query's author__not_in parameter that turns that confusion into arbitrary code execution. WordPress's REST API batch endpoint lets a client bundle multiple API requests into one call. The route-confusion bug means the batch processor can be tricked into resolving an internal request path differently than the WordPress permission system expects — the request looks unauthenticated to the router but gets treated as authenticated deeper in the call stack. Chained with the second bug — unsanitized input reaching WP_Query's author__not_in parameter — an attacker turns that confusion into a working SQL injection, then escalates the injection into arbitrary code execution on the server. Picture two separate locks, each individually weak, installed on the same door: the first lock's flaw only confuses which room you end up in, and the second lock's flaw only lets you jiggle it open once you're already inside. Neither one alone lets a burglar in. Together, a stranger walks straight to the room with your files, no key required.

Rapid7 researchers observed the chain used in the wild to extract password hashes, crack administrator credentials offline, upload malicious plugins disguised as legitimate ones, and drop persistent webshells — a small file that gives an attacker a permanent, hidden command line into the server, reusable long after the original bug is patched.

Did wp2shell Patch Itself Automatically?

For most sites, yes, and that's the detail most coverage of "millions of WordPress sites at risk" skipped past. WordPress didn't just release a patch — it forced the patch onto affected sites automatically, overriding the update settings on most default installations. For the majority of active, properly hosted WordPress sites, this incident already resolved itself in the background sometime between July 17 and July 21, with no action from the owner at all.

That's the silver lining, and it's a real one: modern WordPress's auto-update infrastructure is good enough that a critical, actively-exploited core vulnerability can patch itself across most of the ecosystem inside a few days. The sites still exposed today aren't unlucky — they're the ones where something specific is blocking that safety net.

Which WordPress Sites Are Still Vulnerable to wp2shell?

The sites still vulnerable in August 2026 tend to share one of a few traits: auto-updates disabled at the hosting or plugin level (some security plugins and staging workflows turn this off deliberately, then nobody turns it back on); custom code or a heavily modified wp-config.php that interferes with WordPress's update mechanism; or a site nobody is actively managing — built once, launched, and never checked again. That last trait describes a common pattern: a small business site set up years ago by a freelancer or an agency that's no longer involved.

The forced-update safety net also only covers WordPress core. A plugin with its own unrelated vulnerability — like the miniOrange SSO plugin flaw with no patch at disclosure or the ShapedPlugin supply-chain compromise from earlier this summer — doesn't get force-patched the same way. Core auto-updating is a floor, not a ceiling.

Is Your WordPress Site Still Vulnerable to wp2shell?

Your site is safe from wp2shell if it's running WordPress 6.9.5, 7.0.2, or 6.8.6 or later. Here's how to verify that in five minutes, plus how to check for signs it was already exploited before you patched:

1. Confirm the version, don't assume it. Log into wp-admin and check Dashboard → Updates. The site should show 6.9.5, 7.0.2, or 6.8.6 or later — not just "up to date."
2. Check for unfamiliar admin users. If the chain was exploited before patching, an attacker's first move is often creating a new administrator account. Review Users → All Users for anything unrecognized.
3. Audit installed plugins for anything you didn't add. Webshells are frequently disguised as legitimate-looking plugins with generic names.
4. Check REST API logs if your host provides them, looking for repeated requests to /wp-json/batch/v1 in the days before your update — a sign the chain was probed even if it wasn't successfully exploited.
5. If you find anything from steps 2 or 3, treat it as a confirmed breach, not a false alarm — rotate all passwords and API keys, and get a security review before assuming a plugin deletion fixed it.

Why This Keeps Happening

wp2shell is the third core-adjacent WordPress security event of this scale in a single summer — after the miniOrange SSO plugin's unpatched authentication bypass and the ShapedPlugin supply-chain compromise. Each had a different root cause, but the same shrinking timeline: disclosure to active exploitation in days, not months, the same pattern behind why WordPress shipped three separate security updates in two days earlier this year. Add AI-assisted vulnerability research into the mix — the same category of tooling that found wp2shell in the first place — and that timeline gets shorter for both sides. Defenders find bugs faster. So do attackers.

Treating "WordPress" as a website platform you set up once is no longer a safe assumption. It's infrastructure that needs the same ongoing attention as anything else running production code — because increasingly, that's exactly what it is.

Frequently Asked Questions

What is wp2shell? wp2shell is the name researchers gave to a two-bug vulnerability chain in WordPress core — CVE-2026-63030 and CVE-2026-60137 — that lets an unauthenticated attacker run code on a default WordPress site with no plugin and no login required. WordPress patched it on July 17, 2026.

Is my WordPress site affected by wp2shell? Your site was affected if it ran WordPress 6.9.0–6.9.4 or 7.0.0–7.0.1 before July 17, 2026 (the full remote-code-execution path), or 6.8.0–6.8.5 (SQL injection only, no code execution). Check Dashboard → Updates: if the version shown is 6.9.5, 7.0.2, 6.8.6, or later, the site has the fix.

Was wp2shell exploited in the wild? Yes. CISA added CVE-2026-63030 and CVE-2026-60137 to its Known Exploited Vulnerabilities catalog on July 21, 2026, confirming active exploitation, and set a remediation deadline of July 24, 2026 for federal systems — a deadline that has since passed.

Do I need to do anything if auto-updates are enabled? Probably not. WordPress forced this patch onto affected sites automatically regardless of the site's update settings, so most actively hosted sites patched themselves between July 17 and July 21, 2026. Sites with auto-updates disabled, heavily customized wp-config.php files, or no active management are the ones still exposed.

The Sitora Take

We don't think most small business owners should have to track CVE numbers or CISA catalogs — that's not a reasonable thing to ask of someone running a plumbing company or a law practice. But "my host handles updates" and "my site actually verified it updated" are two different claims, and this incident is a clean example of why the difference matters: the fix existed for days before most of the exposed sites did anything about it, because nobody was checking.

That's the gap a maintained site closes. Not just installing WordPress and walking away, but someone actually watching for exactly this kind of event and confirming the patch landed — not assuming it did.

👉 Get a website security review or book a strategy call with Sitora