The WordPress 7.0.2 security update was released on 17 July 2026 and closes two serious flaws. If your site is on a version between 6.8 and 7.0.1, you are affected: the fix arrived in versions 7.0.2, 6.9.5 and 6.8.6. The first attack attempts came in 90 minutes after the release — which is why it can’t wait.
Contents
- What happened on 17 July, and why does it affect you too?
- Why isn’t “next month” good enough?
- Which WordPress version am I running, and where do I check?
- Which version fixes the flaw? Version matrix
- How do I turn on automatic security updates?
- What should I check if I didn’t update for days?
- What can virtual patching do while you update?
- How alone are you with this problem?
- Frequently asked questions
What happened on 17 July, and why does it affect you too?
That day, the WordPress developers published an emergency security release. According to the official announcement, 7.0.2 fixes “one critical and one high-severity” flaw, and because of the severity the WordPress.org team triggered a forced automatic update for sites running the affected versions (WordPress.org).
That sentence means two things. The good news: many sites received the fix on their own that night, and the owner only saw an email about it in the morning. The less good news: a forced update only runs where automatic updates work in the first place. Where someone switched them off years ago “so nothing breaks”, nothing happened.
What do the two flaws do, in plain terms? In one case, a public request can trigger a database query that should never be allowed. In the other, incoming requests to WordPress’s built-in programming interface don’t end up where they should. Neither hands over the site on its own, but chained together they can give an attacker administrator access and code execution on an unprotected site (Patchstack). We are deliberately not publishing technical details — you don’t need them to protect yourself.
What’s interesting is where the flaw came from. The chain fixed in 7.0.2 was found by researchers at Searchlight Cyber, who set a language model loose on the WordPress source code: the working attack chain came together in ten hours, for roughly 25 dollars (Patchstack). The same trend shows in the traffic of WordPress’s bug reporting programme: for nine years it received a few dozen reports a month, but in July 2026 it received 450 (Patchstack). More eyes, faster — that’s good for WordPress in the long run. In the short run, though, it means “we’ll do it at the next maintenance” is a habit from a world that no longer exists.
Why isn’t “next month” good enough?
Because attackers don’t think in months. According to Patchstack’s telemetry, the fix landed in the WordPress development branch about an hour and a half before 7.0.2 was released — and that commit is itself the disclosure, since anyone can look at what changed.
The first real attack attempts arrived roughly 90 minutes after 7.0.2 was released, three hours after the fix was made public. That was all the time defenders had. (Source: Patchstack)
What followed wasn’t a single organised botnet but a crowd of independent attackers all arriving at once.
In the days after the release, Patchstack blocked more than 65,000 attack attempts against these two flaws, from more than 1,500 different IP addresses — and every single attempt targeted a site that really was running a vulnerable version. (Source: Patchstack)
This isn’t a one-off; it’s the general rhythm. According to Patchstack’s 2026 industry report, for the most-attacked vulnerabilities the weighted median time from disclosure to mass exploitation is five hours; roughly half of high-impact flaws are attacked within 24 hours and 70% within a week (Swif summary of Patchstack data). Meanwhile, Verizon’s 2026 Data Breach Investigations Report measures organisations’ median time to patch rising from 32 days to 43 days.
Five hours is the attackers’ median; 43 days is the defenders’. Most hacked WordPress sites live in that gap. (Source: Swif / Patchstack and Verizon DBIR 2026)
And there’s one more figure that surprises many people: for the first time in the 19-year history of Verizon’s report, exploited vulnerabilities became the number one entry point for breaches, at 31% of attacks — ahead of stolen passwords (Swif). We wrote about this shift in detail in our article on WordPress attack trends in 2026: these days attackers don’t guess your password, they try published flaws.
Which WordPress version am I running, and where do I check?
Two minutes and you’ll know. You don’t need a developer or FTP.
• 1. Log in to the admin area of your site (`yourwebsite.co.uk/wp-admin`). • 2. Dashboard → Home. On the right or further down you’ll find a box called “At a Glance”. At the bottom it says: “WordPress 7.x.x running … theme”. That’s your version number. • 3. If you can’t see it: go to Dashboard → Updates. The top of the page shows which version you’re running and whether a newer one is available. • 4. Want to be sure? Go to Tools → Site Health → Info and expand the WordPress section. Next to the version you’ll also see whether debugging is switched on and which PHP version your site runs on. • 5. If you can’t log in at all: your hosting provider’s control panel (cPanel WP Toolkit, the Plesk WordPress menu) also shows the installed version.
What not to do: don’t try to work it out from the site’s source code. On many installations that information is deliberately hidden or fake, and it tells you nothing about whether your plugins are up to date.
This is exactly what caused weeks of confusion for one of our service-business clients: according to the admin area everything was fine, “no updates available” — while years earlier a developer had completely disabled update checks in the wp-config.php file. The site wasn’t failing to update because there was nothing to update; it simply never asked.
Which version fixes the flaw? Version matrix
WordPress released the fix on three parallel branches. Find your own version number in the left-hand column.
| Your version | Affected by these two flaws? | Fixed version on the branch | What to do now |
|---|---|---|---|
| 7.0.0 – 7.0.1 | Yes, both | 7.0.2 | Update immediately, ideally straight to the latest release. Then work through the checklist below. |
| 6.9.0 – 6.9.4 | Yes, both | 6.9.5 | Update immediately. If you’re not ready to move to the 7.x branch yet, at least install 6.9.5 today. |
| 6.8.0 – 6.8.5 | Yes, one of them | 6.8.6 | Update. Your risk is lower, but not zero — and the 6.8 branch is ageing anyway. |
| 6.7 or older | No, not these two | – | Don’t relax: you’re years behind a supported version and missing dozens of other fixes. Plan an update. |
| 7.0.2 / 6.9.5 / 6.8.6 or newer | Not affected | – | Good. Now check that you also have the 12 further fixes in 7.0.3 (6 Aug 2026). |
The version matrix is based on WordPress.org’s official release documentation, which states that the 6.9 branch is affected by both flaws, the 6.8 branch only by the first, and versions before 6.8 by neither (WordPress.org 7.0.2 documentation).
Importantly, 17 July isn’t the end of the story. WordPress 7.0.3 was released on 6 August 2026, fixing 12 further vulnerabilities in a single release — including one reachable without logging in and four that only need an author-level account (Patchstack). And on 19 August 2026 WordPress 7.1 “Mary Lou” came out (WordPress.org). So even if the matrix says “7.0.2, all fine”, you still have work to do.
Before any update, we always ask our clients for one thing: a recent backup that can actually be restored. It isn’t enough that one is made — it has to be tested. That’s what our article on the 3-2-1 backup rule is about, and honestly, this step is what makes updating stress-free: if there’s somewhere to roll back to, there’s no need to fear the Update button.
How do I turn on automatic security updates?
Since WordPress 3.7, maintenance and security (minor) updates have been automatic by default, and the developers designed this specifically so nobody has to touch it — the official documentation “strongly discourages” switching them off (WordPress Developer Handbook). In practice, though, a great many sites have them disabled.
Here’s how to check and switch them back on:
• 1. Dashboard → Updates. At the top of the page there’s a sentence saying whether your site updates automatically to every new version or only to maintenance and security releases. Next to it is a link to switch between the two. If you find it here, you’re done. • 2. If there’s no such switch, the setting has been overridden in the `wp-config.php` file. In that case `WP_AUTO_UPDATE_CORE` needs to be set to at least `’minor’` (this allows minor updates but not major version changes), and you need to check that `AUTOMATIC_UPDATER_DISABLED` isn’t set to `true`. This takes a little technical confidence or a professional — but it’s a one-off, ten-minute job. • 3. Check whether it’s a fresh installation or an old one. From WordPress 5.6 onwards, new installations receive major versions automatically by default too; older sites, however, keep the previous minor-only behaviour until someone changes it (WordPress Developer Handbook). • 4. Plugins and themes. On the Plugins screen, every row has an “Enable auto-updates” link. Plugins do not update automatically by default — even though 91% of new vulnerabilities in 2025 were in plugins (Swif / Patchstack). We wrote more about this in our article on choosing secure plugins. • 5. Check the admin email address. WordPress emails you about successful and failed automatic updates. If that address belongs to a former colleague or an inbox nobody reads, the system will tell someone — just not you. Settings → General, the “Administration Email Address” field near the top.
Manual, automatic or managed updates?
| Aspect | Manual updates | Built-in automatic minor updates | Managed updates |
|---|---|---|---|
| When it runs | When you remember, or when you have time | On release day, by itself, even at night | On a schedule, checked in a test environment |
| For a security release | Hours or days of delay | Runs within hours | Within hours, in a controlled way |
| Major version change (e.g. 7.0 → 7.1) | Up to you | Doesn’t run by default on older sites | Tested in advance, with a restore point |
| Plugins, themes | By hand, one by one | Only if you switch it on separately | In batches, with compatibility checks |
| If the site breaks | You notice — if you notice | You notice — if you notice | Monitoring alerts, restore from backup |
| Who it suits | A single simple site with a disciplined owner | Everyone — this is the minimum | Online shops, client portals, revenue-generating sites |
The middle column of the table is the most important: it’s the level below which it no longer makes sense to run a WordPress site. The right-hand column is about someone else watching what happened after an update on your behalf.
What should I check if I didn’t update for days?
Say you were on holiday, or time simply ran away with you, and the update only ran days later. The update closes the flaw, but it doesn’t clean up afterwards — if someone has already got in, they stay in. This list goes through the places where traces usually show. None of them requires developer knowledge.
• Unknown administrator. Users → All Users, filter by the “Administrator” role. Do you recognise every name and email address on the list? A single unfamiliar account is reason enough to raise the alarm. • New or unfamiliar plugin. Plugins → Installed Plugins. Look through the inactive plugins too, not just the active ones — smuggled-in code often sits there inactive. If a plugin’s name means nothing to you, look it up. • Unfamiliar PHP file among the uploads. The `wp-content/uploads` folder is home to images and documents. There is never a reason for a PHP file to be there. If you find one in your hosting file manager, that alone is suspicious. • The mu-plugins folder. The contents of the `wp-content/mu-plugins` folder load automatically and don’t appear on the Plugins screen. That’s exactly why it’s a favourite hiding place. Check whether you have this folder and, if so, what’s in it. • Scheduled tasks. WordPress’s built-in scheduler (WP-Cron) runs tasks regularly. An unknown entry here could mean something keeps restarting itself. For non-technical users, the WP Crontrol plugin is the easiest way to take a look. • Outgoing spam. Ask your hosting provider whether the number of emails sent from your domain has gone up. Another tell-tale sign is your own business emails, which used to work fine, suddenly landing in spam or bouncing. • Unexpected content. New posts or pages you didn’t write, text in foreign languages, odd redirects on mobile.
If you got stuck on any point of the list, our article on the 8 tell-tale signs of a hacked website goes through in detail what counts as a real sign and what only looks alarming.
An important warning: don’t just delete what you find. For one client, after the unfamiliar file was deleted the site was fine for two days, then the same thing reappeared — because the real entry point was still elsewhere. The right order is: back up the current (infected) state as evidence, change passwords, carry out a full scan, and only then clean up.
And yes, sometimes you go through the whole list and find nothing. For one of our service-business clients, we ordered a full scan after a delayed update, and every point came back clean. That’s a result too — the certainty is worth the half-hour.
What can virtual patching do while you update?
This is the part that answers the 90 minutes. Virtual patching is a firewall rule that, without modifying the application, blocks requests known to be trying to exploit a specific known flaw (WP Umbrella). The flaw stays in the code — but the request never reaches it.
The benefit is that it can be deployed in seconds, whereas a real update needs testing, scheduling and sometimes coordination with developers. During the July campaign, Patchstack stopped 99.9% of the blocked attempts on its own customers’ sites with the targeted rule for the two flaws, before the first attempt even arrived.
Two sober remarks. First: virtual patching does not replace updating; it only bridges the time until you get there. Second, a lesson Patchstack itself wrote about openly: the firewall rules released in the first hours had the same blind spot across almost the whole industry, and could be bypassed until everyone had updated them. In other words, protection needs maintenance too — it isn’t a switch, it’s a service.
It’s also worth knowing that hosting-level protection on its own isn’t enough. According to Patchstack’s 2025 tests on popular hosting providers, standard hosting protections stopped only 26% of vulnerability exploitation attempts, and only 12% of attacks aimed specifically at WordPress (Swif / Patchstack). That isn’t the hosts’ fault: a network firewall doesn’t know WordPress’s internal logic, so it lets well-formed, “legitimate-looking” requests through.
How alone are you with this problem?
Not at all. WordPress powers 41.5% of websites, and roughly 59% of sites running an identifiable content management system (W3Techs data in Swif’s summary). This concentration is why a single working core flaw can be fired at the entire internet straight away.
The good news is that WordPress installations are much more up to date than ten years ago: roughly 92% run on the 6.x branch or newer. And that’s exactly why this July case was so sharp: the faulty code only existed from version 6.8, which means the most up-to-date sites were the most exposed (Swif). Anyone who hadn’t updated for years wasn’t affected by this particular flaw — but dozens of others do affect them.
In any case, the centre of gravity of the risk hasn’t been WordPress core for a long time. 91% of the 11,334 new vulnerabilities discovered in 2025 were in plugins, and for 46% of disclosed flaws no fix existed at all at the moment of disclosure (Swif / Patchstack). That’s the nearly half of cases where the “always update” advice doesn’t work on its own — because there’s nothing to update to. That leaves virtual patching and monitoring.
Not sure which version you’re running? Let’s check together
At WPShield, our maintenance package closes exactly this gap: we install security releases in a managed way, within hours, with a backup behind us — and if something does go wrong, there’s somewhere to roll back to. And if the damage has already been done, we can restore a hacked site too.
Start with the simplest step: ask for our free quick security check. We’ll look at which WordPress version your site runs, whether automatic security updates are switched on, and whether there are any traces that call for a follow-up scan. Fifteen minutes, and you’ll know where you stand.
*Sources: WordPress.org — WordPress 7.0.2 Release (17 July 2026); WordPress.org — Version 7.0.2 documentation; WordPress.org — WordPress 7.1 “Mary Lou” (19 August 2026); WordPress Developer Handbook — Upgrading WordPress / Configuring Automatic Background Updates; Patchstack — Ninety minutes: watching attackers weaponize the WordPress core RCE (22 July 2026); Patchstack — WordPress 7.0.3 Released: 12 Vulnerabilities Found and Fixed (6 August 2026); Swif — WordPress Security Statistics for 2026 (with Patchstack, W3Techs and Verizon DBIR 2026 data); WP Umbrella — What is Virtual Patching in WordPress?.*
Frequently asked questions
Which WordPress version am I running, and where do I check?
Log in to the admin area and look at the “At a Glance” box on the Dashboard: it shows the exact version number. You’ll find the same information on the Dashboard → Updates screen, and on the WordPress tab under Tools → Site Health → Info. If you can’t log in, check your hosting provider’s control panel, as most panels also show the installed version.
Am I affected by the flaws fixed in WordPress 7.0.2?
If your site runs any version from 6.8 to 7.0.1, yes. According to WordPress.org’s official notice, the 6.9 branch is affected by both flaws, the 6.8 branch by only one, and versions older than 6.8 are not affected by these two flaws. If your version number is 7.0.2, 6.9.5 or 6.8.6, or newer, these two flaws are already patched on your site.
Which version fixes the flaw?
The fix arrived on three branches: 7.0.2, 6.9.5 and 6.8.6. All three were released on 17 July 2026. The best option, however, is not to stop at these versions but to update to the latest release, because 7.0.3 (6 August 2026, 12 further vulnerabilities fixed) and 7.1 “Mary Lou” (19 August 2026) have come out since.
What should I check if I didn’t update for days?
Go through the user list looking for unknown administrators, the plugin list for new or unfamiliar entries, the uploads folder for PHP files, and the wp-content/mu-plugins folder, which doesn’t appear on the Plugins screen. Check the scheduled tasks too, and whether outgoing spam is being sent from your domain. If you find anything, don’t just delete it: ask for an expert scan, because a backdoor rarely comes alone.
How do I turn on automatic security updates?
Since WordPress 3.7, maintenance and security (minor) updates have been automatic by default, but on many sites someone has switched them off. Go to the Dashboard → Updates screen and look at the automatic updates line at the top of the page — that’s where you can switch them on. If there’s no such switch, the setting has been overridden in the wp-config.php file; in that case WP_AUTO_UPDATE_CORE needs to be set to at least “minor”, and you need to check that AUTOMATIC_UPDATER_DISABLED isn’t switched on.
What is virtual patching, and does it replace updating?
Virtual patching is a firewall rule that filters out requests trying to exploit a known flaw before they reach WordPress — without touching the site’s code at all. This protection can be deployed in seconds, so it can bridge the hours between a release and your update. It doesn’t replace updating; it buys you time to do it.
