The recent disclosure of the wp2shell pre-authentication Remote Code Execution (RCE) vulnerability sent shockwaves through the WordPress community. Given that it affects WordPress core, the blast radius was massive.
At Cloudways, we operate on a shared responsibility model. Because we do not offer fully managed WordPress hosting, patching core CMS vulnerabilities typically falls outside our direct scope. However, when a threat of this magnitude emerges, “not our scope” isn’t an acceptable answer as our customers’ WordPress assets are on the line.
Understanding the Threat: wp2shell (CVE-2026-63030)
On July 17, 2026, the WordPress Security Team rolled out critical out-of-band updates (versions 7.0.2, 6.9.5, and 6.8.6) to neutralize an exploit chain dubbed wp2shell. This is every site owner’s worst nightmare: a pre-authentication Remote Code Execution (RCE) flaw residing natively within WordPress core. The attack requires zero privileges, bypasses login screens, needs no third-party plugins, and functions flawlessly against default installations.
The exploit mechanics rely on chaining two distinct flaws. First, attackers leverage a route-confusion bug within the WordPress REST API batch endpoint (CVE-2026-63030). This trickery bypasses authentication checks, allowing them to funnel malicious input directly into a separate SQL injection vulnerability (CVE-2026-60137). The result? A single unauthenticated HTTP request grants attackers full database control and arbitrary code execution on the server.
Vulnerability Scope:
- Impacted Versions: WordPress 6.9.0 through 6.9.4, and 7.0.0 through 7.0.1. (Versions below 6.8 are shielded from the RCE chain).
- Secure Releases: 7.0.2, 6.9.5, and 6.8.6.
While the WordPress core team pushed forced auto-updates to stem the bleeding, relying on auto-updates isn’t a silver bullet. Many production, staging, and heavily customized agency sites intentionally disable automated core updates to prevent breaking changes. Threat actors know this, making these unprotected environments prime targets for automated exploit bots.
Seamless Protection: No Midnight Scramble Required
When a zero-day of this magnitude drops, the standard industry response is a frantic rush to identify vulnerable assets and apply patches before exploitation begins. For Cloudways customers, that panic was entirely bypassed.
Although we operate under a shared responsibility model under which core CMS updates are technically managed by the user, we refuse to leave our customers exposed when critical global threats emerge. We believe in proactive, defense-in-depth security.
If you host your WordPress sites with us, this requires no action on your part. There was no need for midnight emergency patching or urgent audits to identify customer sites affected by vulnerable WordPress core versions. While the broader internet was still digesting the vulnerability disclosure, our security engineering teams had already deployed fleet-wide virtual patches. Our infrastructure absorbed the initial wave of automated attacks at the edge, ensuring your business stayed online, secure, and completely uninterrupted while you planned your core updates.
Here is a look behind the scenes at how our security teams went above and beyond to protect customer sites, secure the platform, and give our customers the time they needed to safely upgrade their WordPress installations, so they could sleep through the storm.
1. Immediate Alerting and Communication
The moment the vulnerability details dropped, our first priority was getting the right information to the right people. We immediately deployed widespread alerts directly into the application security dashboards within our Cloudways platform and pushed urgent notifications through email as well.
Our goal was to ensure every customer knew whether they were vulnerable to wp2shell and what steps they needed to take to secure their environments.
2. Deploying a Virtual Patch Fleet-Wide
While we alerted customers, we knew that manually updating WordPress core takes time, and attackers were actively using that time to scan and exploit unpatched sites.
Given the critical, pre-authentication nature of wp2shell, our security engineers rolled out a platform-wide virtual patch across our entire WordPress customer base within hours of the disclosure. This mitigation blocked malicious payloads, effectively shielding vulnerable sites and buying our customers the necessary time to test and apply the official WordPress update.
3. Refining the Ruleset for Business Continuity
Initial virtual patches for complex vulnerabilities can sometimes be a blunt instrument. While our first patch successfully blocked the exploits, we wanted to ensure zero disruption to legitimate site functionality.
Shortly after the initial rollout, our team released a narrower, highly optimized adjustment to the virtual patch. This updated rule allowed the known-safe WordPress batch mode to operate flawlessly, while continuing to strictly block the specific request forms capable of reaching the vulnerable wp2shell behavior.
4. Catching the Curveball: The POST Body Variant
Security is a continuous game of cat and mouse. As attackers realized their initial exploits were being blocked by edge firewalls across the web, they adapted.
Through our continuous monitoring, our Threat Intelligence team identified a new, stealthy variant of the wp2shell attack in the wild. Attackers were moving the trigger rest_route=/batch/v1 out of the URL string and burying it deep within the POST body.
Unfortunately, most standard virtual patches released in the wider industry initially only matched against the URL, leaving sites wide open to this new bypass. Because we were actively monitoring the situation, we caught this behavior immediately. We updated our virtual patch to inspect the POST body, blocking the new variant in its tracks before it could impact our customers.
A Collaborative Effort
We didn’t do this alone. Fast, effective incident response relies on strong industry collaboration. We want to extend a massive thank you to our security partners at Imunify360. Their teams worked closely with us around the clock during this time-sensitive crisis, sharing threat intelligence and helping us validate our mitigation strategies.
What You Need to Do Next
While our virtual patches have successfully shielded our customers from the wp2shell exploits (including the POST body variants), a virtual patch is not a permanent substitute for a core software update.
If you have not already done so, please log in to your WordPress admin dashboard and update to the latest secure versions (7.0.2, 6.9.5, 6.8.6 or later) as soon as possible.
At our core, we believe that your security is our success. While we rely on a shared responsibility model for day-to-day operations, you can rest assured that when the alarm bells ring, our team is always ready to step up and defend your digital assets.
Stay safe, stay updated, and as always, reach out to our support team if you have any questions!
Asif Wani
Asif Wani is the Manager of Security Engineering at DigitalOcean, leading the Product and Infrastructure Security teams. With extensive cybersecurity experience, he drives initiatives that strengthen DigitalOcean's security posture and help deliver a secure, reliable, and trusted cloud platform.
