Okay, so if you run anything on WordPress, or manage servers for people who do, you've probably already seen this name floating around: wp2shell. It's been viral in every infosec feed for the past few days, and if you haven't patched yet, stop reading in about two minutes and go do that first. I'll wait.
Here's one guide by me summarising from sources how to safeguard
Back? Good. Let's actually talk about what this thing is, because most of the coverage I've seen either buries the interesting part under fifteen paragraphs of CVE numbers, or oversimplifies it into "WordPress bad, update now" without explaining why this one is actually worth your attention.
So what actually happened here
On July 17, WordPress quietly shipped 6.9.5 and 7.0.2. Nothing unusual about a point release — except this one came with forced background updates turned on, which WordPress basically never does unless something is genuinely on fire. And something was.
A researcher named Adam Kues, working under Searchlight Cyber's Assetnote arm, had found a way to get remote code execution on a completely default WordPress site. No plugins. No theme customizations. No login. Just an anonymous HTTP request against a fresh install, and you're running code on someone's server. That's about as bad as it gets for a CMS that a huge chunk of the internet runs on.
He did the responsible thing — reported it quietly through HackerOne, gave WordPress time to patch, and didn't publish exploit details right away. Instead his team put up a little checker site (wp2shell.com) so admins could test if they were exposed without anyone needing to hand out a working exploit to the entire internet. Genuinely good disclosure hygiene, and worth calling out because it doesn't always go that way.
Why "wp2shell" and not just a CVE number
Because it's not one bug, it's two, chained together — and the chaining is what makes it dangerous.
Bug one lives in the REST API's batch endpoint (/wp-json/batch/v1), which has been sitting there, enabled by default, since 2020. Turns out the code validates requests and then executes them in two separate steps, and that gap between "checking" and "doing" is exactly the kind of seam attackers love. That's CVE-2026-63030.
Bug two is a SQL injection tucked into WP_Query — specifically how it handles the author__not_in parameter. WP_Query is about as core as core gets in WordPress; it's the thing behind almost every database call the CMS makes. On its own, this lets someone pull data out of the database, including password hashes. That's CVE-2026-60137.
Neither of those alone gets you a shell. Chained together, though, they do. You use the route confusion to reach code you shouldn't be able to reach, use the injection to leverage database access, and the end result is code execution on the server with zero credentials. Hence, "WordPress to shell." wp2shell.
Who's actually affected
If you're on anything from 6.9.0 to 6.9.4, or 7.0.0 to 7.0.1, you were sitting exposed. Fixed versions are 6.9.5 and 7.0.2. If you're still on the 6.8 branch, that's a separate story — you want 6.8.6 to close the standalone SQL injection piece, even though the full chain doesn't reach that far back.
Anything on 6.8.5 or earlier was never part of this particular mess.
Here's the part that should actually worry you
Disclosure was July 17. By the 18th through the 20th, security vendors were already confirming active exploitation in the wild. By the 21st, both CVEs landed on CISA's Known Exploited Vulnerabilities list. And the next day, Searchlight Cyber published the full technical breakdown, and public proof-of-concept code started showing up.
So the window between "this is theoretical" and "this is being actively abused" was something like 24-48 hours. That's the reality of vulnerability disclosure now — even with a responsible researcher holding back details, once WordPress ships a patch, people diff the code, figure out what changed, and reverse-engineer the bug faster than most orgs can even confirm their sites updated.
Which brings me to the thing I actually want you to take away from this post.
"Forced auto-update" doesn't mean "you're fine"
I get it, WordPress flipped the switch, sites update themselves in the background, problem solved, right? Except — managed hosting setups, staging environments, sites where someone installed a "disable auto-updates" plugin eleven months ago and forgot about it, sites where wp-config.php has auto-updates turned off for "stability" reasons... none of those get saved by the forced-update mechanism.
Go check your actual running version. Don't trust that it happened. wp-admin > Updates, or wp core version if you've got WP-CLI. It takes thirty seconds and it's the difference between "I patched" and "I assumed I patched."
If you genuinely can't update right this second — maybe there's a compatibility issue, maybe it's a change-freeze week, whatever — there are stopgaps: block anonymous access to the REST API at the WAF level, or specifically block /wp-json/batch/v1 and its query-string cousin ?rest_route=/batch/v1. Just know that'll probably break something else (the block editor, mobile apps, integrations), so treat it as a bandage, not a fix.
I menttioned more on this on the above post. Do check out.
the bigger point buried in all this
We spend so much energy auditing plugins because that's historically where WordPress compromises come from some abandoned plugin nobody updated since 2019. wp2shell is a good reminder that core itself isn't immune, and when core breaks, it doesn't matter how careful you were about plugin hygiene. Every default install in that version range was exposed, full stop.
Patch your version, verify it actually took, and if you were in the blast radius, assume compromise until you've checked. That's really the whole post.
Written off public reporting from SecurityWeek, The Hacker News, Rapid7, Strobes, Hadrian, SOCRadar, and Korben, current as of July 22-23, 2026. If you're reading this later, double-check the CVE status — it moves fast.
Top comments (0)