WordPress just forced an emergency security update: what to do about wp2shell

Yesterday WordPress pushed an emergency security release and turned on forced automatic updates for millions of sites. That only happens for the worst category of flaw. This is that category.

One of the two bugs patched on 17 July 2026 lets an anonymous attacker - no login, no plugin, nothing unusual about your setup - run their own code on a default WordPress install. Remote code execution is the top of the severity scale: a successful hit hands the attacker control of the site. And the proof-of-concept exploit code is already public, which means the window between “disclosed” and “actively scanned for” is measured in hours, not weeks.

The good news: it is fixable in one step, and you may already be safe depending on your version. Here is exactly whether you are affected and what to do about it. We run maintenance and care plans for a living - 5,000+ support tasks in the last 18 months - so this is the same triage we ran across every WordPress site we look after the moment the advisory landed.

What actually happened

WordPress disclosed two separate vulnerabilities on 17 July 2026. On their own each is serious; chained together they are the emergency.

CVE	Type	Severity	Where it lives
CVE-2026-63030 (“wp2shell”)	Unauthenticated remote code execution	Critical	Route confusion in the REST API batch endpoint (/wp-json/batch/v1)
CVE-2026-60137	SQL injection	High	The author__not_in parameter of WP_Query, the class behind almost every database query WordPress runs

The researchers who found the chain named it wp2shell. In plain terms: the REST API bug lets an unauthenticated request reach places it should not, and the SQL injection lets that request bend a database query. Put together, an attacker who has never logged in can get code running on the server. No user interaction, no credentials, no exotic configuration - it works against a stock install where a persistent object cache is not in use, which is the default for most sites.

That “default install is exploitable by an anonymous HTTP request” is what moves this from a routine Tuesday patch to a forced update. WordPress is treating it as its highest-priority class of issue.

Are you affected?

This is the part worth reading carefully, because the answer is not “everyone.”

• The critical RCE (wp2shell) only exists in WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. The vulnerable code shipped with 6.9 in December 2025. If you are on an older branch, this specific bug is not in your codebase.
• The SQL injection reaches further back: WordPress 6.8 and later. High severity on its own, and it is the second half of the chain.
• Anything older than 6.8 is not affected by either flaw. (Though if you are running WordPress older than 6.8 in July 2026, you have a different and larger security problem - dozens of unpatched issues have piled up in the meantime.)

So the honest read: if you are on a current 6.9 or 7.0 site, you are in the blast radius of the critical one and hours matter. If you are on 6.8, patch the SQL injection promptly. If you are somehow below 6.8, this advisory is your cue to deal with a long-overdue update, carefully.

What to do right now

One step, done properly:

1. Update WordPress core to the fixed release for your branch:

   • On 7.0.x → 7.0.2
   • On 6.9.x → 6.9.5
   • On 6.8.x → 6.8.6

   Each ships the fix for that branch. You do not need to jump major versions; the backport covers you.

2. Confirm it actually applied. WordPress.org enabled forced automatic updates for affected versions, so a lot of sites will patch themselves overnight. But “should auto-update” and “did” are different things - sites with WP_AUTO_UPDATE_CORE disabled, file permissions locked down, or a managed host that controls updates will not follow the default. Log in, open Dashboard → Updates, and read the version number with your own eyes.

3. If you manage more than a handful of sites, do not click through them one at a time hoping. Check each one’s actual running version. This is exactly the kind of fleet-wide “did every site get the patch, yes or no” question that gets missed when nobody owns it.

Take a backup before a major update as a habit, but do not let backup-taking delay a critical security patch on a live site. With a public-PoC RCE, the update is the emergency; the backup is hygiene.

Will automatic updates and a firewall save you?

Partly, and it is worth being precise about the gaps.

Automatic updates are genuinely helpful here - WordPress forcing them is why this will not be as bad as it could have been. But they are not universal. Managed hosts, hardened installs, and sites where a previous developer disabled auto-updates “to stay in control” will sit unpatched until a human acts. The forced rollout reduces the population at risk; it does not empty it.

A web application firewall (Cloudflare and others) buys time, not immunity. Cloudflare deployed WAF rules for both CVEs on 17 July 2026 at 17:03 UTC across every tier, and says it directly: the rules “reduce exposure while customers update, but they are not a substitute for patching.” Firewall rules match known attack shapes; attackers reshape the payload. The patched code is the only thing that closes the hole for good. Use the firewall as the safety net that covers the hours between disclosure and your update - not as the reason to skip the update.

How to tell if you were already hit

Because working exploit code is public, an unpatched, affected site should be treated as possibly probed - not just possibly vulnerable. Updating stops future exploitation, but it does not undo an intrusion that already happened. If your site ran an affected version exposed to the internet for any real length of time before patching, look for:

• Admin users you do not recognise
• New or recently modified PHP files, especially anything dropped into wp-content/uploads (that folder should hold media, not code)
• Scheduled tasks (WP-Cron entries) you did not create
• The site sending spam, or your host flagging malware
• Unexplained changes to core files

If any of that shows up, applying 7.0.2 is not the end of it - a backdoor left behind survives the update. That is a clean-up job, and the honest advice is to get someone who does incident response to look rather than assume the patch closed the door behind an attacker who was already inside. That is what our rescue and recovery work exists for.

Who is watching your site at 2am

Here is the uncomfortable version of this story: the fix was one step, and it was available within hours of disclosure. The sites that get hurt are not the ones that couldn’t patch - they are the ones where nobody was watching, nobody saw the advisory, and the update sat undone for a week while the site quietly stayed open.

Most WordPress sites are not breached by clever attackers. They are breached by neglect - an update nobody applied, a version nobody checked. A security advisory like this one is not really a technical problem; it is an ownership problem. Someone has to be responsible for seeing it and acting on it, on every site, the same day.

That is the entire job of a maintenance plan: core, theme and plugin updates run and verified on a schedule, an actual person watching the security feed, and a same-day response when something like wp2shell lands. If you want to see what that covers in practice, we wrote up exactly what a monthly WordPress maintenance plan includes.

If nobody currently owns “is every one of our WordPress sites patched today,” that is the gap to close - whether you close it yourself or hand it to us. The next forced update will come. The question is only whether someone is there to catch it.

---

We keep WordPress sites patched, monitored and current for businesses and for other agencies across Europe. If this advisory left you unsure whether your site is safe, a care plan makes it someone’s explicit job. Already seeing signs something is wrong? That is a rescue call, and sooner is better.