Pantheon says its infrastructure recorded more than 45 million attempts to exploit wp2shell from nearly 150,000 network sources during the first week after disclosure. The new telemetry, published August 22, turns a month-old WordPress flaw into a current response lesson: an internet-facing site may face mass automation before its owner finishes a normal patch assessment.
The number describes requests, not 45 million compromised sites. Pantheon saw WordPress-specific patterns hit Drupal systems that could never be vulnerable. The noisy targeting still carried a real consequence. Wiz observed successful exploitation of self-hosted cloud WordPress instances followed by persistent webshell installation.
One week brought 45 million attempts
The scale is Pantheon’s first-party platform telemetry, reported by its CISO Joey Stanford in a contributed article on Cyber Security News. The page identifies his Pantheon role and does not label the contribution as sponsored. Pantheon did not publish the underlying dataset or a count of successful compromises. Its first-week total was about 20 times the request volume it observed during Drupalgeddon, and the traffic came from almost 150,000 network sources.
Stanford described the operational shift plainly: “Disclosure used to buy defenders a head start. Increasingly, it’s the starting gun for the attackers, too.” Pantheon says it also stood up a honeypot to capture live samples and study what attackers attempted after entry.
Wiz’s separate cloud dataset supplies useful bounds. At disclosure, Wiz found that 60% of organizations running WordPress in its dataset had at least one vulnerable instance and 25% exposed one to the internet. Those figures fell to 50% and 10% within 24 hours. Wiz was evaluating its own product telemetry, so those percentages should not be treated as a global WordPress census.
Two flaws reached server code
The wp2shell chain joins two WordPress Core flaws. CVE-2026-63030 confuses nested REST API batch routing. That reachability flaw exposes the query path affected by CVE-2026-60137, where the public author_exclude input reaches an insufficiently sanitized author__not_in query argument. Together, the flaws can turn an unauthenticated batch request into SQL injection and then remote code execution.
F5 Labs captured a fully formed 735-byte attempt from 185[.]242[.]3[.]238. It used nested requests against the batch endpoint and a UNION-based injection that wrapped the test value OK between || markers. The same payload reached at least two US sensor instances.
Figure details
The diagram uses two separate left-to-right rows. The upper attempt-volume row begins with the July 17 WordPress fixes, then shows more than 45 million attempts from nearly 150,000 sources in the first week and WordPress request patterns also reaching Drupal systems. The lower confirmed-compromise row shows an affected WordPress batch route reaching SQL injection and server code, followed by Wiz-observed persistent webshell installation with the victim count unknown.
The chain affected WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. WordPress 6.8.0 through 6.8.5 was affected by the SQL injection flaw, but not the full two-flaw RCE chain. The WordPress security team released minimum fixes in 7.0.2, 6.9.5, and 6.8.6 on July 17 and enabled forced automatic updates.
Those minimums have been superseded. As of August 22, the vendor’s release record lists WordPress 7.1 as current, with 7.0.4, 6.9.7, and 6.8.8 as newer maintenance releases on those branches.
Automation left recognizable traces
High request volume alone is weak evidence. F5 listed five leading sources for batch-endpoint traffic: 47[.]129[.]160[.]40, 94[.]159[.]96[.]62, 185[.]242[.]3[.]238, 207[.]180[.]249[.]59, and 13[.]140[.]128[.]125. Only traffic from 185[.]242[.]3[.]238 was proven in that report to contain the complete wp2shell payload.
Start with requests to /wp-json/batch/v1, /index.php?rest_route=/batch/v1, and /?rest_route=/batch/v1. Look inside the JSON body for nested requests and author_exclude. Wiz says HTTP 207 or 200 Multi-Status responses to batch requests are a higher-fidelity success signal. User agents containing wp2shell or rezwp2shell identify purpose-built tools.
Then follow the application activity. Wiz observed access to /wp-admin/plugin-install.php?tab=upload, POST /wp-admin/update.php?action=upload-plugin, /wp-json/wp/v2/users?context=edit, admin-ajax.php?template=../../../wp-config, and authenticated HTTP 200 responses from /wp-admin/. It also found a 150 KB webshell disguised as the CMSmap plugin and another plugin registering /morning/v1/[REDACTED] with __return_true before decoding a command from parameter c.
Wiz published these SHA-1 webshell hashes:
2a1410d8e2a8337ac2171cedea8c0fdc47c647a0
58eca847e9eae9e6b08cc211f1559817b71bc4cc
ebea44890f434d5d67ede22009a3f4bb5cac33f8
d9a220c8039f1c4d72cae7ccb8b3a33dec8815be
e9756e2338f84746007235e4cab7a70d5b3ca47fIts network list contains exploitation sources 34[.]81[.]132[.]62, 79[.]177[.]131[.]206, 15[.]157[.]135[.]170, and 94[.]100[.]52[.]128, plus mass-scanning source 172[.]235[.]128[.]52. Wiz removed 45[.]79[.]167[.]238 from its list after confirming it was a legitimate security scanner. That correction is a warning against turning one network match into a compromise verdict.
Patch and prove the site clean
Inventory internet-facing WordPress instances and record the running core version from the application, deployment manifest, or wp core version output. Upgrade to WordPress 7.1 where supported, or at least the current maintenance release for the retained branch. A WAF block on anonymous batch API access can buy time, but it does not repair the query flaw or attest to activity before the block.
For every site exposed while it ran an affected build, preserve web, WAF, PHP, process, file-integrity, database, and WordPress audit records. Search the request values, response states, hashes, IP addresses, plugins, REST routes, admin accounts, and file changes above. Distinguish a downloaded or uploaded plugin from PHP that the server actually executed by correlating filesystem time, web access, PHP or process telemetry, and outbound connections.
Run wp core version and wp core verify-checksums --include-root against each production installation. The expected result is WordPress 7.1, 7.0.4, 6.9.7, or 6.8.8 plus Success: WordPress installation verifies against checksums. That proves the current core version and files. Sites that were exposed still need a historical compromise review because a clean core does not remove a malicious plugin, administrator, or webshell outside the verified files.