EssentialPlugin hackerata: backdoor in oltre 20 plugin WordPress colpisce migliaia di siti

La compromissione della suite EssentialPlugin segna uno degli episodi più gravi degli ultimi anni nel panorama WordPress. Un attacco supply chain ha inserito un backdoor in oltre 20 plugin molto diffusi, esponendo centinaia di migliaia di siti a infezioni silenziose, spam SEO, redirect malevoli e accessi non autorizzati. Il caso è particolarmente delicato perché il codice nocivo è stato introdotto dopo il cambio di proprietà del pacchetto plugin e mantenuto dormiente per circa sette mesi prima dell’attivazione. Quando il payload è entrato in funzione, il malware ha iniziato a operare in modo quasi invisibile per gli amministratori, mostrando contenuti manipolati soprattutto ai crawler dei motori di ricerca. L’intervento di WordPress.org ha bloccato la diffusione ulteriore del codice, ma non ha ripulito automaticamente i siti già compromessi.

La vendita della suite apre la strada all’attacco supply chain su WordPress

L’origine del caso risale al 2025, quando EssentialPlugin ha ceduto il proprio portafoglio di oltre trenta plugin a un nuovo proprietario attraverso una compravendita su marketplace. Proprio dopo questo passaggio di proprietà sarebbe stato introdotto il codice malevolo, nascosto dietro un commit che simulava un normale aggiornamento di compatibilità con una nuova versione di WordPress. Questo dettaglio è centrale perché mostra come l’attacco non sia partito da una vulnerabilità classica scoperta dall’esterno, ma da un abuso diretto della fiducia riposta nel maintainer del software. In altre parole, il repository ufficiale e il meccanismo di aggiornamento sono diventati il vettore di compromissione. È questo l’elemento che rende il caso molto più pericoloso di una normale falla plugin, perché colpisce l’intera filiera di distribuzione del software.

Il backdoor resta inattivo per mesi e poi si attiva su comando remoto

Il codice nocivo non ha iniziato subito a danneggiare i siti. Dopo essere stato inserito nei plugin, è rimasto silente per mesi, senza produrre effetti visibili. Questa fase dormiente ha reso più difficile la scoperta del problema, perché agli occhi degli amministratori i plugin continuavano a funzionare regolarmente. L’attivazione vera e propria è avvenuta soltanto il 5 aprile 2026, quando l’infrastruttura di comando e controllo ha iniziato a fornire il payload malevolo. La scelta di attendere così a lungo evidenzia una strategia tipica degli attacchi supply chain più sofisticati: minimizzare i sospetti iniziali, aumentare la base di installato infetto e colpire solo in un secondo momento, quando il codice è già distribuito su una platea molto ampia di siti. Questo approccio ha trasformato normali aggiornamenti plugin in una potenziale porta d’accesso per malware distribuito su larga scala.

L’endpoint REST non autenticato consente l’esecuzione del payload malevolo

Il meccanismo tecnico della compromissione ruota attorno a un endpoint REST API non autenticato, identificato come /analytics/. Questa rotta, condivisa dai plugin colpiti, contattava il dominio remoto utilizzato dall’infrastruttura dell’attaccante e riceveva dati che venivano poi elaborati in modo insicuro. Il punto critico era il metodo fetch_ver_info(), che eseguiva una deserializzazione di contenuti ricevuti dall’esterno. In presenza di una gadget chain PHP, questo comportamento consentiva di alterare il flusso del codice e arrivare a operazioni arbitrarie sul filesystem del server. Da qui nasceva la creazione del file wp-comments-posts.php, volutamente simile al legittimo wp-comments-post.php, così da nascondersi meglio in mezzo ai file standard del sito. Questo file diventava la base di una persistenza che permetteva al malware di restare attivo anche dopo la chiusura del primo vettore.

Il malware modifica wp-config.php e mostra spam solo ai crawler

Una delle parti più insidiose della campagna riguarda il modo in cui il codice malevolo altera il comportamento del sito. Dopo l’attivazione, il malware scrive istruzioni direttamente dentro wp-config.php, cioè uno dei file più sensibili dell’installazione WordPress. Attraverso queste modifiche il sito può generare pagine spam, redirect e contenuti falsi che non vengono mostrati ai visitatori normali, ma solo ai crawler come Googlebot. Questo schema è particolarmente pericoloso perché permette di sfruttare la reputazione del sito compromesso per finalità di spam SEO senza destare immediatamente sospetti nel proprietario. L’amministratore continua a vedere il sito funzionare in modo apparentemente normale, mentre i motori di ricerca indicizzano contenuti manipolati utili all’attaccante. In termini pratici, il danno non è solo tecnico ma anche reputazionale, perché può compromettere ranking, fiducia degli utenti e integrità del dominio.

