Il 17 luglio 2026, il team di sicurezza di WordPress ha rilasciato un aggiornamento straordinario per correggere una delle vulnerabilità più critiche degli ultimi anni. La falla, WP2Shell, non riguardava un plugin o un tema ma il core di WordPress: circostanza rara che ha ampliato il numero di installazioni esposte.
Ciò che ha reso questo incidente particolarmente delicato è stata la gravità della vulnerabilità e la rapidità con cui la situazione si è evoluta. A poche ore dal rilascio delle patch1 sono iniziate le analisi pubbliche e, nel giro di circa due giorni, sono comparse campagne automatizzate che cercavano siti ancora vulnerabili.
Per un provider di hosting, attendere che ogni installazione si aggiorni significa lasciare aperta una finestra di esposizione critica. Per questo motivo, il giorno della pubblicazione delle patch abbiamo avviato una procedura centralizzata per aggiornare le installazioni WordPress riconosciute sulla propria infrastruttura di hosting condiviso, riducendo il tempo di esposizione prima della diffusione della minaccia.
WP2Shell2 non è una singola vulnerabilità, ma una catena di attacco che combina due difetti distinti del core di WordPress. Il primo, CVE-2026-63030, interessa la gestione delle richieste batch della REST API. Il secondo, CVE-2026-60137, è un SQL injection in WP_Query, un difetto che può consentire di manipolare le interrogazioni al database.
Concatenati, questi punti possono consentire a un attaccante non autenticato di arrivare fino all’esecuzione remota di codice (Remote Code Execution, o RCE) senza aver bisogno di plugin vulnerabili o credenziali.
L’attacco sfrutta un’anomalia nella gestione delle richieste batch per aggirare alcuni controlli di autorizzazione. Così è possibile raggiungere un endpoint vulnerabile alla SQL injection, ottenere privilegi elevati e installare codice arbitrario sul sito. Gli attaccanti possono distribuire webshell (strumenti che consentono il controllo remoto del server) e meccanismi di persistenza, progettati per mantenere l’accesso dopo gli aggiornamenti.
Da leggere: come difendersi dalle vulnerabilità dei plugin WordPress
WordPress ha corretto la vulnerabilità con le versioni 6.8.6, 6.9.5 e 7.0.2, abilitando gli aggiornamenti forzati tramite il proprio sistema di auto-update per le installazioni compatibili. Ma la disponibilità della patch con la versione 7.0.3 ha segnato l’inizio della corsa degli attaccanti. Che hanno ricostruito la catena di attacco.
Poco dopo, sono comparsi i primi exploit3 pubblici. Nel giro di circa 48 ore sono iniziate campagne automatizzate di scansione e compromissione rivolte ai siti che non erano stati aggiornati.
La patch era già disponibile quando sono iniziati gli attacchi. Per questo, WP2Shell non viene generalmente classificata come uno zero-day, ma come una vulnerabilità con una finestra di sfruttamento che si è aperta molto rapidamente dopo la pubblicazione delle correzioni.
Di fronte a una vulnerabilità di questo tipo, il tempo è tutto. Serverplan non si è limitata ad attendere il normale meccanismo di aggiornamento di WordPress. Piuttosto, ha avviato dai propri sistemi di gestione una procedura centralizzata per aggiornare le installazioni riconosciute sull’ambiente di hosting condiviso.
L’intervento ha consentito di aggiornare circa il 90% delle installazioni già nelle prime fasi dell’emergenza, riducendo la finestra di esposizione prima che le campagne di sfruttamento diventassero un problema reale. Naturalmente, nessun sistema di automazione può coprire ogni scenario possibile.
Hosting gestito: veloce, affidabile, performante
L’efficacia della risposta è stata resa possibile anche dal lavoro del team Intrepid Support di Serverplan, che affianca gli strumenti di automazione con attività di monitoraggio, analisi e intervento quando le circostanze lo richiedono. Circa il 10% delle installazioni non è stato aggiornato perché presentava condizioni che richiedevano una verifica manuale. Come, ad esempio, errori, configurazioni particolari, aggiornamenti disabilitati o altre anomalie che rendevano rischioso un aggiornamento forzato.
Questo non significa che tali installazioni siano state ignorate. Con migliaia di installazioni è fisiologico che una parte richieda un intervento dedicato, preferendo la sicurezza operativa al rischio di compromettere il sito.
Aggiornare WordPress è il primo passo per chiudere la vulnerabilità, ma non sempre è sufficiente. Alcune installazioni erano già state oggetto di accesso abusivo: in questi casi applicare la patch impedisce nuovi attacchi, ma non rimuove ciò che è già stato installato. Serverplan ha organizzato la risposta su tre fasi: contenimento, bonifica e, nei casi più complessi, ricostruzione dell’installazione.
La priorità iniziale è stata interrompere l’attività degli attaccanti. Le installazioni compromesse sono state individuate correlando più indicatori di compromissione (IOC), evitando di classificare un sito sulla base di un singolo elemento sospetto.
Una volta confermata la compromissione, il sito veniva isolato e i principali meccanismi di persistenza riconosciuti disattivati. Così da impedire ulteriori accessi e preservare le evidenze utili alle fasi successive.
La bonifica è andata oltre la rimozione di file sospetti. Ogni installazione è stata analizzata per distinguere con attenzione i componenti realmente alterati da quelli perfettamente legittimi, evitando modifiche che avrebbero potuto compromettere il funzionamento del sito.
Solo gli elementi confermati come riconducibili alla compromissione sono stati rimossi o messi in quarantena. Mantenendo traccia delle operazioni eseguite e preservando dati e configurazioni del cliente.
Una compromissione di WordPress può interessare molte aree dell’applicazione rispetto ai file del core. La bonifica non si limita a eliminare i payload individuati. Ma verifica anche altri elementi che potrebbero consentire all’attaccante di mantenere o ripristinare l’accesso. Tra gli elementi oggetto di verifica rientrano:
wp-config.php e .htaccess.object-cache.php e advanced-cache.php.wp-content/uploads, dove la presenza di file PHP è spesso un’anomalia.Nessun elemento, preso singolarmente, è sufficiente per classificare un sito come compromesso. La valutazione avviene sempre correlando più evidenze, così da ridurre il rischio di falsi positivi e preservare i componenti legittimi dell’installazione.
In alcuni casi la compromissione può essere così estesa da non consentire di stabilire quali componenti siano ancora affidabili. La soluzione più sicura non è continuare a rimuovere singoli file, ma ricostruire l’installazione partendo da sorgenti verificate.
La procedura prevede la ricostruzione del core utilizzando esclusivamente i pacchetti ufficiali di WordPress, la reinstallazione di plugin e temi provenienti da repository verificati o copie affidabili. E la valutazione separata dei componenti commerciali o personalizzati.
Bisogna ripristinare il funzionamento del sito ricostruendo una catena di fiducia sul codice eseguito dall’installazione. Verificando l’assenza delle alterazioni conosciute e riportando il sito in uno stato affidabile.
L’aspetto meno visibile, ma più importante per il cliente: la risposta di Serverplan non è iniziata con le attività di bonifica. La rapidità dell’intervento è stata resa possibile anche grazie al modello di gestione adottato da Serverplan per i propri piani di hosting WordPress gestito.
Un servizio che prevede monitoraggio continuo, aggiornamenti centralizzati e procedure operative consolidate per ridurre al minimo i tempi di esposizione alle vulnerabilità. Grazie a questa base solida, lo stesso giorno della pubblicazione delle patch è stata avviata una campagna di aggiornamento centralizzato delle installazioni.
Hosting WordPress preinstallato e gestito con SiteBuilder AI incluso
Parallelamente sono stati sviluppati strumenti di analisi per individuare le installazioni che non potevano essere aggiornate automaticamente e quelle che presentavano evidenze di compromissione.
Quando le campagne di sfruttamento hanno iniziato a intensificarsi, la piattaforma disponeva già di procedure dedicate per affrontare le diverse fasi dell’incidente. Questo approccio ha permesso di combinare interventi automatizzati su larga scala con verifiche tecniche puntuali, limitando gli impatti sui singoli clienti.
Da leggere: plugin per aumentare la stabilità di WordPress
WP2Shell ricorda che la sicurezza di WordPress non si esaurisce con il rilascio di una patch. La capacità di reagire rapidamente, individuare le eccezioni, contenere gli attacchi e ripristinare in modo controllato le installazioni compromesse è oggi parte integrante della gestione di una piattaforma di hosting.
Per questo motivo, Serverplan continua a investire nello sviluppo di strumenti interni, automazione e procedure operative. Sono attività che consentano di affrontare vulnerabilità di questo tipo con rapidità, tracciabilità e il minor impatto possibile per i clienti.
