A default install is all it takes
WordPress released versions 6.9.5 and 7.0.2 on July 17, 2026, to close a pre-authentication remote code execution vulnerability in core that researchers named wp2shell. The defining trait of this bug is its lack of preconditions. It requires no login, no unusual configuration, and no third-party plugins, which means a stock WordPress site with nothing added is exploitable by an anonymous HTTP request. That profile is about as dangerous as web vulnerabilities get for a platform that powers a large share of the internet.
For enterprise teams, WordPress often lives in the marketing estate rather than the core application stack, and that is precisely why it becomes a blind spot. Corporate blogs, campaign microsites, and investor relations pages frequently run on WordPress under looser oversight than production systems. A pre-authentication RCE in core turns every one of those forgotten properties into a potential entry point into hosting environments, cloud accounts, and any credentials stored alongside them.
How the chain works
The vulnerability is tracked as CVE-2026-63030 and works by chaining two distinct weaknesses. The first is a route confusion in the WordPress REST API batch endpoint, which lets an attacker smuggle requests to internal routes in a way the framework did not intend. That confusion becomes the delivery mechanism for the second half of the chain, giving an unauthenticated caller a path to reach database functionality that should be walled off behind authentication.
The second weakness is CVE-2026-60137, a SQL injection in the author__not_in parameter of WP_Query. That class sits behind nearly every database query WordPress runs, so an injection there reaches deep into the platform. Adam Kues of Assetnote, the attack surface management division of Searchlight Cyber, reported the RCE chain, while the SQL injection was reported separately by researchers operating as TF1T, dtro, and haongo. WordPress rates the combined chain as Critical.
Which versions are affected
The full remote code execution chain affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1, with fixes delivered in 6.9.5 and 7.0.2 respectively. The underlying SQL injection also reaches the older 6.8 branch, versions 6.8.0 through 6.8.5, which received a targeted fix in 6.8.6. Administrators running any of these builds should treat an upgrade as urgent and verify that the correct patched version is actually running rather than assuming an update completed cleanly.
Recognizing the exposure, the WordPress security team enabled forced automatic updates for the affected releases, a step the project reserves for the most serious situations. Automatic updates will cover a large population of self-managed sites, yet plenty of enterprise deployments disable that mechanism to preserve change control. Those organizations carry the full burden of patching manually, and they are exactly the ones most likely to have unmonitored installs sitting quietly on the public internet.
Public exploit code changes the math
As of the July 18 update to the disclosure, no confirmed exploitation attempts had been reported in the wild. That reprieve is unlikely to last, because a separate researcher published working proof-of-concept exploit code on GitHub within a day of the advisory. Once a reliable exploit for a pre-authentication RCE is public, the barrier to entry collapses and commodity attackers begin mass-scanning for vulnerable installs. WordPress flaws with this profile have historically moved from disclosure to widespread automated abuse within days.
The severity is compounded by how trivial the attack is to launch. One researcher summarized the situation bluntly, noting the chain has "no preconditions and can be exploited by an anonymous user." With no authentication to defeat and public code available, defenders should assume that scanning is already underway and that any exposed, unpatched site is a target. The window between patch availability and opportunistic exploitation is the risk that matters most here.
What security leaders should do now
The immediate action is to inventory every WordPress instance the organization runs, including the ones that marketing, agencies, or acquired business units stood up without security involvement. Each should be confirmed as running 6.9.5, 7.0.2, or 6.8.6, and any site that cannot be updated promptly should be taken offline or shielded behind a web application firewall rule that blocks the malicious REST API batch requests. Cloudflare and other providers have already shipped protections for this class of attack.
Because a successful exploit yields code execution, patching alone does not resolve an install that may already have been hit. Teams should review web server and application logs for anomalous REST API batch requests and for signs of database tampering or dropped web shells. Where an install was internet-facing and unpatched during the exposure window, the safer assumption is compromise, which means rotating database credentials, checking for unauthorized administrator accounts, and validating the integrity of the underlying host.
The core versus plugin blind spot
Most WordPress security guidance fixates on plugins, and for good reason, since the plugin ecosystem produces a steady stream of vulnerabilities. wp2shell breaks that mental model because the flaw lives in core itself, in code that ships with every installation and cannot be removed by pruning add-ons. Organizations that felt safe because they run a minimal, plugin-light configuration are directly in scope, which upends a common risk assumption held by lean web teams.
The broader lesson is about ownership and visibility. WordPress properties tend to accumulate across an enterprise without a single accountable owner, and a core-level pre-authentication RCE exposes the cost of that drift. We think this event is a prompt to bring every content management deployment under the same asset inventory, patch cadence, and monitoring discipline applied to production applications. Treating the marketing site as out of scope is a decision attackers are happy to exploit.
