La catena di exploit “wp2shell” rappresenta un evento di sicurezza critico che prende di mira l’architettura fondamentale dell’ecosistema WordPress. Si tratta di una vulnerabilità di esecuzione di codice remoto (RCE) pre-autenticazione che risiede interamente all’interno del core di WordPress. Per essere sfruttata non richiede plugin o temi di terze parti, né un accesso autenticato. Una singola richiesta HTTP appositamente costruita, diretta contro un’installazione predefinita “di serie”, può consentire a un aggressore non autenticato di ottenere il controllo completo del sistema.

La gravità di questa minaccia è evidenziata dal punteggio CVSS pari a 9,8. La CISA ha aggiunto entrambi i CVE al proprio catalogo delle vulnerabilità note sfruttate (KEV) dopo che, poco dopo la divulgazione, sono state osservate attività di sfruttamento. I dati indicano che circa il 60% delle organizzazioni che utilizzano WordPress era inizialmente vulnerabile al momento della divulgazione, con una parte significativa che esponeva questi server direttamente a Internet.

Uno sfruttamento riuscito può consentire la compromissione completa del database, l’accesso persistente al server web tramite webshell offuscate e la creazione non autorizzata di account amministrativi.

Panoramica della vulnerabilità

La catena di exploit wp2shell combina diverse vulnerabilità del core di WordPress per ottenere un'escalation di privilegi senza autenticazione. L'attacco sfrutta innanzitutto una falla nell'elaborazione delle richieste batch dell'API REST per aggirare la convalida delle richieste e i controlli di autorizzazione. Questo accesso viene poi utilizzato per sfruttare una vulnerabilità di tipo SQL injection nella gestione del parametro author_exclude da parte di WP_Query.

Utilizzando la tecnica di iniezione SQL, un aggressore può manipolare gli oggetti WordPress memorizzati nella cache e sfruttare il meccanismo di caching di oEmbed per reinserire dati dannosi nel database. L’exploit sfrutta quindi la funzionalità dei changeset di Customizer per ereditare temporaneamente i permessi di un account amministratore, creando infine un utente amministrativo persistente.

In sintesi, l’attacco si sviluppa in quattro fasi:

1. Bypass della convalida dell’API REST tramite desincronizzazione delle richieste in batch.
2. Iniezione SQL dovuta a una sanificazione impropria dei parametri.
3. Avvelenamento della cache degli oggetti e manipolazione del database tramite il comportamento di write-back di oEmbed.
4. Elevazione dei privilegi e persistenza tramite la creazione di un account amministratore.

Se combinate tra loro, queste vulnerabilità possono consentire a un aggressore non autenticato di ottenere il pieno controllo amministrativo di un'installazione WordPress vulnerabile.

In questo exploit vengono sfruttate le seguenti vulnerabilità del core di WordPress:

• CVE-2026-63030 (Confusione dei percorsi batch dell’API REST): Un errore logico nella funzione WP_REST_Server::serve_batch_request_v1(), in cui la mancata gestione degli oggettiWP_Error provoca una desincronizzazione tra gli array interni di gestione delle richieste, consentendo a richieste non convalidate di ereditare i permessi di gestori innocui.
• CVE-2026-60137 (Iniezione SQL in WP_Query): Una vulnerabilità di tipo “type-juggling” nel motore WP_Query. Quando determinati parametri ricevono una stringa non elaborata anziché l’array previsto, la sanificazione dei valori interi viene aggirata, portando all’interpolazione della stringa non elaborata nelle clausoleWHERE delle query SQL .

Versioni interessate e versioni corrette

Valutazione strategica: Rischi di WordPress

Storicamente, la sicurezza di WordPress si è concentrata sul «perimetro dei plugin». Questo attacco dimostra che rischi significativi per la sicurezza possono avere origine all’interno del core di WordPress e non esclusivamente attraverso estensioni di terze parti. Le organizzazioni dovrebbero assicurarsi che le istanze di WordPress siano integrate in programmi formali di gestione delle vulnerabilità e delle patch.

Da un punto di vista difensivo, WordPress dovrebbe essere considerato un obiettivo di alto valore. La sua diffusione capillare negli ambienti connessi a Internet lo rende una piattaforma allettante per gli autori delle minacce, aumentando la probabilità di ricerche sulle vulnerabilità, scansioni automatizzate e tentativi di sfruttamento.

