On July 17, 2026, WordPress shipped a patch for a bug that let an attacker take over a site with no password, no plugin, and no click from anyone. Researchers are calling it wp2shell.
I've done enough WordPress work to have gone numb to "critical vulnerability" headlines. Most of them turn out to be some plugin nobody actually installed. This one's different, and if you run a WordPress site, it's worth five minutes of your attention.
I'll walk you through how it actually works, because the mechanics matter more than the scary name, and then exactly what to check on your own site.
Why wp2shell is worse than the usual WordPress scare
Most WordPress vulnerabilities live in the roughly 60,000 plugins and themes built by people who don't work for WordPress. That's not a knock on plugin developers. It's just math: more code, written by more people, with less oversight, produces more bugs.
wp2shell isn't that. It sits in WordPress core, the software that runs something like 40% of the web, whether or not you've ever installed a single plugin. Security researchers found it on a default, out-of-the-box install. No third-party code required.
A plugin vulnerability affects the sites that installed that plugin. A core vulnerability affects everyone running an unpatched version, no exceptions.
How CVE-2026-63030 and CVE-2026-60137 actually chain together
wp2shell is really two bugs, each with its own CVE, that only get dangerous once you combine them.
The first, CVE-2026-63030, lives in WordPress's REST API batch endpoint, the part that lets one HTTP request bundle several smaller requests together. Internally, WordPress tracks which permission check belongs to which sub-request. When one sub-request in a batch failed to parse correctly, that bookkeeping fell out of sync, and a later request in the same batch could end up borrowing a permission result that belonged to something else entirely. An anonymous request that should have failed its permission check could sail through instead.
Cloudflare's research team added an interesting wrinkle here: the vulnerable path is easiest to reach on sites that aren't running a persistent object cache like Redis or Memcached. That's most WordPress sites by default, since persistent object caching is something you have to set up deliberately, not something that ships out of the box.
On its own, that first bug is a logic flaw. Mildly interesting, not catastrophic.
The second, CVE-2026-60137, is a SQL injection in WP_Query, the class that turns a WordPress query into an actual SQL statement. One of its parameters is supposed to arrive as a clean list of numeric IDs, sanitized before it ever touches the database. Route it through the confusion in the first bug, though, and that parameter could arrive unsanitized instead, a raw attacker-controlled string dropped straight into a query.
For what it's worth, even the severity scoring couldn't agree with itself on this one. The GitHub advisory rates CVE-2026-63030 Critical with a 7.5 base score, while NVD's own records show a 9.8 from the CVE numbering authority sitting right next to a separate 7.5 from CISA's own assessment. When the scoring bodies can't agree on a number, that's usually a sign the real-world impact depends heavily on your specific setup, which tracks with what Cloudflare found.
Chain the two bugs together and you get an anonymous visitor who can reach a SQL injection that was never supposed to be reachable without authentication, manipulate data WordPress trusts internally, and ultimately end up with a working administrator account without ever logging in. From there, installing a plugin to run arbitrary code is the easy part. That's literally what the admin panel is built to let an administrator do.
Takeaway
I'm not going to walk through the full exploit chain step by step. It's out there if you go looking, researchers have published proof-of-concept code, but there's no version of "here's exactly how to reproduce this" that belongs in a post written for site owners instead of attackers.
Which WordPress versions CVE-2026-63030 affects
Version matters a lot here.
| Version range | What's exposed |
|---|---|
| 6.8.0 – 6.8.5 | The SQL injection alone. Lower severity, still needs patching. |
| 6.9.0 – 6.9.4 | The full chain, unauthenticated remote code execution. |
| 7.0.0 – 7.0.1 | The full chain, unauthenticated remote code execution. |
The fix is version 7.0.2, 6.9.5, or 6.8.6, depending on your branch. WordPress considered this serious enough to push it as a forced automatic update, which isn't something that happens for routine bugs.
Forced doesn't mean guaranteed. I've seen plenty of hosting setups, especially ones with locked-down file permissions or custom deployment pipelines, quietly swallow an automatic update and never actually apply it. Check your real version number yourself. Don't take it on faith that the update landed.
Why this WordPress core vulnerability went from patch to active exploitation in days
Here's the part that worries me more than the bug itself.
Once WordPress shipped the patch, it took researchers roughly a day to reverse-engineer what it was protecting against and get a working proof-of-concept public. Scanning activity picked up not long after. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on July 21, a list reserved for bugs confirmed under active attack, and set a patch deadline of July 24 for federal systems. That deadline was yesterday, as I'm writing this.
For a bug like this, "we patched it" and "we're safe now" are different claims. If your site sat on a vulnerable version between July 17 and whenever you actually updated, that's a window where multiple security firms confirmed active exploitation in the wild, not a hypothetical risk.
If you can't patch immediately: what actually helps
Ideally you just patch and move on. But if you're on a locked hosting environment, a heavily customized install, or you need to test compatibility before pushing to production, here's the honest trade-off.
A web application firewall rule that blocks the malicious SQL injection pattern on the batch endpoint buys you time, and several security vendors have already published signatures for exactly that. It's fast to deploy and doesn't touch your WordPress install at all. The catch is that WAF rules are pattern matching, not a real fix. An attack that looks different enough from the current public proof-of-concept can slip past a rule tuned for it.
Blocking the /wp-json/batch/v1 route entirely at your web server or CDN is more
aggressive, and it will actually stop this specific attack path. The catch there: if anything on
your site legitimately depends on the REST batch endpoint, which some page builders and modern
plugins do, you'll break that functionality until the block comes off.
Neither replaces patching. They're what you do in the gap between "I know I'm exposed" and "I've actually updated."
What to check on your site right now
- Confirm your actual version. Log into wp-admin and check the dashboard, or if
you're comfortable with WP-CLI,
wp core versiongives you a straight answer. You want 7.0.2, 6.9.5, or 6.8.6 or newer. - If you ran an affected version for any length of time, look for signs you were already compromised. Check your Users list for an administrator account you don't recognize. Check Plugins for anything you didn't install. Check your uploads and cache directories for PHP files that have no business being there.
- If you find anything suspicious, don't just delete it and call it done. A site that's been compromised once needs an actual look before you trust it again. Otherwise you're removing the one thing the attacker left for you to notice while whatever they actually installed sits somewhere less obvious.
wp2shell FAQ
What is wp2shell?
wp2shell is the name security researchers gave to a chain of two WordPress core vulnerabilities, CVE-2026-63030 and CVE-2026-60137, that together let an unauthenticated attacker take over a default WordPress installation with no plugins involved.
Which WordPress versions are vulnerable to CVE-2026-63030?
The full unauthenticated attack chain affects WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. Sites on 6.8.0 through 6.8.5 are exposed to the SQL injection component alone, a lower-severity issue that still needs patching.
How do I know if my site is patched against wp2shell?
Check your WordPress version in the wp-admin dashboard or via WP-CLI, and confirm you're running 7.0.2, 6.9.5, or 6.8.6 or later. Forced automatic updates should have applied the fix already, but hosting configurations can silently block that, so verify the actual version instead of assuming.
Is wp2shell still being actively exploited?
Yes. Multiple security firms confirmed active exploitation within days of disclosure, and both CVEs were added to CISA's Known Exploited Vulnerabilities catalog on July 21, 2026, a designation reserved for vulnerabilities under confirmed active attack.
Who's actually watching your version number
Most WordPress site owners never think about what's running under the hood, and most of the time, that's fine. You shouldn't have to.
But "I don't need to think about it" only holds up if someone else actually is. That's the real difference between a site nobody's watching and one where somebody checked the version number the week this dropped, instead of three months from now when something's already gone sideways.
If you're not sure which one describes your site, that's exactly the kind of five-minute check I do for clients, and it's a lot cheaper before something goes wrong than after.