An anonymous HTTP request can run code on a stock WordPress site. No login, no plugin, no precondition. The bug lives in WordPress Core itself, and public proof-of-concept exploits are already circulating on GitHub. Security firm watchTowr says it is seeing the first signs of in-the-wild exploitation. If you run any WordPress site on version 6.9 or 7.0, the clock is already running.
wp2shell is a pre-authentication remote code execution chain in WordPress Core. Two CVEs let anonymous attackers run code on 6.9 and 7.0 sites with no plugins.
WordPress pushed forced automatic updates on July 17, 2026, but you should not assume that mechanism reached every site you operate. Here is what happened, what is exposed, and what to do in the next hour.
What exactly is the wp2shell attack chain?
The wp2shell attack chains two independent flaws to achieve remote code execution from a single unauthenticated HTTP request. Adam Kues at Searchlight Cyber discovered the chain and reported it to WordPress.
The first flaw, CVE-2026-63030, is a REST API batch-route confusion vulnerability introduced in WordPress 6.9. The WordPress REST API accepts batch requests, and the routing logic can be confused into processing a request in a way that reaches a vulnerable code path. Cloudflare reported that this code path can be reached specifically when a persistent object cache is not in use, which describes a large fraction of default WordPress installs.
The second flaw, CVE-2026-60137, is a SQL injection vulnerability in the author__not_in parameter of WP_Query. The GitHub advisory classifies it as high severity and notes it affects WordPress 6.8 and later. On its own, the SQL injection lets an attacker extract data from the database. Combined with the REST API confusion bug, it becomes a path to remote code execution.
The chain works like this: an attacker sends a crafted batch request to the REST API endpoint. The route confusion bug routes it to a query handler that passes unsanitized input into WP_Query. The SQL injection executes. Some public PoC exploits use the SQL injection to extract WordPress password hashes, crack an administrator password, log in, upload a malicious plugin, and run commands. Other PoC exploits claim to achieve RCE without any administrator credentials at all, which aligns with Searchlight Cyber's description of the attack.
The Rapid7 analysis notes that WordPress Core is an open-source project, and given the current ability of AI models to analyze open-source code, a public PoC was always likely to appear quickly. That prediction came true within days.
Which WordPress versions are vulnerable and how big is the blast radius?
The full RCE chain affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. The SQL injection alone also affects WordPress 6.8.0 through 6.8.5, but those versions cannot be chained to RCE because the REST API batch-route confusion bug was introduced in 6.9.
| WordPress branch | Affected versions | Vulnerability | Fixed version |
|---|---|---|---|
| 6.8.x | 6.8.0 to 6.8.5 | SQL injection only | 6.8.6 |
| 6.9.x | 6.9.0 to 6.9.4 | Full RCE chain | 6.9.5 |
| 7.0.x | 7.0.0 to 7.0.1 | Full RCE chain | 7.0.2 |
| 7.1 beta | Affected beta versions | Full RCE chain | 7.1 Beta 2 |
Searchlight Cyber estimates that more than 500 million websites run WordPress. Not all of those run 6.9 or 7.0, but the number is still enormous. Any site that upgraded to 6.9 or 7.0 for performance or feature reasons in the months before this disclosure is in the blast zone.
The chart below shows the vulnerable point releases by branch, broken down by whether they are exposed to the full RCE chain or only the SQL injection component.
The CVSS score assigned so far is 7.5, though Rapid7 notes that the GitHub advisory classifies the severity as Critical. The score may be revised as the full technical details emerge. What matters operationally is the attack path: unauthenticated, remote, default configuration, no plugins required.
Are attackers already exploiting this in the wild?
Yes. watchTowr CEO Benjamin Harris told BleepingComputer that his team is beginning to see the first signs of in-the-wild exploitation after public proof-of-concept exploits appeared on GitHub.
The exploitation timeline compresses to hours. The GitHub advisory went public on July 17. Public PoC code appeared within a day. watchTowr reported in-the-wild activity shortly after. The chart above shows how fast the window between disclosure and exploitation closed.
WordPress enabled forced automatic security updates for supported installations running affected versions. If your site has automatic updates enabled and is on a supported branch, it may have already patched itself to 6.9.5 or 7.0.2. But auto-updates fail silently for a long list of reasons: filesystem permissions, version constraints in managed hosting, custom update-blocking configurations, or simply a site that has been neglected long enough to fall off the supported branch.
You cannot assume the auto-update worked. You have to verify.
What should I do right now to protect my WordPress sites?
The fix is straightforward. The execution is where teams fail.
-
Inventory every WordPress install you operate. This includes marketing sites, landing pages, legacy blogs, and that one site the intern set up three years ago. Check every domain you own. Attackers will find the one you forgot about.
-
Update to the fixed version for your branch. That is 6.9.5 for the 6.9 branch, 7.0.2 for the 7.0 branch, and 6.8.6 if you are on 6.8. The WordPress advisory recommends immediate updates.
-
If you cannot update immediately, block the attack path at the WAF. Searchlight Cyber recommends blocking
/wp-json/batch/v1and?rest_route=/batch/v1at the WAF level. Both patterns must be blocked. Blocking only one leaves the other open. Cloudflare has deployed WAF rules for both CVEs across all plans, including free accounts, but only for traffic proxied through Cloudflare. Their own guidance says WAF protections are not a substitute for patching. -
Alternatively, disable the REST API entirely. Searchlight suggests installing a plugin like Disable WP REST API to block unauthenticated access to the WordPress API. This is the simplest mitigation but carries a risk of breaking existing functionality that depends on the REST API.
-
Verify that auto-updates actually applied. Do not take the dashboard at face value. Check the version number directly. Log into each site and confirm it reads 6.9.5, 7.0.2, or another fixed release.
-
Check for signs of compromise. If you ran a vulnerable version and the site was internet-facing, assume it may have been hit. Look for unexpected admin accounts, unfamiliar plugins, modified core files, and new scheduled tasks. The SQL injection component means an attacker may have extracted password hashes even if they did not achieve RCE. Rotate all administrator passwords.
If you want to test whether a site is vulnerable, Searchlight Cyber set up wp2shell.com as a checker tool. Run it against your installs before and after patching.
Why does this one matter more than the usual WordPress vulnerability?
WordPress gets a steady stream of plugin and theme vulnerabilities. A core, unauthenticated RCE in a default install with no plugins is a different category of problem. Harris told BleepingComputer that a highly impactful, unauthenticated SQL injection or remote code execution vulnerability in WordPress core is actually fairly rare, which is exactly why the response has been this aggressive.
Two things make this worse than a typical WordPress bug. First, the attack surface is the REST API, which is enabled by default and exposed on every WordPress site. There is no configuration change a site owner would have made that turns it off. Second, the SQL injection component reaches back to 6.8, meaning sites that thought they were safe because they had not upgraded to 6.9 still have a data exposure problem. The RCE chain does not work on 6.8, but credential theft via SQL injection does.
For teams running WordPress at scale, this is also a reminder that auto-updates are a safety net, not a patching strategy. The same way you would not rely on a single backup, you should not rely on a single update mechanism. If you operate more than a handful of WordPress sites, you need a process that inventories, patches, and verifies. The next core RCE may not come with forced auto-updates.
This is also a story about open-source supply chains. The code was public, the vulnerability was in code that AI models can read and reason about, and the PoC appeared within days. Rapid7 flagged this pattern explicitly. Expect the time-to-PoC for open-source vulnerabilities to keep shrinking as AI-assisted exploit development matures. The same dynamic that makes AI coding agent supply chain attacks a real risk applies here: the tools that help you ship faster also help attackers weaponize faster.
The version you are running is the only fact that matters
WordPress has shipped the fix. The forced auto-update is live. Public exploits are out. In-the-wild exploitation has started. Go verify that every site you operate is running 6.9.5, 7.0.2, or another fixed release. Do it now, because the attackers already have the exploit code and the list of vulnerable sites is long.
