wp2shell POST Variant Bypasses URL-Only WordPress Defenses
The development concerns the wp2shell chain involving CVE-2026-63030 and CVE-2026-60137. WordPress released versions 7.0.2, 6.9.5 and 6.8.6 on July 17 to address the underlying flaws. WordPress said the chain combines REST API batch-route confusion with SQL injection and can lead to remote code execution; releases before WordPress 6.8 are not affected.
Cloudways said earlier virtual patches blocked requests targeting the batch route in the URL. Its newly reported variant instead buries the rest_route parameter for the batch endpoint in the POST body. According to the provider, defenses matching only the URL could miss that request form, while body inspection allowed its revised rule to block it. Cloudways credited Imunify360 with helping validate mitigation changes.
Prior research from Wiz documented exploitation after the WordPress disclosure, including persistent webshell deployment. Wiz said the chain targets the REST API batch endpoints and reported that unusual successful responses, purpose-built user-agent strings and unexpected PHP files can help identify attacks. The new Cloudways observation changes the request location defenders must inspect, but it does not alter the two CVE identifiers or affected WordPress versions.
Administrators should install the official WordPress updates rather than rely solely on a web application firewall. WordPress 7.0 users should run 7.0.2 or later, 6.9 users should run 6.9.5 or later, and 6.8 users should run 6.8.6 or later. Organizations unable to update immediately should inspect both URLs and POST bodies for batch-route abuse, review web roots for unfamiliar PHP files and investigate unexpected administrative accounts.
Cloudways said virtual patching provides temporary protection, not a substitute for updating WordPress core. Defenders should confirm deployed versions across all sites, retain relevant web and WAF logs, and monitor the REST batch endpoint for anomalous traffic. Any suspected compromise warrants incident response and credential review because earlier wp2shell activity included database access and persistent server-side code.