Negli ultimi giorni la comunità della sicurezza informatica ha acceso i riflettori su una minaccia che non riguarda un plugin di terze parti o un tema poco aggiornato, ma il cuore stesso di WordPress. Due vulnerabilità presenti nel core del CMS più utilizzato al mondo, se combinate tra loro, permettono a un attaccante non autenticato di ottenere il controllo completo di un sito web, fino alla creazione di un account amministratore e all'esecuzione di codice sul server. La catena di attacco è stata soprannominata dalla comunità di sicurezza wp2shell, ed è già osservata in exploitation attiva su scala globale.

Se gestisci un sito aziendale, un blog o un e-commerce basato su WordPress, questo articolo ti spiega cosa sta succedendo, quali versioni sono a rischio, quali sono i segnali di un sito WordPress hackerato e, soprattutto, come ripristinare un sito WordPress hackerato in modo sicuro e definitivo, evitando che l'attacco si ripeta.

Cos'è wp2shell: la catena di vulnerabilità che ha scosso l'ecosistema WordPress

wp2shell non è una singola falla, ma la combinazione di due vulnerabilità distinte scoperte nel core di WordPress. Prese singolarmente hanno una gravità diversa, ma unite in sequenza consentono a un utente malintenzionato remoto e non autenticato di prendere il pieno controllo di un'installazione vulnerabile, senza bisogno di credenziali, senza dover indurre un amministratore a cliccare su un link e senza che sia coinvolto alcun plugin o tema di terze parti. È sufficiente che il sito sia pubblicamente raggiungibile su internet e non sia stato aggiornato.

Le due vulnerabilità sono state ufficialmente identificate come CVE-2026-60137 e CVE-2026-63030. Diverse società di sicurezza, tra cui Patchstack, Wordfence, Wiz.io e WatchTowr, hanno confermato che gli attacchi sono partiti nelle stesse ore in cui sono state rilasciate le patch, segno che gli aggressori avevano già pronte le tecniche di exploitation ancora prima della divulgazione pubblica dei dettagli tecnici. Anche organismi governativi come il BSI tedesco, tramite la notifica WID-SEC-2026-2409, e la statunitense CISA hanno emesso avvisi ufficiali, classificando la combinazione delle due falle come critica con un punteggio CVSS complessivo di 9.8 su 10.

Le due vulnerabilità in dettaglio

Per capire perché wp2shell è considerata una delle emergenze di sicurezza più serie degli ultimi anni per WordPress, è utile guardare alle due vulnerabilità separatamente.

La prima, CVE-2026-60137, è una vulnerabilità di SQL injection non autenticata che coinvolge il parametro author__not_in della classe WP_Query. Il punteggio di base CVSS assegnato dalla community di WordPress e da CISA è 5.9. Le versioni interessate da questa falla vanno da WordPress 6.8.0 fino alla 6.8.5, dalla 6.9.0 alla 6.9.4 e dalla 7.0.0 alla 7.0.1.

La seconda, CVE-2026-63030, è una vulnerabilità di route confusion nelle richieste batch della REST API, che consente l'esecuzione di codice remoto (RCE). Questa è la componente più pericolosa della catena, con un punteggio CVSS di 9.8, sia secondo la community di WordPress sia secondo CISA. Le versioni coinvolte sono la 6.9.0-6.9.4, la 7.0.0-7.0.1 e persino la versione beta 7.1 Beta 1.

Il meccanismo tecnico, descritto nel dettaglio dal ricercatore che ha scoperto la falla, mostra come i percorsi di validazione e di esecuzione dell'API batch potessero essere desincronizzati, permettendo a parametri controllati dall'attaccante di raggiungere una route che normalmente li avrebbe sanitizzati. Da lì, la SQL injection viene innestata in una catena più ampia che coinvolge la cache dei post, le righe di cache oEmbed, i changeset e gli action hook di WordPress. Il risultato finale è la possibilità di creare un account amministratore e, tramite le normali funzionalità di amministrazione come il caricamento di un plugin, eseguire codice arbitrario con i privilegi del web server.

