wp2shell: unauthenticated RCE in WordPress

WordPress runs a large share of the public web, which makes a pre-auth remote code execution bug in core — not a plugin, core — a different class of problem from the weekly plugin advisory. The "wp2shell" chain (CVE-2026-63030 and CVE-2026-60137) is being actively exploited to install persistent webshells and malicious plugins, and it was added to CISA's Known Exploited Vulnerabilities catalog on 21 July 2026. If you run WordPress anywhere on your estate — including that marketing microsite nobody has logged into since 2024 — this is a same-day patch.

Description of the vulnerability

wp2shell is a chain, not a single bug, and that is why it slipped past individual severity triage. CVE-2026-63030 carries a CVSS base score of only 7.5; the chain's real impact is full site takeover.

Link one — desynchronisation in the batch endpoint. The REST API batch processor at /wp-json/batch/v1 validates requests in one loop and executes them in a second loop. Because the two loops walk their arrays independently, a crafted batch can desynchronise them, so a request gets dispatched under a handler other than the one it was validated against.

Link two — SQL injection in the posts endpoint. A separate flaw in the author__not_in parameter (CVE-2026-60137) is not reachable on its own, because parameter validation stops it. Sent through the desynchronised batch processor, that validation never runs.

Chained, an unauthenticated attacker reaches WordPress internals directly, creates an administrator account, logs in, and uploads a plugin — which is simply how you get code execution on WordPress once you are an admin. No credentials, no user interaction, no phishing step.

Affected: WordPress 6.9.0–6.9.4, 7.0.0–7.0.1, and 7.1 beta builds.

Resolution steps

1. Upgrade core now. Patched releases are 6.9.5, 7.0.2, and 7.1 Beta 2. Auto-updates cover many sites, but not sites pinned by a deployment pipeline or managed host — verify the running version rather than assuming.
2. If you cannot patch this hour, block the endpoint. Deny /wp-json/batch/v1 at the WAF or reverse proxy. This is a stopgap, not a fix — the SQL injection remains reachable if another path to it appears.
3. Restrict anonymous REST API access. Most business sites have no reason to expose write-capable REST routes to unauthenticated visitors at all.
4. Assume compromise if the site was internet-facing and unpatched. Patching removes the bug; it does not remove an attacker who already got in. Hunt before you declare it closed.
5. Hunt for the artefacts: anomalous requests to the batch endpoint in HTTP access logs, administrator accounts you did not create, plugins nobody recognises, and files modified under wp-content/ outside a deploy window.
6. Rotate credentials and salts on any site that shows those artefacts, and rebuild from a known-good source if a webshell is found. A webshell is a persistence mechanism; deleting the file it dropped is rarely the whole cleanup.

Conclusion

wp2shell is a reminder that CVSS is a component score, not a priority order. A 7.5 that chains into unauthenticated site takeover outranks a lonely 9.0 on a service nobody can reach. Two things decide your exposure here: whether you know every WordPress instance you own, and how fast you learn that a patch exists. Both are inventory problems long before they are patching problems — and the sites that get hit are almost always the ones no team remembered was still running.

CyberSpec scans your public attack surface continuously and maps what it finds to the assets you actually own, so a forgotten CMS shows up as a finding rather than as an incident.