wp2shell: Pre-Auth RCE in WordPress Core (Patch Now)

The software that runs a large share of the web just shipped an emergency fix. On July 17, 2026, the WordPress project released versions 7.0.2 and 6.9.5 — with backports to the 6.8.6 branch — to close a pre-authentication remote code execution flaw in core that an anonymous attacker can trigger against a default installation with no plugins. The vulnerability, dubbed wp2shell by the researcher who found it, is not a single bug but a chain of two, and their combination is what turns a confined database issue into full server compromise. WordPress considered the risk severe enough to force auto-updates onto affected sites, an unusual step reserved for the most dangerous flaws.

Two bugs, one chain

wp2shell was disclosed by Adam Kues of Searchlight Cyber, who published a technical writeup and a public checker at wp2shell.com so administrators can test whether their sites are exposed. The exploit chains two distinct weaknesses in WordPress core.

The first, CVE-2026-60137, is a SQL injection in the author__not_in parameter of WP_Query, the core class that builds nearly every database query WordPress issues. It carries a CVSS base score of 9.1 and is classified under CWE-89. On its own, an injection into WP_Query is serious but bounded — it lets an attacker read or manipulate data the query touches, but it does not by itself hand over the server. This bug reaches back to WordPress 6.8, making it the wider-exposure half of the pair.

The second, CVE-2026-63030, is where the danger escalates. It is a REST API batch-route confusion issue — an interpretation conflict classified as CWE-436 — in the /wp-json/batch/v1 endpoint, a feature that has shipped in WordPress since version 5.6 in 2020. The batch endpoint is designed to bundle multiple API calls into a single request. Routed through that endpoint on WordPress 6.9 and later, the SQL injection stops being a read-only nuisance and becomes a path to remote code execution. In effect, the batch route provides the leverage that converts a database bug into arbitrary commands on the underlying host.

Why this one is worse than most

WordPress security advisories arrive constantly, and the overwhelming majority concern plugins and themes — the sprawling third-party ecosystem where most real-world compromises originate. wp2shell is different on three counts, and each one raises the stakes.

It is in core, not a plugin. The flaw lives in WordPress itself, so it does not depend on a site running any particular add-on. Roughly two out of five websites run WordPress; a core pre-auth RCE is close to a worst case for the platform.

It needs no authentication and no special configuration. As Searchlight Cyber describes it, the exploit requires no login, no plugins, and no non-default settings. A single anonymous HTTP request against a stock install is sufficient to reach code execution. There is no privilege to escalate and no account to compromise first — the attack surface is simply “the site is online.”

The vulnerable code is recent, which is oddly the good news. The RCE-enabling combination only exists from WordPress 6.9 onward, and 6.9 shipped on December 2, 2025. Sites still on 6.8 are exposed to the SQL injection (CVE-2026-60137) but not to the full remote-code-execution chain, because they lack the specific batch-endpoint behavior that CVE-2026-63030 abuses. That narrows the population of fully exploitable installs — but 6.9 has been the recommended branch for months, so the exposed base is still enormous.

What to do right now

The fix is to update. WordPress has released patched builds across every supported branch:

• 7.0.2 for sites on the 7.0 line
• 6.9.5 for sites on the 6.9 line
• 6.8.6 for sites still on 6.8
• 7.1 Beta 2 for anyone testing the next release

Because WordPress.org enabled forced auto-updates for affected sites, many installations will patch themselves without administrator action. That is a safety net, not a plan. Sites that have disabled automatic updates, that run behind restrictive firewalls that block the update servers, or that are managed through a deployment pipeline that pins core versions will not update on their own — and those are exactly the environments most likely to be running unattended and internet-exposed. Administrators should confirm the installed version by hand rather than assume the auto-updater reached every host.

For sites that cannot patch immediately, edge filtering buys time. Cloudflare has published Web Application Firewall rules targeting both vulnerabilities, and other WAF vendors have moved to add signatures for the malicious batch-endpoint and author__not_in patterns. A WAF is mitigation, not remediation — it narrows the window while the real fix, updating core, propagates.

The pattern behind the bug

wp2shell is a textbook example of a chained vulnerability, where two individually survivable weaknesses combine into something far worse than the sum of their parts. Neither bug is catastrophic alone: an injection bounded to one query, and a batch endpoint whose request handling is a little too permissive. The severity comes entirely from their interaction — the batch route giving the injection a way out of its cage.

That is a recurring theme in modern web security, and it echoes recent critical flaws in other widely deployed platforms, from the SharePoint remote code execution bug patched earlier this year to a run of RCEs in AI tooling. Long-lived, rarely-audited code paths — the batch endpoint has been in WordPress for five years — are precisely where these chains tend to hide, because individually they never tripped an alarm. It also underscores why the broader discipline of software supply-chain security increasingly treats the framework itself, not just its dependencies, as part of the attack surface.

What it means

For the millions of organizations that run WordPress, the practical takeaway is narrow and urgent: confirm you are on 7.0.2, 6.9.5, or 6.8.6, and do it today. Forced auto-updates will cover most sites, but the ones they miss are disproportionately the high-value, internet-facing, unattended installs that attackers hunt for. A pre-auth RCE with no configuration prerequisites is the kind of bug that gets weaponized into mass-scanning within days of disclosure, and a public checker at wp2shell.com means both defenders and attackers can trivially fingerprint vulnerable hosts.

The winners here are the researchers and the process. Coordinated disclosure worked: Searchlight Cyber reported the chain, WordPress shipped fixes across every branch simultaneously, and the project used its forced-update mechanism the way it is meant to be used. WAF vendors closed the gap for sites that cannot patch on their own schedule. That is roughly the best-case response to a worst-case class of bug.

The losers are the operators of the long tail — the abandoned blogs, the forgotten staging sites, the agency-built installs whose maintenance contracts lapsed. Those are the hosts that will still be running vulnerable code weeks from now, and they are where any real-world exploitation will concentrate. Watch for two things next: whether proof-of-concept exploit code surfaces publicly, which would sharply raise the risk for unpatched sites, and whether any mass-compromise campaign materializes. The window between an emergency patch and active exploitation is often measured in days — and with wp2shell, that clock is already running.