Quali versioni di WordPress sono a rischio

Le versioni affette dalla combinazione completa delle due vulnerabilità (e quindi dal rischio di esecuzione di codice remoto) sono WordPress 6.9.0-6.9.4 e 7.0.0-7.0.1. La versione 6.8.x è interessata soltanto dalla vulnerabilità di SQL injection e non è esposta alla catena RCE completa, ma va comunque aggiornata con priorità.

WordPress ha rilasciato tempestivamente delle versioni corrette. WordPress 7.0.2 risolve entrambe le vulnerabilità CVE-2026-60137 e CVE-2026-63030. WordPress 7.1 Beta 2 corregge anch'essa entrambe le falle. WordPress 6.9.5 chiude completamente la catena di attacco. WordPress 6.8.6, infine, corregge solo la vulnerabilità di SQL injection, essendo l'unica presente in quel ramo.

Per molte installazioni, il team di sicurezza di WordPress ha attivato anche un aggiornamento automatico forzato, una misura eccezionale riservata solo alle minacce più gravi, segno di quanto sia stata considerata seria la situazione.

Cronologia dell'attacco: dalla scoperta all'exploitation di massa

Il 17 luglio 2026 il team di sicurezza di WordPress ha rilasciato le versioni corrette 6.8.6, 6.9.5 e 7.0.2, comunicando che l'aggiornamento risolveva un problema classificato come critico e uno come alto. Lo stesso giorno, i principali fornitori di soluzioni di sicurezza per WordPress hanno rilasciato regole firewall dedicate per i propri clienti a copertura della minaccia.

Poche ore dopo il rilascio delle patch, già nella tarda serata del 17 luglio, sono stati osservati i primi tentativi di probing contro l'endpoint REST API coinvolto nella vulnerabilità, seguiti a distanza di pochi minuti dai primi tentativi concreti di SQL injection attraverso lo stesso endpoint. Nei giorni successivi, tra il 18 e il 20 luglio, diversi ricercatori indipendenti hanno pubblicato analisi tecniche dettagliate della catena di attacco e sono comparsi online i primi exploit proof-of-concept funzionanti, rendendo la minaccia accessibile anche ad attaccanti meno sofisticati. Da quel momento il numero di scansioni e tentativi di attacco contro installazioni WordPress esposte su internet è cresciuto rapidamente.

Questa rapidità nello sfruttamento è ciò che rende wp2shell particolarmente insidiosa: la finestra temporale tra la pubblicazione della patch e l'inizio degli attacchi di massa è stata di poche ore, molto più breve di quanto siamo abituati a vedere per altre vulnerabilità del core.

Perché questa vulnerabilità è così pericolosa

Ci sono alcuni elementi che rendono wp2shell un caso limite rispetto alle vulnerabilità WordPress che si vedono normalmente. Il primo è che riguarda il core stesso del CMS, non un plugin: si stima che WordPress alimenti una quota enorme di tutti i siti web esistenti, il che significa che il numero di installazioni potenzialmente esposte è altissimo. Il secondo è che l'attacco non richiede autenticazione: basta che il sito sia online e non aggiornato. Il terzo è la disponibilità pubblica di exploit proof-of-concept, che abbassa drasticamente la barriera tecnica necessaria per sfruttare la falla. Il quarto, forse il più critico dal punto di vista del danno potenziale, è che l'esito dell'attacco può essere il pieno controllo amministrativo del sito, con la possibilità di installare ulteriori malware, backdoor, o utilizzare il server compromesso come base per altri attacchi.

Per le aziende soggette a normative come NIS2 o DORA, la questione ha anche un risvolto di compliance: chi rientra in questi perimetri normativi ha l'obbligo di segnalare e intervenire immediatamente quando vengono identificate vulnerabilità critiche nei propri sistemi, incluse quelle presenti nei CMS utilizzati per siti istituzionali o di e-commerce.

Come riconoscere un sito WordPress hackerato

