A critical WordPress vulnerability called wp2shell went public on July 17, and attackers were exploiting it in the wild within days. It is a genuinely serious flaw: it sits in WordPress core, needs no login, and hands an attacker the ability to run their own code on your server. But whether it is actually your problem right now comes down to one thing, and it is not how careful you are. It is who patches your site.
On our managed hosting, this was handled at the server level before most site owners had even heard the name. If you are hosted somewhere that leaves patching to you, this is an emergency you need to deal with today.
What wp2shell actually is
wp2shell is two vulnerabilities chained together. CVE-2026-63030 is a flaw in WordPress core’s REST API batch endpoint. CVE-2026-60137 is a SQL injection, also in core. On their own each is bad. Chained, they let an unauthenticated attacker go from an anonymous web request all the way to remote code execution, with no credentials and no user interaction.
The important word there is core. This is not a vulnerability in some abandoned plugin that only a few thousand sites run. It is in WordPress itself, which means every site on an affected version is exposed by default. The affected versions are 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. WordPress shipped fixes in 6.9.5, 7.0.2, and 6.8.6, and pushed them out through the automatic update system for sites that have it enabled.
The timeline is what makes this one nasty. Disclosure was July 17. Working proof-of-concept code was circulating within hours. By July 20, security firms were seeing active exploitation against live sites. There was no comfortable window between “researchers found a bug” and “attackers are using it.” They arrived at the same time.
Why a firewall alone is not the answer here
The standard advice when a WordPress vulnerability drops is “your WAF will catch it.” Sometimes that is true. Here it is only partly true, and the gap is one a lot of site owners do not realize applies to them.
Cloudflare and others did ship firewall rules to detect wp2shell exploitation attempts. But those rules only protect traffic that actually passes through the firewall. If your site runs Cloudflare in DNS-only mode, or points a record straight at your origin server, or otherwise lets requests reach your web server without going through the proxy, the firewall rule never sees the attack. Plenty of sites are configured exactly that way without the owner thinking about it.
A firewall is a useful layer. It is not a substitute for the fix. The only complete protection against wp2shell is running a patched version of WordPress, or having protection applied at the server itself rather than at a proxy the attacker can route around.
Why our clients did not have to do anything
This is the part where hosting actually matters, and it is worth being specific about what “managed” means, because a lot of hosts use the word without doing the work behind it.
Every shared server in our fleet runs server-level security: Imunify360 and ModSecurity, sitting in front of every account. When a vulnerability like wp2shell is being exploited, that layer ships virtual patches that block the attack pattern at the server edge, on every site, regardless of whether the site owner has clicked update yet. It does not depend on each customer noticing a CVE and reacting in time. It also does not care whether a site sits behind a proxy or takes traffic directly, because it runs on the server the traffic is actually hitting.
On top of that, watching security disclosures and applying core patches across the fleet is our job, not yours. When something like this breaks on a Friday, it is not a scramble for our clients. It is a normal day. That is the whole point of paying for managed hosting instead of the cheapest plan you can find: someone is responsible for exactly this, and it is not you. We wrote earlier this year about how the window between disclosure and exploitation has collapsed, and wp2shell is a textbook example of why that matters.
If you are not on managed hosting, do this today
If your site is somewhere that expects you to handle updates yourself, do not wait. The exploitation is real and it is happening now.
- Check your WordPress version. It is in the admin dashboard footer, or under Dashboard, then Updates.
- If you are on 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1, update immediately to 6.9.5, 7.0.2, or later. Sites on 6.8.x should move to 6.8.6.
- Confirm the update actually applied. Forced auto-updates usually work, but “usually” is not “always,” and this is not a bug you want to assume away.
- Do not lean on a firewall alone if your site takes traffic directly or runs a proxy in DNS-only mode. Patch first, then treat the firewall as backup.
- If your site was on an affected version and exposed for the last several days, have it checked for signs of compromise, not just updated. A patch closes the door; it does not undo anything that already got in.
The bottom line
wp2shell is a real, severe, actively exploited hole in WordPress core, and it is not going away because the fix is out. Plenty of sites will stay unpatched for weeks. The question that actually decides your exposure is simple: is someone patching your site for you, or is that on you? On managed hosting done properly, it is the host’s job and it is already done. Everywhere else, it is yours, and the clock started on July 17.
Full disclosure, since you are reading this on a hosting provider’s blog: we are CanSpace, a Canadian-incorporated company with all data centers in Canada and Canadian-staffed support. The reason we can say our clients did not need to do anything about wp2shell is that server-level patching and CVE response are things we actually do, on every account, as part of the plan.
If you would rather this kind of thing be someone else’s problem, our managed hosting plans and managed VPS both include the security layer described above. If you are weighing a move and want a straight answer about how we handle security and patching, ask us directly and we will walk you through it.
