HIGH: WordPress Core 'wp2shell' Pre-Auth RCE Chain Gets Public Exploits (CVE-2026-63030)

WordPress runs something like forty percent of the web, which means when a pre-authentication remote code execution bug lands in WordPress core itself, and not in some abandoned plugin nobody has updated since 2019, the entire internet should sit up straight. That is exactly what happened this weekend. A vulnerability chain that researchers have nicknamed wp2shell takes an anonymous, unauthenticated HTTP request and turns it into code running on the server, no login required, no plugins needed, in a completely stock install. Working proof of concept code is already public on GitHub, and if you have not patched yet, you are now racing scanners that never sleep.

The name says the quiet part out loud. Wp2shell describes going from a WordPress URL to a shell on the box, and the fact that it works against core rather than a third party add-on is what makes this genuinely rare. WordPress core is heavily audited, so unauthenticated RCE in the base platform shows up maybe once every few years. This one arrived with company, because wp2shell is not a single flaw but two bugs working together.

Two CVEs that add up to a shell

The first half of the chain is CVE-2026-63030, a route confusion issue in the WordPress REST API batch endpoint. The batch API exists to let clients bundle several REST calls into one request, and the confusion lets an attacker smuggle requests past the checks that should have stopped them. On its own the CVE record scores it a 7.5 on the CVSS scale, which puts it in High territory rather than Critical. Do not let that number lull you to sleep. WordPress security itself rates the combined chain as Critical, and a 7.5 that means anonymous code execution on forty percent of the web is far scarier than a 9.8 buried in some appliance three people run.

The second half is CVE-2026-60137, a SQL injection flaw sitting in WordPress core. Chained behind the batch route confusion, the SQL injection is what carries the attacker the rest of the way from smuggled request to actual code execution and full site compromise. The mechanism reportedly comes into play when a persistent object cache is not in use, which describes a huge number of everyday WordPress installs that never bothered with Redis or Memcached. Credit where it is due, Adam Kues at Assetnote uncovered the batch route flaw, while researchers going by TF1T, dtro, and haongo reported the SQL injection separately. Two independent discoveries colliding on the same weekend is the kind of luck defenders do not get to count on.

Which versions are on fire

Version math matters here, so read carefully. WordPress releases from 6.9.0 through 6.9.4 carry the full RCE chain and are fixed in 6.9.5. The 7.0.0 and 7.0.1 releases are likewise fully exploitable and patched in 7.0.2. The older 6.8.x branch, specifically 6.8.0 through 6.8.5, is affected only by the SQL injection half and not the full chain, and it gets its fix in 6.8.6. The 7.1 beta line was patched in Beta 2 for anyone brave enough to run pre release WordPress in anything resembling production. The clean summary is that if you are on 6.9.5, 7.0.2, or 6.8.6 or later, you are out of the immediate blast radius. Anything below those lines needs to move today.

The saving grace, and it is a real one, is that WordPress pushed forced updates through its automatic update system on Friday. Sites with auto updates enabled largely healed themselves before most administrators even read the advisory. The problem is the enormous population of sites where someone disabled auto updates years ago for stability reasons, or where a managed host pins core versions, or where a staging environment got forgotten. Those are the sites attackers will find, because attackers are very good at finding the machines everyone else forgot about.

From disclosure to public exploit in a weekend

The timeline is the scary part. The advisory and patches went out around July 17 and 18, technical writeups followed almost immediately, and a working proof of concept landed on GitHub shortly after that. When Rapid7 first wrote up CVE-2026-63030 it noted it was not yet aware of confirmed exploitation in the wild, and The Hacker News reporting through July 18 said much the same. That window has almost certainly closed by now. Once a pre authentication RCE for WordPress core has public exploit code, mass internet scanning follows within hours, because the target list is essentially every WordPress site on earth. Treat the absence of a confirmed victim headline as a lag in reporting rather than as evidence you are safe.

What exploitation looks like in practice is grimly predictable. An attacker sprays requests at the REST batch endpoint across huge ranges of IP space, the vulnerable hosts answer differently, and the automated tooling comes back to finish the job. From code execution the usual WordPress post compromise routine kicks in, which means dropping a PHP web shell somewhere in the uploads directory, creating a rogue administrator account for durable access, injecting spam or malicious redirects into the content, and in the worst cases pivoting deeper into whatever else shares that hosting environment. A compromised WordPress site is rarely the attacker's final goal so much as a convenient doorway.

What to do right now

The fix is refreshingly simple to state. Update WordPress core to 6.9.5, 7.0.2, or 6.8.6 or later depending on which branch you run, and do it now rather than at the next maintenance window. The WordPress team has been explicit that applying the official update is the correct remediation and that clever workarounds are a distant second choice. If you manage more than a handful of sites, this is the moment to log into every dashboard and confirm the core version by hand, because trusting that auto updates fired everywhere is exactly the assumption that leaves one forgotten site owned.

For the rare cases where you genuinely cannot update immediately, there are stopgaps that buy time without fixing the root cause. Blocking anonymous access to the REST API through a security plugin shuts the door on unauthenticated abuse of the endpoint. At the network edge you can block requests to the batch route directly, meaning both the /wp-json/batch/v1 path and the ?rest_route=/batch/v1 query string form, since attackers will happily try either. Cloudflare and Imperva have both shipped managed rules for this, so if you already run a web application firewall, confirm the relevant signature is enabled and in blocking mode rather than merely logging.

Detection deserves attention even after you patch, because a site that was internet facing and unpatched over the weekend may already be compromised. Comb your access logs for a spike of requests to the batch endpoint, especially from noisy scanning IP ranges. Hunt for newly created administrator accounts nobody remembers making, for unexpected PHP files with recent timestamps in wp-content and the uploads folder, and for unfamiliar scheduled tasks or modified core files. If you find any of that, assume full compromise, rotate every credential associated with the site and its database, and rebuild from known good rather than trying to surgically remove a shell you may not fully understand.

The MSP angle

For managed service providers and agencies, wp2shell is a textbook opportunity to prove your value on a Sunday. Any client fleet with WordPress in it just became an urgent triage exercise, and the firms that can sweep every managed site, confirm the patched version, and hunt for indicators of compromise within a day are the ones clients remember at renewal time. Package this as a rapid WordPress hardening and incident readiness engagement covering emergency patching, WAF rule deployment, REST API lockdown, and a compromise assessment for anything that sat exposed. It also makes an unusually honest case for a managed patching retainer, because the entire lesson of this weekend is that the sites which survived were the ones with automatic updates actually turned on and monitored, and that is a service you can sell rather than a favor you keep doing for free.

The broader takeaway is one defenders keep relearning. Core is not automatically safe just because it is core, forty percent market share makes WordPress the single juiciest target on the web, and the gap between a patch dropping and a public exploit landing is now measured in a single weekend. Update to a fixed version, check your logs, and stop assuming the CMS running your marketing site is somebody else's problem.