Search intent: urgent operational — WordPress developers and site owners who have patched and now need to know whether they were hit. We cover the vulnerability, affected versions, indicators of compromise, log analysis, incident response and hardening. It complements our WordPress 7 upgrade guide and plugin backdoor analysis.

wp2shell indicators of compromise — what to search for in access logs and on disk, and why patching is not the same as cleaning by CodeAtoZ

wp2shell chains two vulnerabilities disclosed together on 17 July 2026. CVE-2026-63030 is a route-confusion flaw in the REST API batch endpoint (/wp-json/batch/v1), which processes multiple sub-requests in a single HTTP call; improper handling lets a malformed sub-request cause later requests to be routed to unintended handlers, bypassing endpoint allow-lists. CVE-2026-60137 is a SQL injection in the author__not_in parameter of WP_Query, reachable because passing a string instead of an array bypasses type checks.

Individually, each is serious but constrained. Chained, they give an unauthenticated attacker code execution on a default install — no account, no plugins, no user interaction. That is why the WordPress security team took the unusual step of enabling forced background updates, and why wp2shell matters more than the average core advisory. The researchers who found it, at Searchlight Cyber, stated the attack has no preconditions and works against a stock install. See the official WordPress 7.0.2 release note and the Searchlight Cyber advisory.

Version scope matters here because the two CVEs have different reach — and a lot of the summary posts circulating get this wrong by omitting the 6.8 branch entirely.

# single site
wp core version

# across a directory of sites
for d in /var/www/*/; do
  printf "%-40s " "$d"
  wp core version --path="$d" --allow-root 2>/dev/null || echo "?"
done

# expect 7.0.2, 6.9.5 or 6.8.6 (or newer)

If your site was internet-facing and unpatched at any point after 17 July, hunt before you relax. The strongest wp2shell signals reported by responders fall into three groups.

Batch endpoint traffic. Requests to /wp-json/batch/v1 or ?rest_route=/batch/v1 are the attack path. The endpoint has legitimate uses, so presence alone is not proof — but anonymous POST traffic to it from unfamiliar addresses is worth investigating closely.

HTTP 207 responses. Multi-Status responses from the batch endpoint have been reported by incident responders as a high-fidelity indicator of successful exploitation, which makes them the single most useful thing to grep for.

Tool signatures. Purpose-built exploitation frameworks have used user-agent strings containing wp2shell and rezwp2shell. Crude, easily changed, but free to check and occasionally decisive.

LOG=/var/log/nginx/access.log

# 1. any traffic to the batch endpoint
grep -E "batch/v1|rest_route=/batch" $LOG | tail -50

# 2. HTTP 207 from the batch endpoint - strongest signal
grep -E "batch/v1|rest_route=/batch" $LOG | grep -E '" 207 |" 200 ' | tail -50

# 3. known tool user agents
grep -iE "wp2shell|rezwp2shell" $LOG

# 4. who is hitting it, ranked
grep -E "batch/v1|rest_route=/batch" $LOG 
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# remember to check rotated logs too
zgrep -E "batch/v1|rest_route=/batch" /var/log/nginx/access.log.*.gz | head -50

Log evidence may be missing — rotated away, never retained, or behind a proxy that did not preserve the original request. So check the artefacts too. Successful wp2shell exploitation has been used to deploy persistent webshells, which means unfamiliar PHP files, especially in directories that should never contain executable code.

# PHP files in uploads - almost always malicious
find wp-content/uploads -name "*.php" -type f

# anything modified since the disclosure date
find . -type f -name "*.php" -newermt "2026-07-17" 
  -not -path "./wp-content/cache/*" | head -50

# common webshell function calls
grep -rlE "eval(|base64_decode(|shell_exec(|assert(" 
  wp-content/ --include="*.php" | head -30

# verify core files against the official checksums
wp core verify-checksums

# unexpected administrators, newest first
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# scheduled tasks are a common persistence spot
wp cron event list

wp core verify-checksums is the highest-value single command here: it compares your core files against WordPress.org’s published hashes and reports anything altered. It does not cover themes, plugins or uploads, so pair it with the file searches above. Our plugin backdoor write-up covers what these payloads typically look like once you find one.

If you find evidence of compromise, deleting the file you found is not remediation. Attackers routinely place multiple persistence mechanisms, and a single visible webshell is often the least important one. The order that matters:

Take a forensic copy before you change anything — files and database — because cleaning destroys the evidence you may need for a notification decision. Then rotate every credential the server could have exposed: WordPress admin accounts, database, S/FTP and SSH, API keys, SMTP, and any payment gateway keys stored in configuration. Assume anything readable on that server is known to the attacker; the SQL injection component of wp2shell alone can read password hashes. Force a logout of all sessions and invalidate existing auth cookies by rotating the salts in wp-config.php.

For anything transactional or holding personal data, restoring from a known-good backup predating exploitation is usually safer and faster than cleaning in place — provided you patch before returning it to the internet. If customer data may have been accessed, get advice on notification obligations early rather than late. Our WordPress team handles compromise assessment and clean-up.