instawp/wp2shell-scanDetect & clean up wp2shell (CVE-2026-63030) WordPress compromise — bulk-runnable, read-only by default
Detect and clean up wp2shell (CVE‑2026‑63030) compromise across one or many WordPress sites.
wp2shell is the pre‑authentication remote‑code‑execution vulnerability fixed in WordPress 7.0.2 / 6.9.5 / 6.8.6 (2026‑07‑17). A public PoC appeared within a day and mass‑exploitation followed within ~48 hours. Patching closes the hole — but a site exploited before it was patched is already compromised, and updating does not remove the attacker's persistence.
This tool finds and removes that persistence. It's a single, dependency‑light Bash script that runs read‑only by default and can scan thousands of sites in one pass.
⚠️ This is defensive tooling. It contains no exploit code. Snapshot a site before running
--clean.
Post‑exploitation, wp2shell tooling typically leaves two persistence artifacts, both of which this tool finds:
user_login = wpsvc_<hex> / / , or an email on an attacker domain (, , , , ), with the role. (Note: is a placeholder admin email on some managed hosts — it is deliberately treated as an IOC.)wp2_<hex>w2s_<hex>@wp2shell.*@shellcode.*@wordpress-svc.internal@wordpress-noreply.net@x.loladministrator@system.localwp-content/plugins/<plausible-name>-<6hex>/<same>.php: a tiny (~1.3 KB) PHP file with a fake Author: WordPress.org Community header, gated behind a token, exposing a ?c=<command> interface.It also detects the generic case: any small PHP file under wp-content/ that pipes $_GET['c'] into a command/eval sink.
curl -fsSLO https://raw.githubusercontent.com/InstaWP/wp2shell-scan/main/wp2shell-scan.sh
chmod +x wp2shell-scan.sh
Requires bash, find, grep, and a mysql/mariadb client. WP‑CLI is used when present (cleaner user deletion) but is not required — webshell detection needs no database at all.
# Scan ONE site (read-only)
./wp2shell-scan.sh --path /var/www/example.com
# Scan EVERY WordPress install under a base directory (bulk)
./wp2shell-scan.sh --base /var/www
./wp2shell-scan.sh --base /home # shared hosting
# Auto-detect common layouts (/var/www/*, /home/*/public_html, ...)
./wp2shell-scan.sh
# Machine-readable
./wp2shell-scan.sh --base /var/www --json > report.json
# CLEAN — quarantine + remove backdoors, rotate wp-config salts (logs everyone out)
./wp2shell-scan.sh --base /var/www --clean --yes
# Vet a BACKUP / SNAPSHOT / TEMPLATE dump before restoring it (see warning below)
./wp2shell-scan.sh --sql /path/to/backup.sql
Removed artifacts are moved to a quarantine directory (not deleted outright) so you keep evidence. Exit code is 1 when compromise is found (scan) or cleaned (clean), 0 when clean — handy for cron/CI.
[COMPROMISED] /var/www/example.com — 2 backdoor admin(s), 2 webshell(s)
admin: ID=41 wpsvc_2e1487df8abb <[email protected]> (2026-07-19 06:41:48)
webshell: .../wp-content/plugins/security-headers-manager-8d1d21/security-headers-manager-8d1d21.php
[clean] /var/www/other-site.com
----------------------------------------------------------------
scanned=812 clean=811 compromised=1 cleaned=0
Cleaning a live site does NOT clean your backups. A backup, snapshot, or staging/blueprint template captured while the site was compromised still contains the attacker's admin account — restoring it (or provisioning a new site from it) re-infects instantly. We learned this the hard way: after cleaning every affected live site, brand-new sites kept appearing with the backdoor because they were being provisioned from a poisoned template snapshot.
Vet a dump before you restore it:
./wp2shell-scan.sh --sql /path/to/backup.sql
./wp2shell-scan.sh --sql backup1.sql --sql backup2.sql.gz # repeatable, .gz supported
Exit code is 1 if any dump is poisoned. If it is: do not restore it — clean the live site first, then take a fresh backup, and delete/replace any snapshot or template created during your exposure window.
--clean removes the admin + webshell and rotates salts. You must still:
wp core verify-checksums).?c= command values./wp-json/batch/v1, ?rest_route=/batch/v1, incl. %2f‑encoded). Put it at the origin if a CDN might wave the REST path through.Rogue admins:
SELECT u.ID,u.user_login,u.user_email,u.user_registered
FROM wp_users u JOIN wp_usermeta m ON u.ID=m.user_id
WHERE m.meta_key='wp_capabilities' AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;
Webshell plugins:
find wp-content/plugins -maxdepth 1 -type d -regextype posix-extended -regex '.*-[0-9a-f]{6}$'
grep -rl "\$_GET\['c'\]" wp-content/plugins/
See CLEANUP-WITH-CLAUDE.md for a ready‑to‑paste prompt that drives Claude Code (or any capable coding agent) through the same detection and cleanup on a single site, with human confirmation before each destructive step.