WordPress 7.0.2: What the Emergency Security Update Means for Your Site
On 17 July, WordPress issued an emergency security release (version 7.0.2) to fix a critical flaw in WordPress core. It was serious enough that WordPress took a step it reserves for its most serious incidents: force-pushing the update to sites automatically, whether or not the site owner had auto-updates switched on.
If your site auto-updates, you are most likely already patched. That is the reassuring part, and for most people it is true. This post is about the less reassuring part — forced updates don’t always reach every site. So rather than assume you’re covered, here’s how to make sure, and what to do if you’re not.
What actually happened
In plain terms: a critical weakness was found in WordPress core — the software itself, not a plugin or a theme — that let an attacker run their own code on a site without ever logging in. No password, no tricked administrator, no dodgy add-on required. A WordPress site simply being online and on an affected version was enough. The flaw has been nicknamed wp2shell, and it was reported responsibly by a security researcher, Adam Kues at Assetnote / Searchlight Cyber, rather than found in the wild.
Two things make it stand out. First, flaws this serious almost never live in core itself — it’s overwhelmingly out-of-date plugins and themes that get sites compromised. We wrote about exactly this in our anatomy of a WordPress hack, where core ranked as the rarest way in. This event is the honest exception. Second, it didn’t stay theoretical: according to Wordfence, attackers began probing for the flaw within hours of the patch on the evening of 17 July, and public proof-of-concept exploit code was circulating within a couple of days. That’s why WordPress forced the update — and why “probably patched” is worth taking a moment to confirm.
How to check you’re actually patched
This is a two-minute job.
- Log in to your dashboard and go to Dashboard → Updates. At the top it tells you which version you’re running. You want to see 7.0.2 — or 6.9.5 or 6.8.6 if you’re deliberately kept on an older, still-supported branch. Any of those three means the fix is in place.
- Not sure which version you’re on? The number sits quietly in the bottom-right corner of almost any admin screen. Glance there.
- Now the part most “update now” articles skip. A forced update reaches the sites that were set up to receive it. It does not reliably reach: sites with automatic updates switched off, sites deployed through version control or a managed pipeline (where the dashboard’s update button is often disabled by design), and the ones people simply forget — staging copies, subdomains, and old client or “we’ll-sort-it-later” installs. Each of those is a separate WordPress site and needs checking on its own. One patched site does not vouch for the rest.
- If you’re on an affected version, update now: Dashboard → Updates → Update Now. If something stops you — a deployment process, a plugin conflict, a site you’re not confident touching alone — that is the point to get help rather than leave it sitting exposed.
If you’d like a second opinion on a site you can’t easily log into, the researchers who disclosed the flaw published a public checker at wp2shell.com. Useful as a sense-check, but the version number in your own dashboard is the definitive answer.
What to do if you think you were exploited
If a site was on an affected version — 6.8.x, 6.9.x or 7.0.x — and sat unpatched for a while (a forgotten staging copy, say, or one whose auto-updates were off), it’s worth a calm look for signs of trouble rather than assuming the worst. Because this particular flaw can end in an attacker quietly creating their own administrator account, the two things worth checking are: administrator users you don’t recognise, and any plugin uploads or file changes you can’t account for. Our guide to the signs a WordPress site has been hacked walks through what to look for — and what’s usually a false alarm.
If something genuinely looks off, treat it as a possible full compromise and get it looked at properly. A site that’s had an unknown admin account created on it isn’t one to clean by guesswork, and that’s precisely what our Security & Malware Removal service is for.
The bigger point
Here’s the honest reflection. This was the rare event — a genuine, critical hole in WordPress core, the kind that comes round perhaps once in a decade. And even this one was handled, for most sites, by the update system quietly doing its job. The everyday risk to your site hasn’t changed: it’s still the slow drift of out-of-date plugins, themes and core that accounts for the vast majority of hacks. The single most valuable habit remains the dull one — staying current with your updates, and keeping a staging site so you can apply them without fear of breaking anything. wp2shell is the dramatic exception that makes the unglamorous rule.
Not sure where you stand?
Request a free WordPress health check — we’ll run it through WPScan and tell you plainly where you stand. No obligation.
And if you already suspect something is wrong, our Security & Malware Removal service is the fastest way to get certainty and a clean site.
Your site is affected if it’s running WordPress 6.8.x, 6.9.x or 7.0.x. The 6.9.x and 7.0.x branches are affected by the full remote code execution chain; 6.8.x is affected only by the related SQL injection issue. It’s fixed in 7.0.2, 6.9.5 and 6.8.6. Versions before 6.8 are not affected.
Log in and go to Dashboard → Updates, or look at the bottom-right corner of any admin screen, where the version number is shown. Seeing 7.0.2 (or 6.9.5 or 6.8.6 on an older supported branch) means the fix is in place.
It’s the critical vulnerability at the heart of wp2shell — a REST API batch-route confusion issue in WordPress core that can be chained with a SQL injection flaw (CVE-2026-60137) to achieve remote code execution without any login. WordPress patched it on 17 July 2026.

