wp2shell-scan

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.

Cosa rileva

Dopo lo sfruttamento, gli strumenti wp2shell lasciano in genere due artefatti di persistenza, entrambi rilevati da questo strumento:

1. Un amministratore rogue — diverse varianti osservate: user_login = wpsvc_<hex> / wp2_<hex> / w2s_<hex>, oppure un'email su un dominio dell'attaccante (@wp2shell.*, @shellcode.*, @wordpress-svc.internal, @wordpress-noreply.net, @x.lol), con il ruolo administrator. (Nota: @system.local è un'email amministrativa legittima segnaposto su alcuni host gestiti — volutamente non trattata come IOC.)
2. Una webshell camuffata da plugin — wp-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.

Installazione

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.

Utilizzo

# 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.

Output di esempio

[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

⚠️ Non dimenticare backup, snapshot e template

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.

Dopo la pulizia

--clean rimuove l'admin + la webshell e ruota i salt. Devi comunque:

1. Aggiorna il core di WordPress alla versione 7.0.2 / 6.9.5 / 6.8.6 (la vera correzione).
2. Reimposta tutte le password admin e reinstalla/verifica core + plugin (wp core verify-checksums).
3. Ruota tutti i segreti che il sito poteva leggere — password DB, chiavi API, credenziali SMTP — presupponi che siano trapelati.
4. Rivedi cosa ha eseguito la shell — i tuoi log di accesso registrano i valori dei comandi ?c=.
5. Blocca la rotta batch al tuo edge/origin finché ogni sito non è aggiornato (/wp-json/batch/v1, ?rest_route=/batch/v1, incl. codifica %2f). Mettila all'origin se una CDN potrebbe far passare il percorso REST.

Verifica manuale (senza strumento)

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/

Preferisci un agente AI?

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.

Licenza

MIT — vedi LICENSE. Fornito così com'è, senza garanzia. Costruito e testato sul campo durante un incidente reale dal team di InstaWP.