Il panorama globale della sicurezza informatica è stato scosso da una delle minacce più strutturali e pericolose dell’ultimo decennio per l’ecosistema del Web. Il fulcro del Content Management System (CMS) più utilizzato al mondo è affetto da una gravissima vulnerabilità di Remote Code Execution (RCE) pre-autenticazione, denominata pubblicamente wp2shell. La falla principale è tracciata nei registri internazionali come CVE-2026-63030. Questa non colpisce un componente aggiuntivo di terze parti o un tema grafico obsoleto, ma risiede direttamente all’interno dell’architettura nativa di WordPress Core. Qualsiasi installazione standard esposta su Internet, priva di protezioni adeguate o non aggiornata, risulta intrinsecamente vulnerabile a una compromissione totale e immediata.
I dettagli tecnici rilasciati dalle principali autorità di sicurezza, come il CERT-AgID italiano e l’Agenzia per la Cybersicurezza Nazionale (ACN), confermano scenari allarmanti. La pubblicazione di Proof of Concept (PoC) stabili e l’evidenza di attacchi massivi in corso (in-the-wild) rendono questa crisi un’emergenza prioritaria per amministratori di sistema, agenzie web, aziende e agenzie governative. Per comprendere l’effettiva portata di wp2shell, è necessario analizzare meticolosamente l’anatomia dell’attacco, la catena di exploit utilizzata dai criminali informatici, l’impatto sui database aziendali e le strategie di mitigazione immediate.
Anatomia di un Disastro Annunciato: Cos’è wp2shell?
La vulnerabilità wp2shell non è un singolo difetto isolato, bensì una catena di exploit (exploit chain) che unisce in modo sinergico due diverse debolezze strutturali del codice nativo di WordPress. I due vettori d’attacco combinati consentono a un utente malintenzionato completamente anonimo di bypassare i controlli di sicurezza della piattaforma ed eseguire comandi arbitrari sul server ospitante (RCE).
Il Primo Anello: La Confusione delle Rotte API (CVE-2026-63030)
La prima falla risiede nella gestione degli endpoint batch della REST API di WordPress, specificamente localizzata nell’URI /wp-json/batch/v1. Questo endpoint nasce per consentire agli sviluppatori e alle applicazioni esterne di raggruppare più richieste HTTP in una singola chiamata multiplexed, ottimizzando le performance di comunicazione con il database.
A causa di un difetto logico nella convalida e nel parsing delle rotte interne (noto come route confusion), un utente non autenticato può inviare una richiesta batch formattata in modo malevolo. Questo inganna il sistema, facendo sì che richieste destinate a rimanere protette dal sistema di controllo degli accessi vengano elaborate come se fossero chiamate pubbliche e legittime. Di fatto, la CVE-2026-63030 opera come un bypass dell’autenticazione globale all’interno delle API di WordPress.
Il Secondo Anello: La SQL Injection nel Core (CVE-2026-60137)
Una volta superata la barriera delle API tramite la confusione delle rotte, l’attaccante ottiene l’accesso a funzioni interne di interrogazione del database. Qui entra in gioco la seconda vulnerabilità della catena: la CVE-2026-60137. Si tratta di una falla di tipo SQL Injection (SQLi) annidata profondamente nella classe nativa WP_Query, in particolare nel parametro di filtraggio author__not_in.
Normalmente, WordPress sanifica rigorosamente ogni input destinato a comporre le query SQL dirette al database MySQL o MariaDB. Tuttavia, in determinate circostanze legate all’esecuzione batch e all’elaborazione di questo specifico parametro, i dati forniti dall’utente malintenzionato non vengono sottoposti a escape. L’attaccante può quindi iniettare comandi SQL arbitrari all’interno della query legittima.
[Attaccante Anonimo]
│
▼ (Invia richiesta HTTP POST modificata)
┌────────────────────────────────────────────────────────┐
│ Endpoint REST API: /wp-json/batch/v1 │ -> Sfrutta CVE-2026-63030
│ Bypass logico del controllo delle autorizzazioni │ (Route Confusion)
└──────────────────────────┬─────────────────────────────┘
│
▼ (Iniezione comandi SQL)
┌────────────────────────────────────────────────────────┐
│ Classe WP_Query: parametro 'author__not_in' │ -> Sfrutta CVE-2026-60137
│ Esecuzione di query arbitrarie sul Database │ (SQL Injection)
└──────────────────────────┬─────────────────────────────┘
│
▼ (Esfiltrazione e Compromissione)
┌────────────────────────────────────────────────────────┐
│ Estrazione hash password degli amministratori │
│ Caricamento di una Web Shell ed esecuzione di codice │ -> Compromissione Totale (RCE)
└────────────────────────────────────────────────────────┘
Il Meccanismo di Compromissione e il Pericolo delle Web Shell
L’obiettivo finale del cybercriminale che sfrutta la catena wp2shell è l’ottenimento del controllo remoto del server. Il processo si sviluppa secondo un modello lineare ma devastante, che non richiede alcuna interazione da parte degli utenti legittimi o degli amministratori del sito (zero-click vulnerability).
Fase 1: Scansione Automatica ──> Fase 2: Esfiltrazione DB ──> Fase 3: Cracking Password ──> Fase 4: Upload Web Shell (RCE)
- Scansione e Ricognizione Automatica: Gli attaccanti utilizzano botnet automatizzate per scansionare ampi range di indirizzi IP alla ricerca di siti web che rispondono sull’endpoint REST API batch. Il bot invia piccoli payload di test per verificare se la versione di WordPress risponde alla vulnerabilità di route confusion.
- Esfiltrazione dei Dati e della Tabella
wp_users: Sfruttando la SQL Injection, l’attaccante esegue comandi di dump del database. L’attenzione si concentra sulla tabellawp_users(o la variante con il prefisso personalizzato del database), all’interno della quale sono memorizzati i nomi utente, le email e, soprattutto, gli hash crittografici delle password degli amministratori. - Cracking degli Hash delle Password: Gli hash estratti (solitamente basati sull’algoritmo MD5 modificato da WordPress, ovvero phpass) vengono esportati e processati offline dall’attaccante tramite server ad altissime prestazioni dotati di GPU avanzate, utilizzando dizionari di password o attacchi di forza bruta (brute-force). Se la password dell’amministratore è debole o presente nei leak pubblici, l’accesso amministrativo viene ottenuto in pochi minuti.
- Caricamento della Web Shell (Da cui il nome wp2shell): Una volta decifrata la password, l’attaccante esegue l’autenticazione legittima nel pannello
/wp-admin. Da qui, sfrutta le funzionalità native del CMS (come l’editor dei temi, l’installazione di plugin malevoli o l’uploader dei media) per caricare un file PHP malevolo sul server, comunemente chiamato Web Shell. - Esecuzione Remota di Codice (RCE): La Web Shell fornisce all’attaccante un’interfaccia a riga di comando direttamente nel browser. Da questo momento, il malintenzionato può eseguire comandi di sistema a livello di sistema operativo, manipolare file, scaricare malware, trasformare il server in un nodo per attacchi DDoS o utilizzarlo come testa di ponte per penetrare nella rete locale aziendale.
Versioni Impattate: Chi Rischia Davvero?
La natura di questa vulnerabilità richiede un’analisi attenta delle versioni software installate. Non tutti i rami di rilascio di WordPress reagiscono allo stesso modo, poiché la componente della REST API batch ha subito modifiche strutturali nel corso degli anni.
| Ramo di Versione WordPress | Vulnerabilità Presenti | Livello di Rischio | Stato della Patch di Sicurezza |
|---|---|---|---|
| WordPress da 7.0.0 a 7.0.1 | CVE-2026-63030 + CVE-2026-60137 | CRITICO (Massimo) | Vulnerabile alla catena RCE completa. Richiede aggiornamento a 7.0.2 o superiori. |
| WordPress da 6.9.0 a 6.9.4 | CVE-2026-63030 + CVE-2026-60137 | CRITICO (Massimo) | Vulnerabile alla catena RCE completa. Richiede aggiornamento a 6.9.5 o superiori. |
| WordPress da 6.8.0 a 6.8.5 | Solo CVE-2026-60137 (SQL Injection) | ALTO | Non esposto alla catena RCE tramite API batch, ma vulnerabile a SQLi. Aggiornare a 6.8.6. |
| WordPress <= 6.7.x | Nessuna (Funzionalità batch differente) | BASSO (relativo a wp2shell) | Non affetto dalla catena wp2shell, ma esposto ad altre vulnerabilità storiche se non mantenuto. |
L’elemento che terrorizza gli esperti di sicurezza è l’assenza di prerequisiti. Molte delle vulnerabilità critiche del passato richiedevano che sul sito fosse attivo un e-commerce basato su WooCommerce, o che fosse presente un plugin di form specifico (come Contact Form 7 o Gravity Forms). Nel caso di wp2shell, un’installazione “pulita”, appena configurata e priva di qualunque plugin, è attaccabile fin dal primo secondo in cui viene connessa alla rete pubblica.
Perché l’Aggiornamento non è sempre un Processo Immediato
Il team di sicurezza di WordPress.org ha agito con la massima tempestività, rilasciando le versioni correttive blindate (6.9.5, 7.0.2 e 6.8.6) il 17 luglio 2026 e forzando l’attivazione degli aggiornamenti automatici in background per tutti i siti compatibili. Nonostante questo sforzo centralizzato, milioni di siti web rimangono scoperti. Questo ritardo nell’applicazione delle patch è dovuto a dinamiche operative ed esigenze aziendali complesse:
- Incompatibilità del Software e Regressioni: WordPress vive grazie a un ecosistema di oltre 60.000 plugin e temi. Un aggiornamento del core, seppur di sicurezza, può introdurre modifiche alle funzioni interne o alle API native. Nelle grandi architetture aziendali, aggiornare a scatola chiusa comporta il rischio concreto di causare malfunzionamenti nel sistema di pagamento, corrompere il layout grafico o interrompere l’invio di lead commerciali, bloccando l’operatività del business.
- Flussi di Lavoro e Finestre di Manutenzione Rigide: Le infrastrutture IT aziendali e governative operano secondo rigidi protocolli di Change Management. Ogni modifica al codice deve essere preventivamente approvata, testata in un ambiente di Stage (clonazione del sito in modalità privata), verificata dai team di Quality Assurance (QA) e infine distribuita in produzione solo all’interno di specifiche “finestre di manutenzione” (spesso notturne o durante i fine settimana), per minimizzare l’impatto sugli utenti finali.
- Disattivazione Intenzionale degli Aggiornamenti Automatici: Per evitare i blocchi improvvisi citati in precedenza, moltissimi amministratori di sistema e agenzie di sviluppo disabilitano esplicitamente gli aggiornamenti automatici di WordPress inserendo specifiche direttive nel file di configurazione
wp-config.php:phpdefine( 'WP_AUTO_UPDATE_CORE', false );Usa il codice con cautela.Questa configurazione, pensata per mantenere il controllo totale sul codice, si trasforma in una condanna a morte digitale se il team IT non reagisce entro poche ore dalla pubblicazione di una vulnerabilità di tipo zero-day o con exploit pubblico. - Siti “Orfani” o Legacy: Esiste una porzione immensa del Web composta da blog personali, siti aziendali di micro-imprese, landing page di vecchie campagne marketing o portali istituzionali non più monitorati attivamente da sviluppatori. Questi siti continuano a funzionare online senza alcuna supervisione, rappresentando i bersagli ideali per la creazione di reti di server zombie (botnet).
Strategie di Mitigazione Immediate e Soluzioni Temporanee (Workaround)
Se i tempi tecnici aziendali non consentono di effettuare l’aggiornamento immediato del core alle versioni patchate, gli amministratori di sistema e i responsabili della sicurezza informatica devono implementare misure di mitigazione alternative per interrompere la catena d’attacco prima che i bot completino l’exploit.
Opzione A: Configurazione del Web Application Firewall (WAF)
Il blocco perimetrale a livello di rete è la soluzione temporanea più efficace e sicura. Consente di respingere le richieste malevole prima ancora che tocchino l’applicazione WordPress. I principali fornitori di servizi di sicurezza CDN e WAF, come Cloudflare, Imperva o Akamai, hanno già implementato regole gestite per bloccare i payload specifici di wp2shell.
Se si gestisce un firewall proprietario o un WAF configurabile (es. ModSecurity su server Apache/Nginx), è tassativo impostare regole di sbarramento per bloccare l’accesso non autenticato alle seguenti rotte:
- La rotta URL standard:
/wp-json/batch/v1 - La rotta URL alternativa basata su parametri di query (query string):
?rest_route=/batch/v1
Nota bene: bloccare solo l’URL /wp-json/ lascia il server vulnerabile, poiché WordPress elabora nativamente anche la variante sintattica basata sulla query string ?rest_route=. Entrambe le espressioni devono essere inserite nelle blacklist del firewall.
Opzione B: Intervento sui file di configurazione del Web Server (Nginx / Apache)
Nel caso in cui non si disponga di un WAF commerciale, è possibile istruire direttamente il web server affinché risponda con un codice di errore 403 Forbidden a chiunque tenti di interrogare l’endpoint incriminato.
Per Server Nginx:
Inserire il seguente blocco all’interno del file di configurazione del blocco server {} (solitamente situato in /etc/nginx/sites-available/):
nginx
# Blocco di sicurezza temporaneo contro la vulnerabilità wp2shell (CVE-2026-63030)
if ($request_uri ~* "(/wp-json/batch/v1|\?rest_route=/batch/v1)") {
return 403;
}
Usa il codice con cautela.
Eseguire successivamente un test della sintassi e ricaricare il servizio:
bash
sudo nginx -t
sudo systemctl reload nginx
Usa il codice con cautela.
Per Server Apache (tramite file .htaccess):
Aggiungere queste direttive in cima al file .htaccess presente nella cartella radice (root) dell’installazione di WordPress:
apache
<IfModule mod_rewrite.c>
RewriteEngine On
# Verifica il percorso dell'URL o la presenza del parametro rest_route per il batch
RewriteCond %{REQUEST_URI} ^/wp-json/batch/v1 [NC,OR]
RewriteCond %{QUERY_STRING} rest_route=/batch/v1 [NC]
RewriteRule .* - [F,L]
</IfModule>
Usa il codice con cautela.
Opzione C: Disattivazione Completa della REST API per Utenti Anonimi
Se il sito web aziendale non fa uso di integrazioni esterne, applicazioni JavaScript disaccoppiate (Decoupled/Headless WordPress) o blocchi Gutenberg complessi che richiedono chiamate API continue da utenti non loggati, la soluzione più drastica ed efficiente consiste nel bloccare completamente l’accesso alla REST API per chiunque non abbia effettuato il login.
Questo risultato può essere ottenuto inserendo un frammento di codice (snippet) personalizzato all’interno del file functions.php del tema child attivo, oppure creando un mini-plugin ad hoc (soluzione consigliata per evitare che l’aggiornamento del tema sovrascriva la regola):
php
<?php
/**
* Plugin Name: Blocco REST API di Sicurezza (Anti-wp2shell)
* Description: Disabilita l'accesso non autenticato alla REST API per mitigare le CVE-2026-63030 e CVE-2026-60137.
*/
add_filter( 'rest_authentication_errors', function( $errors ) {
// Se c'è già un errore, mantienilo
if ( ! empty( $errors ) ) {
return $errors;
}
// Se l'utente non è autenticato, blocca l'accesso a tutta la REST API
if ( ! is_user_logged_in() ) {
return new WP_Error(
'rest_forbidden',
__( 'Accesso negato per motivi di sicurezza.', 'text-domain' ),
array( 'status' => 401 )
);
}
return $errors;
});
Usa il codice con cautela.
Guida di Risposta agli Incidenti: Cosa Fare se si Sospetta un Attacco
Se un sito web è rimasto esposto senza patch o protezioni WAF nei giorni successivi alla scoperta di wp2shell, c’è un’elevata probabilità che i sistemi automatizzati abbiano già tentato o portato a termine l’infiltrazione. In questi casi, limitarsi ad aggiornare WordPress non elimina la minaccia, poiché l’attaccante potrebbe aver già installato backdoor persistenti o creato account di amministrazione silenti. È necessario avviare immediatamente una procedura di Incident Response strutturata in 5 fasi.
Fase 1: Ispezione dei Log di Accesso (Log Analysis)
I file di log del server web (es. access.log di Nginx o Apache) sono la fonte primaria della verità. Occorre ricercare sistematicamente tutte le richieste HTTP indirizzate all’endpoint batch che hanno restituito un codice di stato 200 OK nel periodo critico.
È possibile eseguire una ricerca rapida tramite linea di comando (SSH) utilizzando il comando grep:
bash
grep -E "/wp-json/batch/v1|batch/v1" /var/log/nginx/access.log
Usa il codice con cautela.
Se si rilevano chiamate frequenti provenienti da indirizzi IP esteri (o nodi VPN/Tor) che mostrano richieste di tipo POST con risposte positive dal server, il sito è stato quasi certamente preso di mira ed esplorato.
Fase 2: Verifica dell’Integrità del Database
Accedere al database tramite strumenti come phpMyAdmin o la riga di comando MySQL ed effettuare una verifica accurata della tabella degli utenti:
sql
SELECT ID, user_login, user_email, user_registered FROM wp_users;
Usa il codice con cautela.
Verificare se sono comparsi account amministratori sconosciuti o email sospette create di recente. Successivamente, controllare la tabella wp_usermeta per accertarsi che nessun utente standard abbia ricevuto modifiche ai propri privilegi (meta_value associato alle capacità di administrator).
Fase 3: Scansione dei File e Ricerca di Web Shell
Le web shell vengono spesso nascoste all’interno della directory dei caricamenti multimediali (/wp-content/uploads/) o mimetizzate tra i file nativi del core o dei temi (es. rinominate come wp-creds.php, index-backup.php o annidate all’interno di file legittimi tramite funzioni di offuscamento come eval(base64_decode(...))).
Strumenti utili per l’ispezione automatica dei file includono:
- WP-CLI: L’interfaccia a riga di comando ufficiale di WordPress consente di verificare l’integrità dei file nativi del core confrontando i checksum MD5 con i server ufficiali di WordPress:bash
wp core verify-checksumsUsa il codice con cautela.Se il comando segnala file modificati o estranei nelle cartellewp-adminowp-includes, il sistema è compromesso. - Scanner di Sicurezza Applicativi: L’installazione di soluzioni di sicurezza interne rinomate come Wordfence Security o i servizi di monitoraggio di Sucuri permette di effettuare scansioni approfondite alla ricerca di firme malware note e porzioni di codice PHP malevole inserite nei file di sistema.
Fase 4: Bonifica Generale delle Credenziali e dei Token
Se i controlli confermano o fanno sospettare un’intrusione avvenuta con successo, è imperativo procedere all’azzeramento totale dello stato di sicurezza del sito:
- Forzare il cambio password di tutti gli utenti amministrativi esistenti, imponendo l’uso di stringhe alfanumeriche complesse (superiori a 16 caratteri) generate tramite password manager.
- Rigenerare le chiavi di autenticazione e i “Salt” all’interno del file
wp-config.php. Questa operazione invalida istantaneamente tutti i cookie di sessione attivi, disconnettendo forzatamente chiunque sia collegato al sito (inclusi eventuali hacker silenti). I nuovi codici di sicurezza casuali possono essere generati direttamente tramite il generatore ufficiale di chiavi di WordPress.org.phpdefine('AUTH_KEY', 'INSERIRE_STRINGA_CASUALE_E_COMPLESSA'); define('SECURE_AUTH_KEY', 'INSERIRE_STRINGA_CASUALE_E_COMPLESSA'); define('LOGGED_IN_KEY', 'INSERIRE_STRINGA_CASUALE_E_COMPLESSA'); define('NONCE_KEY', 'INSERIRE_STRINGA_CASUALE_E_COMPLESSA'); define('AUTH_SALT', 'INSERIRE_STRINGA_CASUALE_E_COMPLESSA'); define('SECURE_AUTH_SALT', 'INSERIRE_STRINGA_CASUALE_E_COMPLESSA'); define('LOGGED_IN_SALT', 'INSERIRE_STRINGA_CASUALE_E_COMPLESSA'); define('NONCE_SALT', 'INSERIRE_STRINGA_CASUALE_E_COMPLESSA');Usa il codice con cautela.
Fase 5: Ripristino da un Backup Sicuro (Bare-Metal Restore)
Nei casi di infezione profonda e persistente, dove non si ha l’assoluta certezza di aver rimosso ogni singola backdoor o script iniettato, la pratica standard di sicurezza prevede la cancellazione totale dell’istanza web e il ripristino di un backup completo (file e database) risalente a una data antecedente al 17 luglio 2026 (giorno del rilascio pubblico della vulnerabilità). Subito dopo il ripristino del backup storico, e prima di riaprire il traffico pubblico sul sito, è obbligatorio applicare immediatamente la patch ufficiale o le regole del WAF.
Il Futuro della Sicurezza nei CMS: Le Lezioni Imparate
La crisi generata da wp2shell solleva interrogativi cruciali sulla sostenibilità dei modelli di sviluppo software a lungo termine per le piattaforme che sorreggono oltre il 40% dell’intero web mondiale. Quando una vulnerabilità RCE colpisce il nucleo centrale di un software così diffuso, l’effetto domino sull’economia digitale è immediato e tangibile.
L’importanza degli Ambienti di Staging Automatizzati
La scusa comune secondo cui “non possiamo aggiornare per paura di rompere il sito” non è più accettabile nel moderno panorama delle minacce informatiche. Le aziende devono dotarsi di infrastrutture di sviluppo moderne, basate su pipeline di Continuous Integration / Continuous Deployment (CI/CD). L’adozione di strumenti in grado di clonare automaticamente il sito di produzione in un ambiente di Stage isolato, applicare la patch di sicurezza del core, eseguire test di navigazione automatizzati (Headless Browser Testing) e rilasciare l’aggiornamento in produzione in pochi minuti è l’unico modo sicuro per ridurre a zero la finestra di vulnerabilità di un’applicazione web.
Verso un Architettura Minimum Viable API
Questa vicenda dimostra anche come la progressiva introduzione di funzionalità avanzate all’interno del core di WordPress (come la REST API nativa o il sistema batch), sebbene utile per la modernizzazione tecnologica del CMS, aumenti in modo esponenziale la cosiddetta superficie di attacco (attack surface). Gli sviluppatori del core dovranno ripensare i meccanismi di inclusione dei moduli nativi, valutando la possibilità di rendere disattivabili di default o modulari tutte quelle componenti avanzate che non sono strettamente indispensabili al funzionamento base di un sito web editoriale.
Per concludere
La minaccia rappresentata da wp2shell (CVE-2026-63030) costituisce un severo richiamo all’ordine per l’intera comunità digitale. Gestire un sito web aziendale o istituzionale non può più essere considerata un’attività passiva di puro inserimento di contenuti. La sicurezza deve diventare parte integrante della cultura aziendale, richiedendo investimenti costanti in monitoraggio proattivo, firewall aggiornati, backup ridondati e, soprattutto, una reattività immediata di fronte al rilascio delle patch correttive del software.
Aggiornare tempestivamente i propri sistemi oggi non è semplicemente una buona pratica tecnica, ma rappresenta l’unica barriera efficace a tutela della reputazione aziendale, dei dati dei propri utenti e della continuità del proprio business sul mercato globale.
Francesco Meduri