Non sempre un attacco riuscito si manifesta con segnali evidenti nell'immediato. Anzi, spesso chi sfrutta una vulnerabilità come wp2shell preferisce restare nascosto il più possibile per mantenere l'accesso più a lungo. Ci sono comunque alcuni indizi tipici a cui prestare attenzione se si sospetta un sito WordPress hackerato.

Un primo segnale è la presenza di account amministratore che non riconosci nella sezione utenti, magari creati con nomi generici o con indirizzi email sospetti. Un secondo indizio riguarda plugin o temi che non hai installato tu, oppure file modificati di recente in cartelle come wp-content senza che tu abbia effettuato alcun aggiornamento. Un terzo segnale sono i reindirizzamenti inattesi dei visitatori verso siti esterni, spesso di spam o contenuti fraudolenti, oppure la comparsa di popup e annunci mai configurati. Anche un peggioramento improvviso delle performance del sito, un aumento anomalo del traffico in uscita o richieste verso indirizzi IP sconosciuti nei log del server possono indicare la presenza di uno script malevolo in esecuzione. Infine, se Google Search Console segnala contenuti dannosi o il tuo hosting provider ti comunica un'attività sospetta e sospende temporaneamente l'account, è molto probabile che il sito sia stato compromesso.

Se riconosci uno o più di questi segnali sul tuo sito, il consiglio è di non aspettare: ogni ora di ritardo aumenta il rischio che l'attaccante consolidi ulteriormente il proprio accesso o utilizzi il sito per colpire altri obiettivi.

Cosa fare subito se il tuo sito è stato compromesso

Nel momento in cui si sospetta o si conferma una compromissione, la prima cosa da fare è isolare il problema. Metti il sito in modalità di manutenzione o, se possibile, rendilo temporaneamente non accessibile dall'esterno per evitare che l'attaccante continui a operare mentre stai intervenendo. Cambia immediatamente tutte le password: quella dell'amministratore WordPress, quella del database, quella dell'hosting e quella dell'accesso FTP/SFTP, perché in molti casi le credenziali compromesse vengono riutilizzate su più livelli.

Aggiorna subito il core di WordPress alla versione patchata più recente, sia essa la 6.8.6, la 6.9.5 o la 7.0.2, verificando che l'aggiornamento automatico o forzato sia effettivamente andato a buon fine. Controlla poi con attenzione la lista degli utenti amministratori, rimuovendo qualsiasi account non riconosciuto, e rivedi l'elenco dei plugin installati, disattivando ed eliminando quelli che non hai autorizzato personalmente.

Come ripristinare un sito WordPress hackerato: la guida passo dopo passo

Ripristinare un sito WordPress hackerato non significa semplicemente rimuovere qualche file sospetto: significa ricostruire la sicurezza dell'intera installazione partendo da una base pulita e verificata. Il primo passo, quando possibile, è ripristinare il sito da un backup precedente alla compromissione, purché sia certo che quel backup non contenga già il malware. Questo è il motivo per cui avere un sistema di backup automatico, frequente e verificato è fondamentale: senza un punto di ripristino affidabile, il recupero diventa molto più lungo, costoso e incerto.

Se non è disponibile un backup sicuro, occorre procedere con una pulizia manuale approfondita: scansione di tutti i file del sito con strumenti antimalware specifici per WordPress, confronto dei file del core con una copia originale e pulita della stessa versione di WordPress, verifica di ogni singolo plugin e tema installato, controllo delle tabelle del database alla ricerca di codice iniettato in articoli, widget o opzioni, e revisione dei file di configurazione come wp-config.php e .htaccess, spesso target privilegiati per l'inserimento di backdoor persistenti.

Una volta completata la pulizia, è essenziale reinstallare da zero il core di WordPress nella versione patchata, rigenerare tutte le chiavi segrete presenti in wp-config.php, e verificare che non restino script pianificati sospetti che potrebbero reintrodurre il malware dopo la pulizia. Solo a questo punto il sito può essere rimesso online, monitorandolo attentamente nei giorni successivi per verificare che non ci siano segnali di una nuova compromissione.

