On Friday, July 17, the WordPress security team quietly shipped two emergency releases. Behind them was one of the most serious vulnerabilities WordPress core has seen in years: a flaw that let a completely anonymous attacker run their own code on a WordPress site. No password. No stolen login. No vulnerable plugin. Just a crafted web request sent to a stock WordPress install.
By the end of that same day, every site we manage was patched and verified.
Here’s what happened, why this one was different, and what it says about how website security actually works in 2026.
What is wp2shell?
The vulnerability, nicknamed wp2shell by Assetnote, the security research team that discovered it, is what the industry calls a pre-authentication remote code execution flaw. Translated: an attacker who has never touched your site, has no account, and knows nothing about your setup can send a request that executes code on your server.
That’s about as bad as web vulnerabilities get. Once an attacker can run code, your site is effectively theirs. They can steal customer data, plant malware, redirect your visitors, or quietly use your server for their own purposes.
Two things made wp2shell stand out from the usual stream of WordPress security news:
It was in WordPress core itself. The overwhelming majority of WordPress compromises come through third-party plugins and themes. This flaw lived in WordPress’s own REST API: a confusion in how its batch endpoint routed requests, chained with a SQL injection. A bare WordPress install with zero plugins was exploitable.
It flew under the radar of standard tooling. At the time of the patch, the vulnerability had no CVE identifier and no CVSS score, the standardized labels that security scanners and inventory tools use to flag known issues. Any monitoring that keys off CVE databases simply couldn’t see this one. The only reliable way to know whether a site was safe was to check the actual version it was running.
Who was affected
The vulnerable code shipped in WordPress 6.9 (released December 2025), which means:
- WordPress 6.9.0 – 6.9.4 → fixed in 6.9.5
- WordPress 7.0.0 – 7.0.1 → fixed in 7.0.2
If your site was on any release in those ranges, it was exposed. WordPress did enable forced automatic updates to push the fix, but auto-updates can be disabled, delayed by hosting configurations, or silently fail. The WordPress team itself has been careful not to promise the forced push reached everyone. “It probably auto-updated” is a hope, not a security posture.
How we responded
This is where a real maintenance process earns its keep.
When the advisories landed, we didn’t have to scramble to figure out what we were running. Our maintenance program means we keep a live picture of every site under management: hosting environment, WordPress version, update configuration, all of it. So the response looked like this:
- Identify. Within minutes of the disclosure, we knew exactly which of our sites fell in the affected version ranges. Not “probably.” Not “we’ll audit next week.” A complete list, immediately.
- Patch. We applied the fixed releases across every affected environment. Same day, every site.
- Verify. We didn’t trust auto-updates to have done the job. We confirmed the running version on each site directly, because the difference between “the update was released” and “the update is actually running on your server” is exactly the gap attackers live in.
No client had to call us. No one had to forward us a scary headline. By the time most site owners were reading about wp2shell, our clients’ sites were already patched.
The uncomfortable truth about the window
Here’s the part that should stick with every website owner: the researchers who found this flaw are deliberately withholding the technical details to give the world time to update. But WordPress is open source. The patch itself is public, and skilled attackers routinely reverse-engineer fixes to reconstruct the underlying bug, sometimes within a day of release.
That means every unpatched site is now in a race it doesn’t know it’s running. Mass exploitation of WordPress is a genuine industry: earlier this summer, a single already-patched plugin flaw was used to compromise more than 17,000 sites. And that bug required a non-default setting. wp2shell requires nothing at all.
The sites that get hurt by vulnerabilities like this are almost never the ones patched on day one. They’re the ones patched on day forty, or never.
What this means for your website
If you manage your own WordPress site, do this today: log in, check your version, and make sure you’re on 6.9.5 or 7.0.2 (or later). Don’t assume auto-updates handled it. Confirm it.
And if that sentence made you realize you don’t know what version your site is running, or who would have checked, that’s the real lesson of wp2shell.
Website security isn’t a product you install. It’s a process: knowing what you’re running, watching for what’s coming, and moving fast when it matters. That’s what managed maintenance is. Most months, it looks like routine updates and quiet reports. On days like July 17, it looks like the difference between a same-day patch and an open door.
Our clients didn’t have to think about wp2shell at all. That’s the whole point.
Want your site covered before the next one? Learn more about our managed maintenance plans, or reach out. We’re happy to check what version you’re running right now.
