2026-07-28 · Team Fenrir

wp2shell: come verificare se il tuo WordPress è esposto

wp2shell è il nome con cui è conosciuta una catena di due vulnerabilità di WordPress — CVE-2026-63030 e CVE-2026-60137 — che insieme permettono l’esecuzione di codice da remoto senza autenticazione, su un’installazione WordPress di default e senza plugin. Le correzioni esistono dal 17 luglio 2026. Lo sfruttamento in rete è confermato. La domanda operativa è una sola: la tua versione è tra quelle colpite? Si verifica in un comando.

Che cos’è wp2shell, in due righe?

Non è un bug solo: sono due, e contano solo se messi in fila.

• CVE-2026-63030 — un problema di route confusion sull’endpoint REST di batch. NVD lo descrive come un difetto che, «combinato con la SQL injection su author__not_in di WP_Query (CVE-2026-60137), potrebbe consentire a un attaccante di eseguire SQL injection e ottenere Remote Code Execution».
• CVE-2026-60137 — WordPress «non sanifica correttamente il parametro author__not_in di WP_Query», con possibile SQL injection quando un plugin o un tema passa a quel parametro input non fidato.

Letta bene, la seconda CVE da sola non è un disastro universale: serve che qualcosa passi input non fidato a quel parametro. È la prima a fornire quel qualcosa, e a farlo senza credenziali. Da qui la gravità: la catena trasforma due difetti di media portata in un accesso pre-autenticazione. In termini MITRE ATT&CK è un caso da manuale di T1190 — Exploit Public-Facing Application: «gli avversari possono tentare di sfruttare una debolezza in un host esposto su internet per ottenere accesso iniziale a una rete».

Una nota di onestà, visto che probabilmente sei arrivato qui cercando proprio quella parola: «wp2shell» non compare né nei record CVE né nell’advisory di WordPress. È l’etichetta che il settore ha attaccato alla catena. I nomi ufficiali sono i due CVE.

Sul funzionamento interno ci fermiamo qui. L’endpoint di batch non è un segreto — è documentato dal 2020, introdotto in WordPress 5.6, accetta fino a 25 sotto-richieste per chiamata e si raggiunge su /wp-json/batch/v1 — ma la meccanica dell’attacco non serve a chi deve difendersi, e la vulnerabilità è sotto sfruttamento attivo. Quello che serve è sapere se sei esposto.

Sono vulnerabile? La matrice delle versioni

Questa è la tabella che conta. È ricavata dai record NVD e dall’annuncio ufficiale di rilascio.

WordPress.org lo scrive in modo netto: «WordPress 6.9 è affetta da entrambe le vulnerabilità», «WordPress 6.8 è affetta solo dalla prima», «le versioni di WordPress precedenti alla 6.8 non sono affette». Attenzione a quest’ultima riga: non affette da queste due CVE non vuol dire sicure. Vale sempre il principio che «solo la versione più recente di WordPress è attivamente supportata».

Due dati sulla gravità, con l’attribuzione corretta — perché le fonti non concordano e vale la pena saperlo. Su CVE-2026-63030 il CNA (WPScan) assegna CVSS 9.8, CRITICAL, mentre il record aggiuntivo di CISA-ADP assegna 7.5, HIGH. Su CVE-2026-60137 il rapporto si inverte: 5.9 (MEDIUM) dal CNA, 9.1 (CRITICAL) da CISA-ADP. Non esiste un punteggio primario NVD. Il numero che decide la priorità, però, non è nessuno di questi: è che CISA ha inserito entrambe le CVE nel catalogo Known Exploited Vulnerabilities il 21 luglio 2026, con scadenza di rimedio fissata al 4 agosto 2026. Nel catalogo KEV ci finisce ciò che risulta sfruttato in rete.

Come verifico la versione dalla riga di comando?

Sul server. Con WP-CLI, una riga:

# La versione installata
wp core version

# Con dettagli aggiuntivi (revisione DB, lingua del pacchetto)
wp core version --extra

Senza WP-CLI, la versione è nella bacheca sotto Aggiornamenti, o nel numero in basso a destra nell’area di amministrazione.

E i “wp2shell checker” che interrogano il sito da fuori? Servono a farsi un’idea su larga scala, non a certificare il tuo sito. Un controllo remoto deduce la versione da readme.html o dal meta tag generator: due elementi che moltissime installazioni rimuovono per abitudine di hardening, che le cache possono servire vecchi, e che un attaccante entrato può modificare. Il risultato è che uno scanner esterno può dirti «sicuro» mentre non lo sei — o allarmarti a vuoto. Il controllo autorevole è quello fatto sul filesystem. Se gestisci più di un sito, questa è esattamente la differenza tra sapere e sperare: è il motivo per cui Fenrir WP Bridge tiene l’inventario delle versioni di tutti i siti in un punto solo, invece di lasciarti aprire venti bacheche.

Gli aggiornamenti automatici mi hanno già salvato?

Forse. Non darlo per scontato, e non perché WordPress non abbia fatto la sua parte: per questa release il progetto ha «attivato aggiornamenti forzati tramite il sistema di auto-update per i siti che eseguono versioni affette». Molti siti si sono aggiornati da soli nella notte del 17 luglio.

Restano fuori quattro categorie, e sono più diffuse di quanto sembri:

