wp2shell: Critical WordPress Vulnerability Under Active Attack

WordPress powers a large share of the web. A flaw in its core therefore does not hit individual sites, it hits millions of installations at once. That is exactly what has happened with wp2shell. Since July 17, 2026, a vulnerability chain has been public; an exploit was circulating within hours, and it is now being actively exploited.

The real problem is not a missing patch. There is one. The problem is the time in between: the days between "the exploit is public" and "the update is cleanly rolled out everywhere." That is exactly the window where the attacks happen. And this window can be closed before the first server reboots.

You can check in seconds whether one of your installations is affected using the free checker from the researchers who found it : enter a domain and the tool tells you whether your WordPress site is vulnerable.

What is wp2shell?

wp2shell is not a plugin bug. It is a chain of two vulnerabilities in the WordPress core that together lead to code execution, with no login required.

• CVE-2026-63030: a route confusion in the REST API batch endpoint (/wp-json/batch/v1), introduced with WordPress 6.9. This is the part that makes code execution possible.
• CVE-2026-60137: a SQL injection in the author__not_in parameter of WP_Query, present since WordPress 6.8.

Chained on WordPress 6.9.0 through 7.0.1, this adds up to an unauthenticated path to code execution. Germany's BSI rates the chain with a CVSS score of 9.8, which is critical. Attackers use the access to plant persistent webshells. A webshell is a small file that gives the attacker remote control of the server. Hence the name wp2shell.

The chain was discovered by the security team at Searchlight Cyber. It hits standard installations; no vulnerable plugin is required. Affected are versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. Versions up to and including 6.8.5 are not affected. The issue is fixed in 6.9.5 and 7.0.2, released on July 17, 2026; for older branches there is a backport in 6.8.6.

Why isn't fast patching enough?

Because "patch quickly" is rarely quick in practice. Even for careful teams, days often pass between a vulnerability becoming known and an update being cleanly rolled out. The reasons are familiar:

• Compatibility: a core update can break plugins or the theme. Doing it responsibly means testing in staging first, then going to production.
• Maintenance windows: production sites are not updated in the middle of the day. Approvals and change processes take time.
• Scale: agencies and companies often run dozens or hundreds of WordPress instances. They cannot all be touched at once.
• Dependencies: hosted environments with pinned versions, customized cores, disabled automatic updates.

WordPress.org has enabled forced automatic updates for affected versions. That helps, but it covers far from everything. Relying on it alone means relying on something you do not control. The result: the vulnerable code stays vulnerable for a while, even for teams that want to do everything right. What is needed is something that closes the attack path immediately, independent of the patch cycle.

How does Cloudflare protect against the flaw before you patch?

Through virtual patching. A rule at the edge intercepts the exploit request before it ever reaches WordPress. The code itself remains unchanged for the time being, but the path to it is closed.

For wp2shell, Cloudflare rolled out an emergency rule in its Web Application Firewall, coordinated with the WordPress security team, on July 17, 2026 at 17:03 UTC, before the details became public. Anyone using the Managed Rules was protected automatically, in many cases earlier than site owners even knew about the flaw. Even the free ruleset applies here. The rules target two points: the parameters of the SQL injection and the requests that trigger code execution via the REST API.

The honest caveat belongs in the picture: this does not replace the patch, it bridges the time until then. Cloudflare calls it "defense in depth while you patch." That is exactly the point: reduce the risk immediately, then patch calmly. Cloudflare has described the technical details in its own blog post .

The Cloudflare building blocks that apply here

Four components work together against exactly this attack:

• Web Application Firewall with Managed Rules : the heart of virtual patching. The emergency rule against wp2shell landed here automatically and blocks the exploit requests to the batch endpoint.
• Rate Limiting : slows down the mass exploitation attempts that typically roll in against the affected endpoints once an exploit is published.
• Bot Management : exploitation runs almost entirely automated, through scanners and botnets. Scoring bot behavior intercepts these waves before they can do damage.
• DDoS protection : after a disclosure, the same endpoints are often flooded with requests. The always-on protection at layer 7 fends that off.

Each of these components lowers the risk. None of them replaces the update. The order is: shield immediately, then patch in an orderly way.

What you should do now

1. Check whether you are affected. The researchers provide a free checker at wp2shell.com : enter a domain and the tool tells you whether your WordPress installation is vulnerable.
2. Check versions and patch. If an installation runs 6.9.0 through 6.9.4 or 7.0.0 through 7.0.1, it belongs on 6.9.5 or 7.0.2 immediately; older branches go to 6.8.6.
3. Do not blindly trust automatic updates. Actively verify that the update has actually arrived.
4. Put a WAF in front. With Managed Rules active, the emergency rule kicks in and closes the attack path, even while you are still testing and rolling out.
5. Check for compromise. Watch for unknown PHP files in the upload directories, newly created administrator accounts, and suspicious requests to /wp-json/batch/v1 in your logs. wp2shell leaves behind webshells that stay active even after the patch.
6. Back up and document. Take a backup before you intervene, and record what you have checked.

How KAEMI supports you

KAEMI is a Cloudflare partner (Authorized Service Delivery Partner) and sets up exactly this protection for you. Concretely, that means we put the Web Application Firewall in front of your sites, verify that the Managed Rules cover the current threat, tune rate limiting and bot rules to your traffic, and examine your WordPress installations for signs of compromise.

There are two ways to do this. As a one-off, so your sites are protected now while you patch at your own pace. Or permanently as a managed service, in which we continuously manage and monitor security at the edge for you. We bundle both in our Application Security and in our Cloudflare services .

The point that matters with wp2shell: a WAF can stand in front of your site within a few hours and closes the window of exposure before the patch has landed everywhere. If you run several sites or are unsure whether you are affected, get in touch . We will take a look together, with no obligation.

Sources

• Checker from the researchers (Searchlight Cyber): wp2shell.com
• heise online: WordPress vulnerability wp2shell under attack
• Golem: WordPress flaws put millions of websites at risk
• Borncity: Critical WordPress vulnerability wp2shell allows CMS takeover
• Cloudflare Blog: How Cloudflare protects against the WordPress vulnerabilities