Va detto con onestà che questo tipo di intervento richiede competenze tecniche specifiche di sicurezza WordPress, tempo e strumenti professionali. Un errore durante la fase di pulizia, come lasciare attiva anche una sola backdoor, può vanificare tutto il lavoro e portare a una nuova compromissione nel giro di poche settimane. Per questo motivo, in situazioni come quella generata da wp2shell, molte aziende scelgono di affidarsi a un servizio professionale di manutenzione WordPress in grado di gestire aggiornamenti, sicurezza e monitoraggio continuo, riducendo drasticamente il rischio di dover ripetere daccapo l'intero processo di ripristino.

Il ruolo del backup e del disaster recovery in scenari come wp2shell

L'episodio wp2shell dimostra in modo evidente perché il backup da solo, per quanto necessario, non basta più a garantire la continuità di un sito web. Un vero piano di disaster recovery per WordPress prevede backup automatici e ridondanti su più location, test periodici di ripristino per verificare che i backup siano effettivamente utilizzabili, procedure documentate e tempificate per il ripristino rapido in caso di incidente, e un piano di risposta agli incidenti che stabilisca in anticipo chi fa cosa nelle prime ore critiche dopo la scoperta di una compromissione.

Quando una vulnerabilità critica del core come quella di wp2shell viene sfruttata attivamente nel giro di poche ore dalla pubblicazione della patch, la differenza tra un sito che torna online in poche ore e uno che resta compromesso per giorni o settimane sta esattamente nella qualità del piano di disaster recovery messo in campo prima che l'incidente si verificasse. Per le aziende che vogliono davvero tutelarsi da scenari come questo, avere un servizio dedicato di disaster recovery permette di limitare drasticamente i tempi di fermo, recuperare rapidamente dati e configurazioni integre e minimizzare l'impatto economico e reputazionale di un attacco informatico riuscito.

Prevenire nuovi attacchi: perché la manutenzione continua fa la differenza

Uno degli aspetti più rilevanti del caso wp2shell è che ha colpito con particolare violenza i siti WordPress lasciati senza supervisione: installazioni con aggiornamenti automatici disattivati, senza un firewall applicativo, senza monitoraggio dei file e senza nessuno che controllasse regolarmente lo stato di sicurezza del sito. Molti di questi siti erano tecnicamente aggiornabili, ma nessuno si è accorto in tempo della necessità di intervenire.

Una strategia di manutenzione WordPress continuativa comprende l'aggiornamento tempestivo di core, plugin e temi non appena vengono rilasciate patch di sicurezza, il monitoraggio costante dell'integrità dei file per individuare modifiche non autorizzate, l'impiego di un firewall applicativo capace di bloccare pattern di attacco noti anche prima che la patch venga installata, controlli periodici sugli account utente e sui permessi, e backup regolari con test di ripristino. Questo tipo di presidio continuo è esattamente ciò che avrebbe permesso a molti siti coinvolti nella vicenda wp2shell di restare al sicuro, applicando la patch nelle stesse ore in cui è stata rilasciata, prima ancora che gli exploit pubblici cominciassero a circolare.

Per chi non ha un team interno dedicato alla sicurezza WordPress, delegare questa responsabilità a un partner specializzato in manutenzione WordPress significa poter contare su aggiornamenti applicati con la giusta priorità, monitoraggio professionale e un interlocutore pronto a intervenire nel momento esatto in cui viene scoperta una nuova vulnerabilità critica come quella di questo caso.

Obblighi normativi: NIS2, DORA e la responsabilità delle aziende

Per le organizzazioni che rientrano nel perimetro della direttiva NIS2 o del regolamento DORA, la vicenda wp2shell non è solo un problema tecnico ma anche un tema di conformità normativa. Entrambe le normative impongono obblighi precisi di gestione del rischio informatico, inclusa la necessità di identificare rapidamente le vulnerabilità critiche nei propri sistemi, applicare le patch necessarie in tempi congrui e, in alcuni casi, segnalare gli incidenti di sicurezza alle autorità competenti entro finestre temporali molto ristrette.

