instawp/wp2shell-scanRileva e ripulisci la compromissione di WordPress da wp2shell (CVE-2026-63030) — eseguibile in blocco, sola lettura per impostazione predefinita
Rileva e ripulisci il compromesso wp2shell (CVE‑2026‑63030) su uno o più siti WordPress.
wp2shell è la vulnerabilità di esecuzione remota di codice pre-autenticazione risolta in WordPress 7.0.2 / 6.9.5 / 6.8.6 (2026‑07‑17). Un PoC pubblico è apparso entro un giorno e lo sfruttamento di massa è seguito entro ~48 ore. La patch chiude il varco — ma un sito sfruttato prima della patch è già compromesso, e l'aggiornamento non rimuove la persistenza dell'attaccante.
Questo strumento trova e rimuove quella persistenza. È un singolo script Bash con poche dipendenze che viene eseguito in sola lettura per impostazione predefinita e può scansionare migliaia di siti in un'unica passata.
⚠️ Questo è uno strumento difensivo. Non contiene codice di exploit. Esegui uno snapshot del sito prima di lanciare
--clean.
Dopo lo sfruttamento, gli strumenti wp2shell lasciano in genere due artefatti di persistenza, entrambi rilevati da questo strumento:
user_login = wpsvc_<hex> / wp2_<hex> / , oppure un'email su un dominio dell'attaccante (, , , , ), con il ruolo . (Nota: è un'email amministrativa segnaposto su alcuni host gestiti — volutamente trattata come IOC.)w2s_<hex>@wp2shell.*@shellcode.*@wordpress-svc.internal@wordpress-noreply.net@x.loladministrator@system.localwp-content/plugins/<plausible-name>-<6hex>/<same>.php: un piccolo file PHP (~1,3 KB) con un falso header Author: WordPress.org Community, protetto da un token, che espone un'interfaccia ?c=<command>.Rileva anche il caso generico: qualsiasi piccolo file PHP sotto wp-content/ che convoglia $_GET['c'] in un sink di comando/eval.
curl -fsSLO https://raw.githubusercontent.com/InstaWP/wp2shell-scan/main/wp2shell-scan.sh
chmod +x wp2shell-scan.sh
Richiede bash, find, grep e un client mysql/mariadb. WP‑CLI viene usato quando presente (rimozione utente più pulita) ma non è richiesto — il rilevamento delle webshell non necessita affatto di un database.
# Scansiona UN sito (sola lettura)
./wp2shell-scan.sh --path /var/www/example.com
# Scansiona OGNI installazione WordPress sotto una directory base (bulk)
./wp2shell-scan.sh --base /var/www
./wp2shell-scan.sh --base /home # hosting condiviso
# Rilevamento automatico dei layout comuni (/var/www/*, /home/*/public_html, ...)
./wp2shell-scan.sh
# Leggibile da macchina
./wp2shell-scan.sh --base /var/www --json > report.json
# PULIZIA — quarantena + rimozione backdoor, rotazione salt wp-config (disconnette tutti)
./wp2shell-scan.sh --base /var/www --clean --yes
# Controlla un dump di BACKUP / SNAPSHOT / TEMPLATE prima di ripristinarlo (vedi avviso sotto)
./wp2shell-scan.sh --sql /path/to/backup.sql
Gli artefatti rimossi vengono spostati in una directory di quarantena (non eliminati del tutto) così conservi le prove. Il codice di uscita è 1 quando viene trovato un compromesso (scan) o dopo la pulizia (clean), 0 quando è tutto pulito — utile per 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
Pulire un sito live NON pulisce i tuoi backup. Un backup, uno snapshot o un template di staging/blueprint catturato mentre il sito era compromesso contiene ancora l'account admin dell'attaccante — ripristinarlo (o creare un nuovo sito da esso) ri-infetta all'istante. L'abbiamo imparato a nostre spese: dopo aver ripulito ogni sito live interessato, continuavano ad apparire siti nuovi con la backdoor perché venivano creati da uno snapshot di template avvelenato.
Controlla un dump prima di ripristinarlo:
./wp2shell-scan.sh --sql /path/to/backup.sql
./wp2shell-scan.sh --sql backup1.sql --sql backup2.sql.gz # ripetibile, supporta .gz
Il codice di uscita è 1 se un dump è avvelenato. Se lo è: non ripristinarlo — pulisci prima il sito live, poi fai un backup nuovo ed elimina/sostituisci qualsiasi snapshot o template creato durante la finestra di esposizione.
--clean rimuove l'admin + la webshell e ruota i salt. Devi comunque:
wp core verify-checksums).?c=./wp-json/batch/v1, ?rest_route=/batch/v1, incl. codifica %2f). Mettila all'origin se una CDN potrebbe far passare il percorso REST.Amministratori rogue:
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;
Plugin webshell:
find wp-content/plugins -maxdepth 1 -type d -regextype posix-extended -regex '.*-[0-9a-f]{6}$'
grep -rl "\$_GET\['c'\]" wp-content/plugins/
Vedi CLEANUP-WITH-CLAUDE.md per un prompt pronto da incollare che guida Claude Code (o qualsiasi agente di codifica capace) attraverso lo stesso rilevamento e la stessa pulizia su un singolo sito, con conferma umana prima di ogni passaggio distruttivo.