Oltre 20 plugin coinvolti ampliano la portata della compromissione

L’attacco non ha colpito un singolo componente, ma una parte rilevante del catalogo EssentialPlugin. Tra i plugin coinvolti compaiono strumenti per slider, popup, gallery, countdown, FAQ, post grid, portfolio, testimonial, blog widget e altri moduli tipicamente installati su siti corporate, magazine, vetrine commerciali e landing page. Alcuni di questi prodotti contavano decine di migliaia di installazioni attive, e la somma complessiva porta l’incidente su una scala molto ampia. Proprio la natura trasversale della suite ha moltiplicato l’impatto: un’unica modifica condivisa nel codice analytics è bastata a compromettere contemporaneamente decine di prodotti differenti. Questo dimostra quanto possa essere fragile la sicurezza di un ecosistema plugin quando librerie comuni, endpoint condivisi e logiche replicate vengono riutilizzati su un gran numero di estensioni distribuite da un solo vendor.

WordPress.org rimuove i plugin e forza un aggiornamento di sicurezza

Di fronte alla conferma dell’attacco, il Plugin Review Team di WordPress.org è intervenuto il 7 aprile 2026 con una misura drastica. Tutti i plugin coinvolti sono stati rimossi in modo permanente dal repository ufficiale e, contestualmente, è stato spinto un aggiornamento di sicurezza forzato per neutralizzare il codice dannoso nelle versioni future. L’intervento ha modificato la funzione responsabile della ricezione dei dati analytics e ha interrotto il punto esatto in cui veniva innescato il flusso malevolo. Questa azione è servita a bloccare il backdoor sul canale di distribuzione ufficiale, ma non equivale a una bonifica completa dei siti già infetti. È un passaggio importante da chiarire, perché molti amministratori potrebbero ritenere sufficiente l’update automatico, mentre in realtà il codice già scritto nei file del sito può restare lì anche dopo la correzione del plugin.

L’update forzato non rimuove i file malevoli già presenti sui siti

Il limite principale della risposta automatica è che il fix impedisce l’esecuzione futura del backdoor, ma non cancella i segni dell’infezione lasciati sul server. Se il file wp-comments-posts.php è già stato creato oppure se wp-config.php è già stato alterato, l’amministratore deve intervenire manualmente. In questo senso l’incidente è particolarmente pericoloso perché la compromissione continua a vivere anche dopo la chiusura ufficiale del vettore iniziale. Il sito può quindi rimanere inquinato da codice spam, redirect nascosti o ulteriori funzioni di accesso non autorizzato. Per questo la semplice verifica della versione del plugin non basta. Serve una revisione diretta dell’installazione, dei file core, delle variazioni recenti e dell’eventuale presenza di script con nomi simili a quelli legittimi di WordPress, una tecnica tipica per nascondere backdoor in ambienti condivisi.

I webmaster devono controllare file, accessi e credenziali amministrative

Per chi ha usato uno dei plugin coinvolti, la priorità non è solo aggiornare o disattivare l’estensione, ma verificare se il sito sia già stato compromesso. Il primo controllo riguarda la presenza del file wp-comments-posts.php, che va distinto con attenzione dal file nativo wp-comments-post.php. Il secondo passaggio riguarda wp-config.php, che deve essere ispezionato per identificare righe sospette, richiami remoti, codice offuscato o istruzioni anomale. In molti casi può essere più sicuro sostituire il file con una copia pulita ricostruita da backup affidabili. Dopo la bonifica tecnica, è prudente cambiare tutte le password amministrative, rigenerare eventuali chiavi di sicurezza, rivedere gli utenti con privilegi elevati e monitorare i log per verificare se vi siano accessi anomali, nuove modifiche ai file o richieste sospette verso endpoint non previsti.

Il caso EssentialPlugin cambia la percezione del rischio nella supply chain WordPress

Questo incidente dimostra in modo molto concreto che il rischio non nasce solo da plugin vulnerabili, ma anche dai cambi di proprietà, dalla fiducia automatica negli aggiornamenti e dalla mancanza di controlli più severi sulla supply chain del software. Un plugin con una lunga storia e una reputazione positiva può trasformarsi rapidamente in un vettore di compromissione se passa nelle mani sbagliate. Per gli sviluppatori il caso impone maggiore attenzione alla firma del codice, alla verifica dell’integrità dei pacchetti e alla trasparenza sui cambi di ownership. Per i webmaster, invece, diventa essenziale monitorare non solo la disponibilità degli aggiornamenti, ma anche l’evoluzione del vendor, le anomalie nei changelog e la presenza di file inattesi dopo ogni update. EssentialPlugin rappresenta così un precedente pesante per l’intero ecosistema WordPress, perché mostra quanto un attacco supply chain possa essere silenzioso, esteso e difficile da bonificare senza un controllo manuale accurato.