Nell’estate del 2026 il mondo WordPress ha vissuto uno dei momenti più delicati degli ultimi anni. Una vulnerabilità critica soprannominata wp2shell ha esposto centinaia di milioni di siti al rischio di controllo totale da parte di aggressori, senza bisogno di alcuna password. Non si tratta del solito plugin scritto male: il problema risiede nel cuore stesso di WordPress, il core, ed è per questo che merita attenzione anche da parte di chi ha sempre tenuto il proprio sito ordinato e aggiornato.
Chi gestisce un sito professionale sa che, in casi come questo, aggiornare non basta. Se l’attacco è già avvenuto, il core corretto convive con le porte sul retro lasciate aperte dagli aggressori. Vale quindi la pena capire con calma cosa sia successo, come riconoscere un sito già compromesso e quali passaggi seguire per riportarlo in uno stato realmente pulito e sicuro.
Cos’è wp2shell e perché va presa sul serio
wp2shell non è un singolo difetto, ma una catena di due vulnerabilità che, combinate, permettono a un utente anonimo di eseguire codice arbitrario sul server. Il primo anello è un errore di gestione delle richieste nell’endpoint REST batch (/wp-json/batch/v1), un’interfaccia attiva di default che consente di inviare più richieste in un’unica chiamata. Un difetto nella validazione permette di far passare una richiesta ad alto privilegio mascherandola dietro una a basso privilegio, aggirando i controlli di autorizzazione. Il secondo anello è una SQL injection nel parametro con cui WordPress esclude determinati autori dalle query: passando un valore di tipo stringa anziché numerico, l’attaccante riesce a iniettare codice SQL.
Presi singolarmente, questi due problemi avrebbero un impatto contenuto. Concatenati, trasformano una semplice richiesta HTTP anonima nel risultato più grave che un’applicazione web possa concedere: l’esecuzione di codice remoto. La particolarità che rende wp2shell così pericolosa è l’assenza di prerequisiti. Non serve un account da rubare, non serve un plugin vulnerabile da individuare, non serve una configurazione errata da sfruttare: è sufficiente che il sito esponga l’API REST, cosa che vale per la quasi totalità delle installazioni.
La vulnerabilità è stata divulgata pubblicamente il 17 luglio 2026 e nel giro di pochi giorni sono comparsi sia le analisi tecniche complete sia un proof-of-concept funzionante. Da quel momento gli attacchi automatizzati si sono diffusi rapidamente, il che spiega perché tanti amministratori si siano ritrovati il sito trasformato in una pagina bianca o pieno di file sospetti.
Le versioni coinvolte (e quelle già al sicuro)
La catena completa colpisce le versioni da 6.9.0 a 6.9.4 e da 7.0.0 a 7.0.1. Le installazioni sul ramo 6.8.x sono esposte soltanto alla componente di SQL injection, non all’intera catena. Le versioni che risolvono il problema sono la 6.9.5 e la 7.0.2, affiancate dalla 6.8.6 per chi è rimasto sul ramo precedente.
Data l’eccezionale gravità, il team di WordPress ha compiuto un passo insolito: ha forzato l’aggiornamento automatico su tutti i siti vulnerabili, invece di attendere l’intervento manuale degli amministratori. Questo ha protetto moltissimi siti, ma ha generato anche un pericoloso senso di sicurezza. Ed è qui che si nasconde l’insidia più grande: se l’aggiornamento è arrivato dopo che l’attacco era già andato a segno, il sito risulta aggiornato ma compromesso. Il core patchato chiude la porta d’ingresso, ma non rimuove le backdoor, gli utenti fasulli e i file dannosi che l’aggressore ha già lasciato dietro di sé.
Come capire se il tuo sito è stato compromesso
Il primo controllo è il più semplice: aprire la sezione Utenti del pannello di amministrazione e verificare la presenza di account sconosciuti, soprattutto con privilegi di amministratore. Un profilo che nessuno ricorda di aver creato è uno degli indizi più diretti di una violazione avvenuta.
Il secondo controllo riguarda i plugin, inclusi i cosiddetti must-use plugin. Gli aggressori amano nascondere una backdoor persistente in wp-content/mu-plugins/, spesso travestita da innocua patch di sicurezza, perché questa cartella viene caricata automaticamente e non compare nell’elenco tradizionale dei plugin. Vale la pena ispezionarla file per file, insieme alla cartella plugins/ standard, alla ricerca di elementi mai installati.
Sul file system compaiono altri segnali ricorrenti. Nelle cartelle di cache (wp-content/cache/ e simili) possono materializzarsi file PHP dal nome alfanumerico privo di senso: sono web shell, ossia pannelli che consentono all’attaccante di impartire comandi. Anche i file della directory principale, come index.php o wp-load.php, possono risultare modificati, con codice offuscato aggiunto in coda e, talvolta, impostati in sola lettura per impedire che gli aggiornamenti li sovrascrivano. Alcuni amministratori hanno riportato la comparsa di sottocartelle annidate contenenti finti file immagine che in realtà nascondono binari dannosi, oltre a chiamate in uscita verso domini dall’aspetto casuale.
Chi vuole una prima verifica rapida può usare il checker ufficiale pubblicato dai ricercatori di Searchlight Cyber, che stabilisce se l’endpoint batch è ancora vulnerabile. È però bene ricordarne il limite: quello strumento indica se il sito è tuttora esposto, non se è già stato violato. L’assenza di segnali evidenti non è mai una prova definitiva di innocenza: un attaccante accorto può aver ripulito le proprie tracce.
Come ripulire un sito WordPress infetto
Prima di toccare qualsiasi cosa, la regola vale sempre: eseguire un backup completo di file e database. Non perché quel backup sia pulito — quasi certamente non lo è — ma perché serve come rete di sicurezza e come materiale di analisi in caso di errore durante la bonifica.
Il primo intervento è sul file system, via FTP o SSH. Si eliminano le web shell dalle cartelle di cache, si rimuovono i plugin fasulli dalle directory mu-plugins/ e plugins/ e si ripristinano i file del core che risultano alterati. Per questi ultimi, il metodo più affidabile è sostituirli con quelli di una copia integra della stessa versione di WordPress scaricata dal sito ufficiale, così da avere la certezza di non lasciarsi sfuggire codice iniettato.
Segue l’aggiornamento del core alla versione corretta — 6.9.5 oppure 7.0.2 — verificando che sia stato realmente applicato: gli aggiornamenti automatici possono infatti bloccarsi in silenzio a causa di problemi di permessi o di spazio su disco.
A questo punto si passa alla parte più trascurata e più importante: utenti, password e sessioni. Chi ha avuto accesso al database ha con ogni probabilità ottenuto gli hash delle credenziali o è entrato direttamente come amministratore. Vanno quindi reimpostate tutte le password, con priorità agli account amministrativi, e va cambiata anche la password dell’utente MySQL, aggiornandola nel file wp-config.php. Per sfrattare eventuali aggressori ancora connessi, si rigenerano le chiavi di sicurezza (i cosiddetti salt) tramite il generatore ufficiale di WordPress, sovrascrivendo quelle presenti in wp-config.php: l’operazione invalida ogni sessione attiva e disconnette tutti i dispositivi.
Resta infine la pulizia del database. Diversi amministratori hanno segnalato la presenza di record artefatti — voci di menu di navigazione e changeset di personalizzazione fasulli — usati per aggirare i filtri di sicurezza durante l’attacco, spesso riconoscibili da una data fissa e da riferimenti a domini fittizi. È opportuno trattare questi indicatori come segnali osservati sul campo e non come una firma ufficiale e universale: prima di cancellare, conviene ispezionare a mano le tabelle wp_posts e wp_postmeta per capire cosa sia effettivamente estraneo, adattando ogni query al prefisso reale del proprio database. Se la manipolazione diretta di SQL non fa parte delle proprie competenze, la strada più sicura resta un’altra: ripartire da un backup precedente alla data della violazione e riapplicare solo le modifiche legittime.
Rafforzare la sicurezza per il futuro
Una volta ripulito il sito, l’obiettivo diventa impedire che una vicenda simile si ripeta. Alcune misure hanno un rapporto costo-beneficio particolarmente favorevole.
La prima è chiudere la superficie d’attacco specifica: finché non si è certi che tutto sia aggiornato, si può bloccare l’accesso anonimo all’endpoint batch a livello di firewall applicativo o web server, avendo cura di coprire entrambe le forme con cui risponde, /wp-json/batch/v1 e /?rest_route=/batch/v1. In alternativa, esistono plugin che richiedono un utente autenticato per le richieste batch.
La seconda misura riguarda i permessi del database. WordPress, per il suo normale funzionamento, non ha bisogno del privilegio FILE, quello che consente di scrivere file su disco a partire da una query. Revocarlo all’utente del database toglie all’attaccante uno degli strumenti chiave usati proprio in wp2shell per depositare web shell sul server.
Sul fronte del pannello di amministrazione, disabilitare la modifica e l’installazione dei file direttamente dall’interfaccia riduce sensibilmente i danni che una backdoor può causare. È sufficiente aggiungere al file wp-config.php le direttive che disattivano l’editor integrato e le modifiche ai plugin. Il piccolo prezzo da pagare è che gli aggiornamenti andranno gestiti in modo controllato, ma è un compromesso quasi sempre conveniente per un sito professionale.
Restano infine le buone pratiche di sempre, che questa vicenda rende ancora più concrete: mantenere attivi gli aggiornamenti automatici, applicare il principio del privilegio minimo agli account, e dotarsi di un sistema di monitoraggio che permetta di accorgersi di un’anomalia mentre accade, e non settimane dopo. Molti dei siti colpiti più duramente avevano in comune proprio l’assenza totale di visibilità su ciò che vi succedeva.
Una riflessione finale
wp2shell ricorda una verità scomoda: la sicurezza di un sito non è uno stato che si raggiunge una volta per tutte, ma una manutenzione continua fatta di aggiornamenti tempestivi, controlli periodici e privilegi calibrati con attenzione. È proprio in questa costanza che la maggior parte dei siti si scopre fragile — non per mancanza di competenza tecnica, ma perché nessuno ha il tempo di presidiare ogni giorno ciò che accade dietro le quinte.
È esattamente il compito di cui ci occupiamo con il nostro servizio di manutenzione siti web: aggiornamenti gestiti in modo controllato, monitoraggio continuo, backup verificati e interventi rapidi quando emerge un’anomalia. Così una vulnerabilità critica come wp2shell viene chiusa prima di trasformarsi in un danno, e non scoperta settimane dopo, a compromissione ormai avvenuta.
La vera domanda, allora, non è soltanto se il tuo sito è aggiornato oggi, ma quanto tempo passerebbe prima che tu ti accorga se qualcosa, domani, andasse storto.
