Most WordPress security advice fits in one sentence: keep your plugins updated, because that is where the bugs live. wp2shell breaks that model. The vulnerability chain, found by Adam Kues of Assetnote (Searchlight Cyber) and patched on July 17 in WordPress 6.9.5 and 7.0.2, sits in WordPress core. A bare install with zero plugins is exploitable, and the researchers describe the attack as having "no preconditions" — an anonymous HTTP request ends in code execution on the server.
What we know
wp2shell is two bugs chained together, both now carrying CVE IDs: CVE-2026-63030, a batch-route confusion in the REST API, and CVE-2026-60137, a SQL injection in WordPress core. The entry point is the REST batch endpoint (/wp-json/batch/v1) — a feature WordPress has shipped since version 5.6 and documented publicly ever since. Chained, the two take an anonymous request all the way to remote code execution.
The affected ranges are 6.9.0 through 6.9.4 (fixed in 6.9.5) and 7.0.0 through 7.0.1 (fixed in 7.0.2). The flawed code only exists from 6.9 onward — released December 2025 — so this is not a decade-old bug, but 6.9 and 7.0 are precisely the versions well-maintained sites run. WordPress considered it serious enough to enable forced updates through its auto-update system, something it reserves for the worst cases.
Since disclosure, events have moved fast: the full mechanism has been published and a working proof-of-concept is public on GitHub. The window between "patch available" and "exploit available" — the only head start defenders had — is already gone.
Why this matters beyond your marketing site
It is tempting to file WordPress issues under "marketing's problem." Resist that. In most organizations WordPress runs the corporate site, the careers page, a landing-page farm, maybe an intranet — often on infrastructure that shares DNS, TLS certificates, credentials or a hosting account with things that matter more. Code execution on that server is a foothold: good enough to phish your customers from your own domain, poison SEO, steal form submissions, or pivot further.
There is also precedent for what happens next. The WP-SHELLSTORM crew compromised more than 17,000 sites through a single caching-plugin flaw that was already public and already patched. Mass exploitation of WordPress is an industry; a pre-auth core RCE with a public PoC is its ideal input.
What to check today
- Verify the version actually running. WordPress pushed forced updates, but has not said whether the push reaches sites that disabled auto-updates. Do not assume it landed — check. That includes staging clones, forgotten subdomain installs and anything an agency manages for you.
- If you cannot update immediately, block anonymous access to the batch endpoint — and block both routes:
/wp-json/batch/v1and the query-string variantrest_route=/batch/v1. A WAF rule covering only the first path leaves the second open. Disabling the REST API for unauthenticated users, or using the short drop-in plugin the researchers published, are alternative stopgaps.
- Review logs for
batch/v1traffic. Requests to the batch endpoint from unauthenticated sources — especially since July 17 — deserve a look. With a PoC public, scanning is a matter of when, not if.
- Inventory your WordPress estate. Most organizations that get burned by WordPress are burned by the install they forgot they had. If you cannot list every WordPress instance on your domains in five minutes, that is finding number one.
The bigger lesson: "core is safe" was an assumption, not a fact
Every web stack carries assumptions nobody tests: core is audited, the REST API is harmless, that endpoint is authenticated. wp2shell — like this year's anonymous SQL injection in Drupal core — is a reminder that these assumptions have expiry dates. This is exactly where a web application penetration test earns its keep: not just running a scanner over your plugins, but probing the REST surface, the authentication boundaries and the assumptions underneath the CMS — including the installs you forgot about. Paired with a recurring vulnerability assessment, it also gives you the inventory that turns "are we affected?" from a fire drill into a lookup.
If WordPress is anywhere in your organization — even "just the website" — and you are not certain every instance is patched and every batch endpoint is closed, talk to us. Checking takes far less time than cleaning up.
This article is general information based on public reporting by WordPress.org, Searchlight Cyber/Assetnote and The Hacker News, not incident-response advice for a specific environment.