wp2shell: WordPress Core's Zero-Login RCE Chain, What to Patch Right Now

If you run WordPress and haven’t checked your version number since Friday, do it before you finish reading this. A vulnerability chain researchers are calling wp2shell lets an attacker with zero credentials take full control of a default WordPress install, no plugin required, no login required, just one HTTP request. WordPress shipped the fix on July 17, and exploitation started the same evening.

What wp2shell actually is

wp2shell isn’t one bug, it’s two chained together. CVE-2026-63030 is a route-confusion flaw in how WordPress core’s REST API resolves batch requests, requests that bundle multiple API calls into a single HTTP call. CVE-2026-60137 is a SQL injection in core. On their own, each is a serious problem. Chained, they let an unauthenticated attacker route a crafted batch request through the confused endpoint into the injectable query, and from there into arbitrary code execution on the server.

The part worth sitting with: this lives in WordPress core itself. It doesn’t need a vulnerable plugin, a misconfigured theme, or an admin who clicked the wrong link. A brand-new, completely default WordPress install on an affected version is exploitable by a single anonymous request. That’s a different threat model than the plugin-chain vulnerabilities that make up most WordPress CVEs, where the attack surface is at least gated by what you happened to install.

The timeline is the real story

WordPress shipped 7.0.2, 6.9.5, and 6.8.6 on July 17, 2026, and pushed the fix through forced auto-updates rather than the usual opt-in release cycle, a strong signal of how seriously the core team treated this one. Rapid7 reported the first confirmed exploitation starting shortly before 7 PM ET that same day, roughly six hours after the patch went out. A public proof-of-concept followed within the next day.

Six hours is not enough time for most site owners to have manually patched anything, which is exactly why the forced auto-update mattered here. If you’re relying on a manual patch cadence, weekly maintenance windows, monthly reviews, this vulnerability moved faster than that cadence by design, and the only thing standing between a default install and compromise for most sites was whether WordPress’s own update mechanism actually reached them in time.

Detail	Value
Vulnerability chain	CVE-2026-63030 (REST API batch-route confusion) + CVE-2026-60137 (SQL injection)
Nickname	wp2shell
Affected versions	WordPress 6.9.x and 7.0 through 7.0.1
Authentication required	None
Plugins required	None, affects core
Patched versions	7.0.2, 6.9.5, 6.8.6
Patch released	July 17, 2026
First observed exploitation	July 17, 2026, ~7 PM ET
Public PoC	Yes, circulating since July 17-18

Why this is worse than a typical core CVE

Most severe WordPress vulnerabilities need a second condition to be exploitable at scale: a specific plugin installed, a non-default configuration, an authenticated low-privilege account to escalate from. Those conditions filter the actual attack surface down from “every WordPress site” to “every WordPress site running this specific combination.” wp2shell doesn’t have that filter. WordPress powers a meaningful share of the web’s total site count, and every one of those running an affected core version, regardless of what’s built on top of it, was exposed the moment the vulnerability chain became public.

That also means the usual advice, “just review your plugins,” doesn’t apply here. This is a core patch-level problem, full stop. If you manage WordPress sites for clients, this is the kind of CVE where checking version numbers across your whole portfolio in one sitting is worth doing today rather than waiting for the next scheduled maintenance pass.

What to actually do this week

1. Confirm your real version number, not just that auto-updates are enabled. Log into wp-admin and check Dashboard > Updates, or check the version footer directly. You want 7.0.2, 6.9.5, or 6.8.6 or later.
2. If you manage multiple WordPress sites, check all of them, not just the ones you remember updating recently. Managed hosting, staging environments, and old client sites that don’t get regular attention are the likeliest places to still be running an unpatched version.
3. Review access logs for the July 17-19 window for anonymous POST requests hitting REST API batch routes, especially with malformed or unusually nested request bodies. Given the public PoC, treat scanning activity from that window as a signal worth investigating, not necessarily a confirmed breach on its own.
4. If a site turns out to have been unpatched during that window, don’t just patch and move on. Check for new admin accounts, unfamiliar files in the upload directory or site root, and scheduled tasks (cron jobs) you didn’t create. A code-execution chain this clean is rarely used for just one thing.
5. If auto-updates are disabled for change-control reasons, this is a good moment to reconsider that policy specifically for core security releases, even if you keep manual review for feature updates.

We work with a lot of teams whose WordPress sites are past due for exactly this kind of patch discipline, whether because auto-updates got turned off for a legacy customization or because nobody’s owned the maintenance calendar since the site launched. If that describes your situation, our WordPress development and maintenance work usually starts with exactly this kind of version-and-patch audit before touching anything else. We’ve also covered how to hire a WordPress developer who treats this kind of patch cadence as a baseline responsibility rather than an afterthought, which is worth reading if this CVE is the reason you’re rethinking who maintains your site.

Unauthenticated, core-level, zero-plugin-required RCE chains are rare, but the gap between patch and exploitation keeps shrinking across the board, not just for WordPress. Treat the next one the same way: check your actual version, don’t assume the update landed, and verify rather than trust the automation.