wp2shell Mass Scanning: Mitigating the Public Exploit Wave
Hey team,
With the wp2shell situation escalating, I wanted to share some quick findings and get a pulse on how everyone else is handling the noise. The combination of CVE-2026-63030 and CVE-2026-60137 is particularly nasty because it bypasses authentication entirely, leading to unauthenticated RCE on vulnerable WordPress instances.
Given the public exploit code availability, the barrier to entry is zero. We are observing payloads attempting to spawn a reverse shell directly via the REST API endpoints. If you haven't patched 6.9 or 7.0 yet, you need to assume compromise.
We are currently filtering for specific anomalous patterns in the URI parameters. For those running Apache or Nginx, you can check your access logs for the specific injection strings seen in the wild:
grep -iE "eval\(|base64_decode" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq
If you suspect a breach has already occurred, you might want to scan your webroot for common webshells that this exploit drops:
find /var/www/html -type f -name "*.php" -exec grep -l "shell_exec\|passthru\|proc_open" {} \;
Given the speed of mass scanning, how are you handling this at scale? Are you forcing updates across all clients immediately, or relying purely on WAF signatures for now?
The noise in our SIEM is unreal right now. We deployed a Sigma rule immediately, but we're getting hammered with false positives from legitimate plugin updates. If anyone needs a KQL query for Azure/Sentinel to narrow down to the specific malicious User-Agent strings seen in this campaign, try this:
DeviceNetworkEvents
| where RemoteUrl has "wp-" and RequestHeader has "wp2shell"
| summarize Count() by SourceIP
Just be careful tuning it; some scanners rotate the UA string rapidly to look like legitimate bots.
We're an MSP, so we started forced updates via Ansible at 0400 UTC. It broke a few legacy sites running incompatible page builders, but that's better than explaining a crypto-miner infection to a client.
We are also temporarily dropping all POST requests to /wp-/wp/v2/ from unauthenticated IPs in our Nginx config until the patching is 100% complete. Has anyone seen successful exploitation attempts originating from residential IPs, or is it mostly VPS hosting providers?
For those tuning their SIEMs, filtering for common PHP execution functions within POST requests to the REST API has been the most reliable signal. It helps distinguish the exploit from standard plugin updates. You can spot-check your logs with:
grep "POST /wp-/" access.log | grep -Ei "eval\(|system\("
We noticed that blocking generic 'bot' User-Agents isn't working because this campaign spoofs legitimate browser strings. Has anyone seen the payloads shifting to encode the commands differently?
Great point on the REST API filtering, Rosa. I’d also recommend checking the access logs for generic scanner User-Agents. These mass scans often forget to spoof headers, making them easy to spot at the edge. We've been blocking IPs matching patterns like python-requests or empty strings preemptively.
Here’s a quick snippet to find them in Nginx logs:
grep POST /var/log/nginx/access.log | grep -E '(python-requests|curl/)' | cut -d' ' -f1 | sort -u
This helps offload the noise before it hits your WAF or SIEM.
Solid points on detection. While we harden, I’ve been scanning for IoCs by finding recently modified PHP files. If the exploit drops a webshell, it usually has a new creation time. Here’s a quick one-liner to hunt for files touched in the last 24 hours on the docroot:
find /var/www/html -name "*.php" -mtime -1 -ls
Also, make sure your off-site backups are immutable; if a site gets wiped, you'll need a clean restore point fast.
If public-facing REST API endpoints aren't critical for your site's operation, consider temporarily restricting access by IP. Containment is key here. For those running Nginx, this quick block stops the noise while you coordinate patching:
nginx location ~ ^/wp-/ { allow 192.168.1.0/24; deny all; }
For environments where patching isn't immediate, consider virtual patching at the WAF level to buy time. We’re seeing success blocking the specific endpoint pattern with ModSecurity. This rule drops requests matching the exploit signature before they hit the backend:
apache
SecRule REQUEST_URI "@rx /wp-/.*vulnerable_route"
"id:1001,phase:2,deny,status:403,msg:'wp2shell attempt'"
It effectively neutralizes the unauth RCE vector while you test updates.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access