1. Siti sotto controllo di versione. Gli aggiornamenti automatici del core sono disattivati quando WordPress rileva un checkout Git o SVN.
2. Siti con la costante AUTOMATIC_UPDATER_DISABLED impostata in wp-config.php, o con WP_AUTO_UPDATE_CORE a false.
3. Siti in cui il cron di WordPress non gira — perché disattivato, perché il traffico è scarso, perché sostituito da un cron di sistema mal configurato. L’aggiornamento automatico ha bisogno di essere innescato.
4. Siti installati prima della 5.6 e mai riconfigurati: fino a quella versione l’auto-update di default copriva solo le release minori, e la configurazione ereditata resta.

In tutti e quattro i casi il sito è rimasto sulla versione vulnerabile mentre lo sfruttamento era già in corso. Da qui la regola: verifica, non dedurre.

Come capisco se mi hanno già bucato?

Se il tuo sito è stato esposto con una versione vulnerabile tra il 17 luglio e il momento dell’aggiornamento, l’aggiornamento non basta: chiude la porta, non sfratta chi è già entrato. Quattro controlli, in ordine di resa.

1. Integrità dei file del core. Confronta ogni file con i checksum ufficiali di WordPress.org:

wp core verify-checksums --include-root
wp plugin verify-checksums --all

--include-root è il flag che conta: senza, vedi solo i file modificati; con, ti segnala anche i file estranei comparsi nella radice del sito. Una backdoor raramente modifica un file esistente — di solito ne aggiunge uno. Se trovi qualcosa, il seguito è il mestiere raccontato in come riconoscere una web-shell su WordPress: MITRE cataloga quella persistenza come T1505.003.

2. Amministratori che non hai creato. È l’indicatore di compromissione più immediato dopo un RCE, e ATT&CK lo cataloga come T1136.001 (Create Account: Local Account). La colonna che conta è la data di registrazione:

wp user list --role=administrator \
  --fields=ID,user_login,user_email,user_registered

Un amministratore registrato dopo il 17 luglio che non riconosci è un incidente fino a prova contraria. La stessa domanda va posta agli utenti con ruolo editor: un attaccante accorto non chiede sempre i privilegi massimi.

3. Attività pianificate estranee. Il cron di WordPress è un posto comodo per farsi rieseguire:

wp cron event list --fields=hook,next_run,recurrence

Cerca hook con nomi che non appartengono né al core né ai tuoi plugin.

4. Log del web server. Cerca le richieste POST verso l’endpoint di batch, nelle due forme in cui può comparire a seconda dei permalink:

grep -E 'POST .*(wp-json/batch/v1|rest_route=/batch/v1)' /var/log/nginx/access.log

Traffico legittimo verso quell’endpoint esiste — lo usa l’editor a blocchi — quindi non è di per sé un allarme. Quello che conta è il contesto: raffiche da un singolo IP, user agent anonimi, richieste da reti che non c’entrano nulla con i tuoi redattori, e soprattutto una raffica seguita da comparse sospette nei tre controlli precedenti.

Cosa faccio se trovo qualcosa?

La procedura ufficiale di WordPress.org per un sito compromesso è lunga; questi sono i punti che si sbagliano più spesso.

• Documenta prima di pulire. «Il primo passo concreto da compiere dopo una compromissione è la documentazione»: è la base dell’incident report, e la cancellazione frettolosa distrugge le prove che servono a capire come sono entrati.
• Non reinstallare il core dalla bacheca. L’indicazione ufficiale è esplicita: «quando reinstalli, assicurati di non usare le opzioni di reinstallazione in WP-ADMIN», perché quegli installer «spesso sovrascrivono solo i file esistenti, e le compromissioni introducono spesso file nuovi». Si reinstalla la stessa versione via SFTP, sostituendo /wp-admin e /wp-includes.
• Ruota le chiavi segrete, non solo le password. Cambiare le password non butta fuori chi ha già una sessione aperta. Vanno aggiornate le secret key in wp-config.php: «questo costringerà chiunque sia ancora collegato a uscire».
• Cambia le credenziali due volte: una durante la bonifica e una a bonifica finita, perché «devi cambiare le password del sito dopo esserti assicurato che sia pulito».
• Controlla .htaccess, in tutte le directory in cui compare: la documentazione ufficiale lo segnala come il file più spesso modificato per scopi malevoli.

Se il sito tratta dati di clienti o ordini, a questo punto la domanda non è più tecnica e va portata a chi di dovere. Noi ci fermiamo dove finisce il mestiere: rimettere in piedi il sito e capire il vettore.

Perché il monitoraggio conta più della singola patch

wp2shell è la dimostrazione di un problema strutturale, non un caso isolato. La finestra tra il rilascio della correzione (17 luglio) e l’inserimento nel catalogo KEV (21 luglio) è di quattro giorni: tanto è passato tra «esiste una patch» e «è confermato che qualcuno la sta sfruttando su siti veri». In quella finestra, la differenza tra un sito aggiornato e uno fermo non l’ha fatta la bravura di nessuno: l’ha fatta un cron che girava o non girava.

Nessuno legge l’annuncio di sicurezza di WordPress alle due di notte. Ma qualcosa deve accorgersene: che è uscita una release di sicurezza, che tre dei tuoi venti siti non l’hanno presa, che uno di quei tre ha un amministratore in più rispetto a ieri. È il lavoro di Fenrir per WordPress sui siti e di Fenrir SOC sui server: inventario delle versioni, integrità dei file, correlazione dei log e una risposta che parte prima che tu apra il terminale. La patch la applichi una volta. La verifica che serva ancora, ogni notte.