WP2Shell: the WordPress vulnerability that hit sites worldwide, and how we responded

Security bulletin

In July 2026, a critical vulnerability in WordPress core itself was disclosed and almost immediately exploited across the internet. It’s been nicknamed WP2Shell.

Why it stands out: it needed no plugin, no login, and no special setup. Any WordPress site on an affected version could be compromised by a single anonymous request. That’s rare, and it’s serious.

Every site we manage has been patched and checked. Here’s what happened, and how we handled it.

What WP2Shell actually was:

In plain English: attackers could send specially crafted requests to a WordPress site and end up running their own code on it, effectively taking control, without ever logging in.

For anyone who wants the detail: it chained two flaws together, a REST API “batch route” confusion in WordPress’s /wp-json/batch/v1 endpoint (CVE-2026-63030, critical) with a SQL injection issue (CVE-2026-60137, high), into an unauthenticated remote code execution. In practice, attackers used it to create a hidden administrator account and/or drop a web shell on the server.

WP2Shell: incident summary Critical
CVEs
CVE-2026-63030, CVE-2026-60137
Affected versions
6.9.0–6.9.4 & 7.0.0–7.0.1
Fixed in
6.9.5 / 7.0.2
Fix released
17 July 2026, force-pushed

Why it was such a big deal:

Pre-authentication plus core-level access means the widest possible blast radius: millions of sites potentially in scope. Public proof-of-concept code appeared quickly, and active in-the-wild exploitation was confirmed within days (18 to 20 July). CISA added both CVEs to its Known Exploited Vulnerabilities catalogue, with a US federal patch deadline of 24 July, a strong signal that real-world attacks were already underway.

In our own monitoring, we saw a single reachable site hit by hundreds of exploit attempts from many different IP addresses within a matter of days, different actors, all running the same public tooling. The lesson: attackers spray every site they can reach automatically, so “my site is too small to be a target” isn’t a defence.

How we responded:

As soon as the vulnerability broke, we reviewed the WordPress version of every site in our care and identified which needed action. We brought every affected site onto a fixed version, staging tested where a major upgrade was involved, or pinned to the security minor where a bigger jump carried risk. Because auto-updates don’t always land silently, we verified each site’s version directly rather than trusting the dashboard.

For the small number of sites that were exposed during the attack window, we went further, checking for unauthorised administrator accounts, injected content and malicious files, alongside our hosting partner’s own malware scanning.

We check the database, not just the files. This attack’s automated tooling deletes its own files after it runs, security researchers at Elastic documented exactly this, so a site can look clean on the surface while the real evidence, a hidden administrator account, for example, sits in the database. Checking only the files would miss it, which is why our review goes deeper.

We check the server logs, too. For any site that was exposed, we went to the raw server access logs to establish what actually happened: whether the vulnerability was triggered, from where, and whether there was any sign of data being accessed, rather than guessing. That’s what lets us give a straight, honest answer instead of a shrug, including saying so plainly where the logs can’t prove something either way.

Where we found trace activity, we removed it, reset credentials, and tightened defences: bot protection on forms, login protections, and re-enabling automatic security updates. Patched isn’t the same as safe. Verifying and checking is the part that matters, and it’s the part we do as standard.

MID JULY
Vulnerability disclosed
WordPress core, unauthenticated
17 JUL
Fix released
Force-pushed via auto-update
18–20 JUL
Exploitation confirmed
Active attacks in the wild
24 JUL
CISA KEV deadline
US federal patch mandate

What this means for site owners:

Attacks like this are automated and indiscriminate. Bots hit every reachable site, so being small or low-profile is no protection. A meaningful security check goes beyond “is it the right version”; it looks at user accounts, content, files and server logs, because capable attackers cover their tracks and a surface glance misses them. Managed hosting plus an active maintenance partner shortens the window between a vulnerability being announced and your site actually being protected. And a good response plan includes checking for compromise, not just applying the patch.

How we protect the sites we look after:

This is exactly why we run ongoing maintenance for the sites we manage rather than treating updates as a one-off task. Core, plugin and theme updates are applied on a regular schedule and tested before they go live. When something like WP2Shell breaks, we don’t wait for a scheduled cycle: we check every site we manage against it immediately, verify the fix has actually landed, and look for signs of compromise where it matters. It’s backed by hosting on a platform with its own security monitoring, so issues get caught from more than one angle.

Not sure whether your site is covered, or when it was last updated?

Get in touch with our team

To find out more about how we can help grow your e-commerce business, please get in touch and we will get back to you as soon as we can.



    Sources & further reading

    Post Categories

    More Articles…