Yesterday WordPress shipped 7.0.2 and 6.9.5 to fix wp2shell (CVE-2026-63030), a pre-authentication remote code execution flaw in core. WordPress.org force-pushed the update, Cloudflare deployed WAF rules within hours, and in theory most sites are already safe.
“In theory” is doing some heavy lifting there. Forced updates don’t reach every site, a WAF rule is not a patch, and a patch applied today says nothing about what happened before it landed. This post covers the three questions that actually matter now: are you patched, why you might not be, and how to tell whether anyone got in.
First, confirm you’re actually patched
Don’t assume, check. A patched site is running 7.0.2, 6.9.5 or 6.8.6. Anything else in the 6.9 or 7.0 branches is exposed.
- In the dashboard: the At a Glance widget on the main dashboard screen, or Dashboard → Updates.
- On the command line:
wp core versionif you have WP-CLI access. - Externally: the researchers’ checker at wp2shell.com will test a URL without needing login access, useful for sites you look after but don’t administer daily.
Then check the sites you’ve forgotten about: staging copies, development subdomains, that dormant site still sitting in a subfolder from a 2022 rebuild. Attackers do not care that it’s “just staging”, and on shared hosting a compromised neighbour can become everyone’s problem.
Why your site might not have auto-updated
WordPress.org pushed this update to affected sites, but forced pushes fail silently in more configurations than most people realise:
- Updates disabled in wp-config.php.
AUTOMATIC_UPDATER_DISABLEDorDISALLOW_FILE_MODSset to true, orWP_AUTO_UPDATE_COREset to false. Often added years ago for a good reason nobody remembers. - Version control in the install. WordPress skips core auto-updates when it detects a
.gitor.svndirectory, on the assumption that deployments are handled elsewhere. If your deployment pipeline doesn’t actually handle them, nothing does. - Managed hosts on their own schedule. Some hosts disable WordPress’s updater and roll patches out themselves. Usually fast for something this severe, but confirm rather than hope.
- File permissions. If the web server can’t write to core files, the updater fails quietly.
- No traffic. Background updates run off wp-cron, which fires on page visits. A site nobody visits can’t update itself, which is its own kind of warning.
If any of these apply, update manually today, then decide deliberately who owns updates for that site going forward. “Nobody, silently, since 2023” is the answer this vulnerability was built to punish.
The Cloudflare and object cache detail
Two mitigating factors worth knowing about, neither of which replaces the update.
Cloudflare WAF rules covering wp2shell went live at 17:03 UTC on 17 July for every plan, including free, provided your traffic is actually proxied through Cloudflare (orange cloud, not grey). That bought a lot of sites breathing room. It is a seatbelt, not a fix.
Persistent object caching. The official CVE description scopes exploitation to sites where a persistent object cache is not in use. If you’re running Redis or Memcached, you appear to be out of the direct line of fire. Treat that as a bonus rather than immunity: the full technical details are still withheld, and “appears unexploitable” has a poor track record as a security strategy. It is, however, one more reason to run an object cache, something we’d recommend for performance anyway.
How to check whether anyone got in
The vulnerable code shipped with WordPress 6.9 in December 2025, but the flaw was privately reported and no exploitation has been seen in the wild at the time of writing. The window that matters is the gap between public disclosure on 17 July and the moment your site was patched. If that gap was minutes, relax. If it was longer, or you can’t say, run through this list:
- Access logs. Look for POST requests to
/wp-json/batch/v1orindex.php?rest_route=/batch/v1. Legitimate anonymous traffic to the batch endpoint is rare; anything unexplained deserves a closer look. - Core file integrity.
wp core verify-checksumscompares every core file against the official release and flags anything modified or added. - Admin accounts. Review Users → Administrators, or
wp user list --role=administrator. Anything you don’t recognise is a red flag, not a curiosity. - PHP where it shouldn’t be.
wp-content/uploadsshould contain no PHP files at all. Any that are there were put there by someone. - Scheduled tasks and mu-plugins. Attackers like persistence. Check
wp-content/mu-pluginsfor files you didn’t install and review scheduled events withwp cron event list.
Two caveats. Logs rotate, so absence of evidence is weaker than it sounds. And if you find anything that looks wrong, resist the urge to start deleting: take a full snapshot first so there’s something to investigate, then get help. We’ve written about what a professional cleanup involves and costs, and the short version is that it’s cheaper when the evidence still exists.
Hardening beyond this patch
wp2shell will not be the last core vulnerability. The sites that shrug off the next one share a few habits:
- Minor auto-updates left on. This release is exactly the scenario they exist for. If you disabled them, have a reason you can say out loud.
- A WAF in front of the site. Cloudflare’s free tier covered this vulnerability within hours of disclosure. That is remarkable value for a DNS change.
- A persistent object cache. Faster site, and in this instance an accidental mitigation.
- A smaller attack surface. Fewer plugins, actively maintained ones, and anonymous REST API access restricted if nothing on the site uses it (test first: some form and block plugins do).
- Tested backups stored off the server. A backup sitting on the compromised machine is a souvenir, not a recovery plan.
The uncomfortable takeaway
As core vulnerabilities go, wp2shell is the good scenario: privately reported, patched before details were published, force-pushed by WordPress.org, and covered by WAF vendors the same afternoon. The system worked.
The sites that get hurt by events like this are the ones nobody is watching: auto-updates silently off since a migration years ago, no logs, no named owner. That describes an uncomfortable number of charity and small organisation websites, because lean teams have better things to do than read security advisories on a Friday night. Closing that gap is precisely what our WordPress support and maintenance plans are for; our clients on those plans were patched before most people had heard the word wp2shell.
If you’re not sure which category your site falls into, that’s usually the answer. Get in touch via our contact page or book a discovery call and we’ll take a look.
wp2shell FAQ
What is wp2shell?
wp2shell (CVE-2026-63030) is a critical pre-authentication remote code execution vulnerability in WordPress core, chaining a REST API batch route confusion with SQL injection. It was fixed on 17 July 2026 in WordPress 7.0.2 and 6.9.5. Full background in our advisory.
Which WordPress versions are affected?
WordPress 6.9.0 – 6.9.4 (fixed in 6.9.5) and 7.0.0 – 7.0.1 (fixed in 7.0.2). Versions before 6.8 are not affected. WordPress 6.8 is affected by a separate SQL injection issue fixed in 6.8.6.
Auto-updates are on. Do I need to do anything?
Verify the version anyway. Forced updates fail silently on sites with updates disabled in configuration, version-controlled installs, restrictive file permissions or very low traffic. Checking takes thirty seconds.
Does Cloudflare protect me from wp2shell?
Cloudflare deployed WAF rules for this vulnerability at 17:03 UTC on 17 July 2026 across all plans, if your traffic is proxied through them. It reduces exposure while you update. It is not a substitute for updating.
Has wp2shell been exploited in the wild?
No exploitation had been reported at the time of writing, and the researchers are withholding full technical details. That will not last forever, which is why patching promptly matters.
What if I can’t update yet?
Block anonymous access to the batch endpoint (both /wp-json/batch/v1 and the ?rest_route=/batch/v1 form) at your firewall, or use the researchers’ drop-in mitigation plugin from wp2shell.com. Stopgaps only; the fix is the update.
