Roger Gnanih
On July 17, 2026, WordPress did something it almost never does: ignore administrators' choices and force an update on millions of sites, even those where automatic updates were disabled.
The name of the flaw: wp2shell. The verdict of the researchers who found it: remote code execution, without authentication, on a default installation, without any plugin.
In other words, the worst possible scenario for a CMS that runs more than 40 % of the web.
Why this flaw stands out
Every week brings its share of WordPress vulnerabilities. In the vast majority of cases, they affect a third-party plugin or theme, with a limited install base and a vector that already assumes a minimum level of access.
wp2shell checks none of these reassuring boxes:
- It lives in the core of WordPress, not in a plugin.
- It is exploitable without an account, without privileges, without interaction.
- It affects a default installation, as is, straight out of the box.
It is this combination that pushed Searchlight Cyber, the team that discovered the flaw, to classify it as critical, and that pushed WordPress to respond with a forced deployment rather than a simple security bulletin.
How the attack works
Everything starts from a REST API endpoint meant to save time: /wp-json/batch/v1, which allows grouping several API calls into a single request.
The problem lies in the way this endpoint resolves internal routes, a confusion that lets unsanitized data through to the database. The complete chain unfolds in two stages:
- An SQL injection via batch processing, which allows manipulating queries sent to the database.
- Arbitrary code execution (RCE), made possible by what was injected in the previous step.
CVE-2026-60137: the SQL injection component, which also affects the 6.8 branch
CVE-2026-63030: the complete chain leading to RCE, reported by researcher Kues
Affected versions
6.8.x: vulnerable up to 6.8.5 (SQLi only) → fixed in 6.8.6
6.9.x: vulnerable from 6.9.0 to 6.9.4 → fixed in 6.9.5
7.0.x: vulnerable from 7.0.0 to 7.0.1 → fixed in 7.0.2
7.1 (beta): vulnerable in beta1 → fixed in beta2
The real warning sign: the force-push
WordPress has a background automatic update system, but it normally respects an administrator's wish to disable it. It is one of the rare configuration decisions that WordPress core never questions.
On July 17, that rule was broken. The fix was pushed to all affected sites, whether or not they had auto-update enabled.
🚨 It is this detail, more than the vulnerability itself, that deserves attention. WordPress breaks this trust contract only on very rare occasions. The implicit message: the risk of mass exploitation was deemed too high to leave it in the administrators' hands.
What to do, concretely
- Verify the version actually installed. Do not assume the auto-update worked. On shared hosting or custom configurations, automatic updates can fail silently. Go directly to the admin dashboard and confirm the displayed version: 6.9.5, 7.0.2, or higher.
- If an immediate update is not possible, put at least one of these mitigations in place while you patch.
- Monitor the logs over the following days for any suspicious requests to the batch endpoint, even after the fix, a sign that a third party was already testing the flaw before the patch.
- Block /wp-json/batch/v1 and rest_route=/batch/v1 at the WAF or reverse proxy level
- Install a plugin that restricts unauthenticated access to the REST API
- Add a must-use plugin that requires authentication on the batch route
Key Takeaways
No active exploitation had been reported at the time of disclosure, according to Searchlight Cyber. But the history of WordPress core vulnerabilities is unambiguous: the window between public disclosure and the first automated exploitation attempts is measured in hours, not days.
If you manage even a single WordPress site, this fix is not one to put off until tomorrow.