Un sito WordPress compromesso che gestisce dati di clienti, transazioni di e-commerce o servizi rivolti al pubblico può quindi generare non solo un danno diretto in termini di immagine e continuità operativa, ma anche conseguenze legali e sanzionatorie se l'azienda non riesce a dimostrare di aver adottato misure adeguate di prevenzione e risposta. Anche per questo motivo, disporre di un piano formalizzato di manutenzione e di disaster recovery non è più soltanto una buona pratica tecnica, ma un requisito sempre più vicino a un obbligo di legge per molte categorie di imprese.

Domande frequenti su wp2shell e sul ripristino di un sito WordPress hackerato

Come faccio a sapere se il mio sito WordPress è vulnerabile a wp2shell? Il modo più semplice è controllare la versione di WordPress installata dal pannello di amministrazione, sotto la voce Aggiornamenti. Se il sito è fermo a una versione compresa tra 6.8.0 e 6.8.5, tra 6.9.0 e 6.9.4 oppure tra 7.0.0 e 7.0.1, è a rischio e va aggiornato immediatamente alla versione patchata corrispondente.

Quanto tempo richiede ripristinare un sito WordPress hackerato? Dipende dalla gravità della compromissione e dalla disponibilità di un backup pulito. Se esiste un backup recente e verificato, il ripristino può richiedere poche ore. Senza backup, una pulizia manuale completa con verifica di file, database e utenti può richiedere diversi giorni, soprattutto se sono state installate più backdoor o se il codice malevolo si è propagato a più directory.

È possibile ripristinare un sito WordPress hackerato senza perdere i contenuti? Nella maggior parte dei casi sì, a condizione di intervenire con attenzione: articoli, pagine e media possono essere recuperati separando i contenuti legittimi dal codice iniettato nel database e nei file. È un'operazione delicata, perché rimuovere in modo troppo aggressivo può danneggiare contenuti reali, mentre una pulizia troppo leggera rischia di lasciare tracce del malware.

Conviene affidarsi a un professionista o si può fare da soli? Per un utente con solide competenze tecniche è possibile intervenire autonomamente su compromissioni semplici. Tuttavia, in un caso come wp2shell, dove l'attacco può portare alla creazione di account amministratore nascosti e all'esecuzione di codice arbitrario, il rischio di lasciare backdoor non rilevate è alto. Un servizio professionale di manutenzione WordPress riduce sensibilmente questo rischio e permette di ripristinare il sito con maggiore rapidità e sicurezza.

Cosa succede se non aggiorno subito il mio sito WordPress? Più tempo passa tra il rilascio della patch e l'aggiornamento effettivo, più aumenta la probabilità che il sito venga individuato dagli scanner automatici che gli attaccanti utilizzano per cercare installazioni vulnerabili su larga scala. Nel caso di wp2shell, le prime scansioni sono iniziate poche ore dopo la pubblicazione della patch, quindi ogni giorno di ritardo si traduce in un rischio concreto e crescente.

Conclusioni: cosa fare oggi, prima che sia troppo tardi

Il caso wp2shell è un promemoria molto concreto di quanto possa essere rapido il passaggio da vulnerabilità appena divulgata a exploitation di massa, e di quanto sia costoso lasciare un sito WordPress senza una supervisione costante. Se gestisci un sito basato su WordPress, il primo passo da compiere oggi stesso è verificare la versione installata e, se rientra tra quelle vulnerabili, aggiornarla immediatamente a 6.8.6, 6.9.5 o 7.0.2. Il secondo passo è controllare con attenzione utenti amministratori, plugin e file recenti per escludere una compromissione già in corso.

Se invece il tuo sito mostra già segnali di essere stato compromesso, agire in fretta e con metodo è l'unica strada per limitare i danni: isolare il sito, ripristinare da un backup sicuro o procedere con una pulizia professionale completa, e solo dopo rimetterlo online in sicurezza. E se vuoi evitare di ritrovarti nella stessa situazione alla prossima vulnerabilità critica del core WordPress, che prima o poi arriverà, vale la pena investire oggi in un servizio strutturato di manutenzione e in un piano di disaster recovery testato, capace di trasformare un potenziale disastro in un semplice contrattempo gestito in poche ore.