wp2shell
No Plugin. No Login. No Excuse.
A pre-authentication remote code execution chain in WordPress core, disclosed July 17, 2026. It works against a stock install with zero plugins — and public exploit code is already circulating. If you run 6.9.x or 7.0.x, this is a same-day patch, not a next-sprint ticket.
Field notes from someone who patches and migrates WordPress for a living.
TL;DR
If you run WordPress 6.9.x or 7.0.x, stop reading and update to 6.9.5 or 7.0.2 right now. The first in-the-wild attacks have already been reported.
01 — The Disclosure
What wp2shell Actually Is
Most WordPress security stories are plugin stories. Some abandoned form builder with 40,000 installs ships a broken nonce check, a few thousand sites get defaced, and everyone who kept their plugin count low sleeps fine.
wp2shell is not that. It lives in core.
Researchers at Assetnote — the attack-surface arm of Searchlight Cyber — reported a pre-authentication RCE in WordPress core that requires no preconditions at all. No login. No plugin. No unusual configuration. An anonymous HTTP request against a default install is enough to get code running on the server. WordPress powers an estimated 500 million websites. That is the blast radius.
It's a chain, not a single bug
Understanding the chain matters, because it determines who is exposed to what. Alone, either bug is bad. Chained, they're catastrophic.
SQL injection in WP_Query
An injection reachable through the author__not_in parameter of WP_Query, the class behind essentially every database read WordPress performs. Rated high severity — and it reaches back to WordPress 6.8.
REST API batch-route confusion
A route-confusion issue in the batch REST endpoint (/wp-json/batch/v1) — the piece that turns a bounded SQL injection into full unauthenticated code execution. Introduced in 6.9, so it does not exist on older branches.
The batch endpoint is core, enabled by default, and reachable without authentication. It also answers on the ?rest_route=/batch/v1 fallback form — so the common "I disabled pretty permalinks" assumption buys you nothing.
02 — Exposure Check
Am I Vulnerable? Check This First
| WordPress version | SQLi (60137) | Full RCE chain | Action |
|---|---|---|---|
| 7.0.0 – 7.0.1 | Vulnerable | Vulnerable | Update to 7.0.2 immediately |
| 7.0.2 | Patched | Patched | You're good |
| 6.9.0 – 6.9.4 | Vulnerable | Vulnerable | Update to 6.9.5 immediately |
| 6.9.5 | Patched | Patched | You're good |
| 6.8.0 – 6.8.5 | Vulnerable | Not chainable | Update to the latest 6.8 security release |
| Below 6.8 | Not affected | Not affected | Different, older problems |
Searchlight Cyber published a free checker at wp2shell.com that tells you whether a given install is exposed. Use it on sites you own or are authorized to test. Nothing else.
A silent scan isn't a clean scan
If you've stripped the WordPress generator version string from your HTML (good hardening, generally), any scanner reading your version off the homepage reports unknown, not vulnerable. Don't confuse the two — check the actual version in your admin dashboard or via WP-CLI.
03 — Remediation
How to Patch, Properly
The 60-second path
WordPress.org enabled forced automatic updates for affected installs given the severity, so many sites are already patched. Do not assume yours is one of them — auto-updates fail quietly on sites with restricted file permissions, DISALLOW_FILE_MODS set, version-controlled deployments, or managed hosts that pin core versions. Go and verify.
Dashboard: Log in → Dashboard → Updates. Confirm the version reads 7.0.2 or 6.9.5.
# Check what you're actually running
wp core version
# Update to the latest release on your branch
wp core update
# Verify, and confirm core files match the official checksums
wp core version
wp core verify-checksumsThat last command is the one people skip. verify-checksums compares your core files against the official WordPress.org hashes. If something was modified, you'll know.
If you genuinely can't patch today
Temporary mitigations, in rough order of preference. Treat all three as a bridge measured in hours, not a fix.
Block the batch endpoint at your WAF or edge
Both /wp-json/batch/v1 and ?rest_route=/batch/v1. Blocking only the first is a half-measure attackers already know about.
Block anonymous REST API access entirely
If your site doesn't need it. Note that the block editor uses the REST API, so test your admin workflow before shipping this.
Cloudflare users: WAF rules are already live
Rules covering both CVEs were deployed across all plans, including free ones. Cloudflare said it plainly — this reduces exposure while you update; it is not a replacement for updating.
Not sure which version you're actually on?
A version check and exposure audit costs you nothing.
04 — Incident Response
You Patched. Were You Already Hit?
Patching closes the door. It does nothing about anyone who walked in before you closed it. If your site sat on an affected version after July 17, run a compromise check.
Unknown admin users
Users → All Users, sorted by registration date. Anyone you don't recognize is a problem.
Recently modified files
Especially in wp-content/uploads/, which should never contain PHP.
Unexpected plugins
Generic names, no readme. Uploading a malicious plugin is a common post-exploitation step.
Rogue scheduled tasks
Run wp cron event list and look for jobs you didn't create.
Modified core files
Run wp core verify-checksums again — and take it seriously if it complains.
Rotate everything
If you find anything at all: DB credentials, wp-config salts, admin passwords, API keys, and SFTP / hosting-panel logins.
# PHP files changed since just before disclosure
find wp-content/ -name "*.php" -newermt "2026-07-15" -ls
# uploads/ should never contain PHP — anything here is a red flag
find wp-content/uploads/ -name "*.php" -lsOn shared hosting, one breached site is rarely the end of the blast radius. Neighboring accounts and the surrounding hosting environment are frequently part of the same incident.
05 — The Part That Isn't About wp2shell
Shared Attack Surface
Critical unauthenticated RCE in WordPress core is genuinely rare. The security team is good, and this one made headlines partly because it's unusual. Nobody should read this as "WordPress is insecure." That's lazy.
The real lesson is about shared attack surface. When a flaw lands in core, every site running that version becomes vulnerable at the same instant — regardless of how carefully it was built, how few plugins it runs, or how disciplined its owner is. Your diligence doesn't isolate you. You inherited the vulnerability the moment you inherited the framework, and 500 million other sites make the exploit worth writing.
A target that scales
A shared framework means one exploit pays off across millions of sites. That economics is exactly why mass scanners exist — and why a core bug becomes an internet-wide event within hours.
A surface that's yours
A custom Next.js site has no /wp-json/batch/v1 and no WP_Query. It has its own surface — and it's not immune to bugs — but it's smaller, yours, and not a target that scales.
That's the actual tradeoff, and it isn't a binary. WordPress remains the right call for content-heavy sites with non-technical editors and a real update discipline. It becomes the wrong call when nobody owns patching, when the plugin count creeps past twenty, and when "it's been working fine" substitutes for maintenance.
I wrote about the long-run economics of this in WordPress vs. Hardcoded — wp2shell is the security chapter of that same argument, arriving right on schedule.
The permanent fix
Patching ends the emergency. A rebuild ends the category.
Updating to 6.9.5 or 7.0.2 closes this one door. Rebuilding onto a hardcoded Next.js stack removes the door entirely — no WordPress core, no plugin soup, no /wp-json/batch/v1 for a mass scanner to find. That's the work I do: migrating WordPress sites onto custom-coded builds that stay fast, score 100 on SEO, and don't live on the internet's most-targeted CMS.
06 — Fast Answers
wp2shell FAQ
What is wp2shell?
+
Which WordPress versions are affected by wp2shell?
+
Which WordPress version fixes wp2shell?
+
Do I need plugins installed to be vulnerable to wp2shell?
+
Is wp2shell being exploited in the wild?
+
Does a WAF protect me from wp2shell?
+
How do I check if my WordPress site is vulnerable to wp2shell?
+
Tired of patching WordPress? Rebuild it once.
Update to 6.9.5 or 7.0.2 today — that's the emergency fix. But if you're done with the maintenance treadmill, the endless patch cycle, and the plugin roulette, there's a cleaner way out: a hardcoded rebuild. I migrate WordPress sites onto custom Next.js stacks that score 90+ on performance and 100 on SEO — and never ship a wp2shell-shaped attack surface again. Not sure if you were exposed or already compromised? Let's start with a free check.
Sources
- Searchlight Cyber — wp2shell: Pre-Authentication RCE in WordPress Core
- WordPress 7.0.2 Security Release
- GitHub Advisory — CVE-2026-63030
- GitHub Advisory — CVE-2026-60137
- BleepingComputer — wp2shell RCE flaws get public exploits
- The Hacker News — New wp2shell WordPress Core Flaw
- Cloudflare — WAF protections for WordPress vulnerabilities
Last updated: July 22, 2026. This is a developing story — verify version numbers against the official WordPress security releases before acting.