Pilastri della governance strategica

• Mappatura della superficie di attacco: effettuare un inventario continuo di tutte le risorse WordPress. La maggior parte delle violazioni si verifica su istanze di staging dimenticate e prive di patch.
• Convalida continua: non affidarsi allo stato "aggiornamento automatico". Implementare il controllo automatico delle versioni per garantire che le patch siano effettivamente attive.
• Fidarsi ma verificare: sebbene WordPress.org consenta gli aggiornamenti forzati, gli amministratori devono verificare il completamento su ogni configurazione dell’host.
• Rotazione delle credenziali e dei salt: in caso di sospetta vulnerabilità del Core, la rotazione dei salt del database nel file wp-config.php è una misura difensiva strategica obbligatoria per invalidare le sessioni esistenti.

Ricerca delle minacce e indicatori di compromissione (IoC)

Segnali di rete

• HTTP 207 Multi-Status: si tratta di un segnale altamente attendibile che indica tentativi di sfruttamento riusciti tramite l’API batch.
• Consapevolezza del bypass delWAF: gli aggressori potrebbero utilizzare sequenze di escape %2F nel parametro ?rest_route= per aggirare il semplice confronto delle stringhe. I WAF devono essere configurati per eseguire la decodifica dell’URL prima del confronto.
• User-Agent: monitorare la presenza di wp2shell, rezwp2shell o cve-2026-63030/1.0.

Elementi basati sull’host

• Indicatori di file: cercare " temp-write-test- " nella directory wp-content/, utilizzata dai kit di exploit per verificare i permessi di scrittura.
• Plugin dannosi: cercare directory che utilizzano un suffisso esadecimale, come ad esempio wp-content/plugins/wp2shell_/.
• Distinzione relativa a CMSmap: i team forensi devono distinguere tra lo strumento legittimo CMSmap da 11 KB e la piattaforma offuscata da 150 KB osservata nelle campagne attuali.

IOC noti

Misure di mitigazione e di bonifica

Le organizzazioni devono aggiornareimmediatamente il core di WordPress alle versioni 7.0.2, 6.9.5 o 6.8.6. Sebbene WordPress.org abbia imposto aggiornamenti automatici, gli amministratori devono "fidarsi ma verificare" queste installazioni, poiché il completamento dell'aggiornamento automatico non è garantito su tutte le configurazioni di hosting. È necessario dare priorità alle istanze sui rami 6.9.x e 7.0.x, che sono vulnerabili alla catena completa di RCE.

Misure di mitigazione temporanee

Laddove non sia possibile applicare immediatamente le patch, gli amministratori dovrebbero implementare regole WAF per bloccare l’accesso non autenticato agli endpoint batch dell’API REST interessati. La decodifica degli URL dovrebbe essere eseguita prima della corrispondenza delle regole per rilevare le richieste codificate.

Endpoint bloccati:

• /wp-json/batch/v1
• ?rest_route=/batch/v1 (comprese le varianti con codifica URL come %2Fbatch%2Fv1)

Azioni successive alla compromissione

Se vi sono motivi per ritenere che si sia verificato uno sfruttamento, si raccomandano le seguenti azioni:

• Verifica dell’integrità dei file del core: eseguire il comando `wp core verify-checksums` per identificare eventuali file del core di WordPress modificati o non autorizzati.
• Aggiornare le credenziali: reimpostare le credenziali del database e rigenerare i salt di autenticazione e le chiavi di sicurezza all'interno del file wp-config.php.
• Esaminare gli account utente: controllare la tabella `wp_users` alla ricerca di account non autorizzati, in particolare quelli che utilizzano la convenzione di denominazione `w2s_`.
• Ricerca degli IOC: cercare nei log del server web, nei file system e negli strumenti di monitoraggio della sicurezza gli indicatori di compromissione (IOC) elencati nella presente nota informativa.

Se siete preoccupati per una qualsiasi delle minacce descritte in questo bollettino o avete bisogno di aiuto per determinare quali misure adottare per proteggervi dalle minacce più rilevanti che la vostra organizzazione deve affrontare, contattate il vostro account manager o, in alternativa, mettetevi in contatto con noi per scoprire come proteggere la vostra organizzazione.