WordPress 7.0.2: what happened and why you must update now
On 17 July 2026 WordPress released version 7.0.2, a security update that fixes two vulnerabilities: one critical and one high severity. This is not a routine maintenance update: the critical flaw lets an attacker with no credentials at all run code on the server of a WordPress site with a standard install.
If you run a WordPress site, this is one of those pieces of news to read now, not on Monday.
What happened
The update resolves two issues responsibly reported through WordPress’s HackerOne programme:
- CVE-2026-63030, nicknamed wp2shell: a route-confusion weakness in the REST API batch endpoint that, chained with the second flaw, leads to remote code execution (RCE). This is the critical one, found by Adam Kues of Searchlight Cyber’s Assetnote team.
- CVE-2026-60137: a SQL injection, reported by the team of TF1T, dtro and haongo. It is the second link in the chain.
What makes this case different is how easy it is to exploit. According to the researchers the attack has no preconditions: no login, no third-party plugins, no special configuration. A stock WordPress install is exploitable with a single anonymous HTTP request. And the REST API batch endpoint is part of core, on by default and reachable without authentication, so this is not a niche configuration issue.
Remote code execution is the most severe class of vulnerability there is. Successful exploitation means, in practice, that the attacker gains control of the site.
What an attacker can do, and the consequences
“Takes control of the site” sounds abstract. Concretely, being able to run code on the server, an attacker can:
- Create hidden administrator accounts and keep access even after an update.
- Install persistent backdoors that survive surface-level cleanups.
- Steal database data: customer records, orders, email addresses, passwords (which, even if encrypted, become attackable offline at leisure).
- Inject redirects to malware or scam sites, or insert spam and hidden links that destroy your Google ranking.
- Deface pages or take the site offline.
- Use your server to attack other sites or send spam, landing your domain on blocklists.
- Reach other sites on the same hosting, if the environment is not isolated.
- Encrypt or hijack the site and demand a ransom.
An often underestimated risk is API keys. If keys for pay-as-you-go services are configured on the site or server, for example AI models, email or SMS sending, cloud services, anyone with access can steal them and use them in your name. The result can be a very large bill that builds up fast and may arrive before you even notice the breach.
And the real cost comes after the attack: days of work to clean up and restore, a possible notification to the data protection authority if personal data was breached (GDPR), the loss of customer trust and the revenue lost while the site is down or compromised.
Which versions are at risk
This is where many articles cause confusion, so it is worth being precise. Not every WordPress version is vulnerable to the RCE chain.
| Version | Situation | Fixed version |
|---|---|---|
| 7.0.0 – 7.0.1 | Vulnerable to both flaws | 7.0.2 |
| 6.9.0 – 6.9.4 | Vulnerable to both flaws | 6.9.5 |
| 6.8.x | Vulnerable to the SQL injection only | 6.8.6 |
| 7.1 beta | Vulnerable to both flaws | 7.1 beta2 |
| Before 6.8 | Not affected | — |
The code vulnerable to the RCE chain exists from 6.9, released in December 2025. A site on an older version is not exposed to this specific flaw, which does not make it safe, since those versions have other known issues.
Why this is urgent
Given the severity, the WordPress.org team enabled forced updates through the auto-update system for affected versions. That is an exceptional measure, taken only when the risk is concrete and widespread.
Searchlight Cyber deliberately held back the exploit’s technical details to give administrators time to patch, publishing only a public checker. But in the hours after disclosure, proof-of-concepts in circulation and the first signs of real exploitation were already reported. Put plainly: if one of your sites is running an affected version, the right thinking is not “I’ll update when I get time” but “I treat that site as exposed until it is updated”.
Check your version in 30 seconds
Open the WordPress dashboard and look at the “At a Glance” box: the version is shown there. You can also find it under Updates or in the readme.html file at the root of the install. If you manage many sites, there are public online checkers and tools like WPScan.
What to do, right now
- Update core. From the dashboard: Updates → Update now. If the site supports automatic updates the process may have started on its own: check that it succeeded anyway, because a forced update can fail silently on installs with unusual file permissions.
- Confirm you are actually on the fixed version (7.0.2, 6.9.5 or 6.8.6 depending on the branch).
- Repeat on every site you manage, including staging and forgotten projects. An abandoned site on the same server is still an open door.
If you can’t update immediately
It happens: a site with heavy customisations where the update has to be tested first. In that case the researchers suggest temporary measures, such as restricting anonymous access to the REST API or blocking requests to the batch endpoint at the web application firewall level. Two warnings: these can break legitimate integrations that use the REST API, so they are a temporary patch, not an alternative to updating; and the claim that a persistent object cache (Redis, Memcached) protects you is not protection and must not be read that way.
How to tell if you’ve been compromised
If a site stayed on a vulnerable version after disclosure, the update closes the door but does not remove an intrusion that already happened. Check for unknown administrator accounts added recently, files modified on suspicious dates (especially in wp-content and the root), the access logs to the REST endpoints, and scheduled tasks you don’t recognise. If you find something, the right path is not to delete the file and hope: you need a restore from a backup made before the intrusion, followed by the update and a change of all credentials.
The lesson: why maintenance is not an optional cost
This case proves a principle I often repeat to clients: the security of a WordPress site is not a state, it is a process.
Notice one thing: plugins are not the point here. The classic advice “use few plugins and keep them updated” is sound, but it would have protected no one. The flaw was in core, in code active by default on every install. The only real defence was applying the update quickly.
And here you see the difference between a site that is looked after and one left to itself. It is not about the owner’s skill: someone has to notice a critical security update has shipped, check which sites are affected, apply it and confirm it worked. On a summer Friday evening, while you are doing something else.
The paradox of maintenance done well is that, when it works, it looks like nothing is happening. Days like this are the exception where you see what it is for.
FAQ
Frequently asked questions
My site updates itself, am I fine?
Probably yes, because forced updates were enabled for this release. But automatic updates can fail, for example due to file permissions. It is always worth checking the version manually in the dashboard.
I use WordPress 6.8, am I vulnerable?
Not to the RCE chain: that code exists from 6.9. You are affected by the SQL injection, fixed in 6.8.6. Update anyway.
Is disabling plugins enough to protect me?
No. The vulnerability is in WordPress core, not in a plugin. Disabling plugins changes nothing.
Am I safe with Redis or Memcached?
No. The disclosed exploitation path concerns cases without a persistent object cache, but it is not protection. The only remedy is the update.
How do I know if my site was attacked?
Check for new administrator accounts, recently modified files and the access logs to the REST endpoints. If in doubt, have someone who knows where to look take a look.