WordPress in pericolo: compromessi i plugin di Essential Plugin, wp-config.php accessibile pubblicamente

Un singolo acquirente, conosciuto solo come "Kris", ha comprato un intero portafoglio di plugin WordPress per una cifra a sei zeri. Pochi mesi dopo, migliaia di siti si sono ritrovati con una backdoor nel cuore del proprio codice. È il classico attacco alla supply chain - colpire il fornitore per raggiungere tutti i suoi clienti - e questa volta il bersaglio è l'ecosistema di plugin che alimenta una quota enorme del web mondiale. Compreso quello di moltissime piccole imprese e professionisti italiani che su WordPress hanno costruito la propria presenza online.

L'acquisizione: comprare la fiducia su Flippa

La storia comincia nei primi mesi del 2025, quando tale "Kris" - un profilo legato al mondo SEO, criptovalute e marketing per il gioco d'azzardo online - acquista tramite il marketplace Flippa il portafoglio di Essential Plugin, precedentemente noto come WP Online Support. Almeno 26 plugin, per una base installata nell'ordine delle centinaia di migliaia di siti. I creatori originali - Minesh Shah, Anoop Ranawat e Pratik Jain - avevano costruito il loro business dal 2015, ma il fatturato era calato del 35-45% entro la fine del 2024. Una vendita comprensibile, dal punto di vista di chi cede. Un'opportunità perfetta, dal punto di vista di chi attacca.

Il 12 maggio 2025 un nuovo account, essentialplugin, compare su WordPress.org con accesso SVN in scrittura su tutti e 26 i plugin. A quel punto il nuovo proprietario ha le chiavi di casa: può modificare il codice sorgente e distribuire aggiornamenti a ogni sito che utilizza quei plugin. Gli utenti non ricevono alcuna notifica del cambio di proprietà.

Anatomia della backdoor

L'8 agosto 2025 viene rilasciata la versione 2.6.7 di Countdown Timer Ultimate. Il changelog recita candidamente: «Check compatibility with WordPress version 6.8.2». In realtà, 191 righe di codice malevolo vengono innestate nel modulo wpos-analytics, un componente fino a quel momento legittimo, usato per raccogliere dati di utilizzo con il consenso dell'utente. Il file class-anylc-admin.php passa da 473 a 664 righe.

I meccanismi introdotti sono tre. Un metodo fetch_ver_info() che richiama file_get_contents() verso il server dell'attaccante e passa la risposta a @unserialize() - tecnica classica di deserializzazione PHP che consente l'esecuzione di codice arbitrario. Un metodo version_info_clean() che invoca funzioni i cui nomi arrivano direttamente dai dati deserializzati dal server remoto, aprendo la porta a chiamate arbitrarie. E un endpoint REST API completamente privo di autenticazione, configurato con permission_callback: __return_true. Chiunque può bussare, e la porta si apre.

Il plugin contattava analytics.essentialplugin[.]com per ricevere istruzioni. Una volta attivato, scaricava un file chiamato wp-comments-posts.php - un nome quasi identico al legittimo wp-comments-post.php del core di WordPress - e iniettava circa 6 kB di codice PHP direttamente dentro wp-config.php, il file di configurazione principale di ogni installazione WordPress. Il codice veniva appeso sulla stessa riga di require_once ABSPATH . 'wp-settings.php';, una posizione scelta per sfuggire a ispezioni superficiali.

Otto mesi nel silenzio

Ed ecco il dettaglio che trasforma un attacco grave in un attacco brillante, se ci si concede il cinismo tecnico. La backdoor è rimasta dormiente per circa otto mesi. Dall'8 agosto 2025 al 5 aprile 2026 il server di comando e controllo ha restituito risposte innocue. In tutto quel tempo il codice malevolo si è propagato silenziosamente con ogni nuova installazione o aggiornamento, senza che alcun sistema di sicurezza avesse motivo di allarmarsi. Centinaia di migliaia di siti hanno accolto il cavallo di Troia senza saperlo.

Il 5-6 aprile 2026 il server ha iniziato a distribuire payload malevoli. L'analisi forense condotta da Austin Ginder - utilizzando backup giornalieri di CaptainCore basati su restic - ha individuato una finestra di iniezione confermata in wp-config.php tra le 04:22 e le 11:06 UTC del 6 aprile: sei ore e 44 minuti in cui il danno si è materializzato.

Invisibile ai proprietari, visibilissimo a Google

La parte più insidiosa riguarda chi può vedere cosa. Il codice iniettato recuperava link di spam, reindirizzamenti e pagine false da un server C2 e li serviva esclusivamente a Googlebot. Chi visitava il proprio sito con un browser normale non notava nulla di anomalo. Ma il crawler di Google vedeva un sito infarcito di contenuti spam - con conseguenze devastanti sul posizionamento nei risultati di ricerca. Per un piccolo imprenditore o un professionista italiano che dipende dalla visibilità organica, questo si traduce in clienti persi senza alcun segnale visibile del problema.

La tecnica di evasione non si ferma qui. Il malware risolveva l'indirizzo del proprio server C2 attraverso uno smart contract su Ethereum, interrogando endpoint RPC pubblici sulla blockchain. Il vantaggio per l'attaccante è strutturale: non basta un sequestro di dominio tradizionale per neutralizzare l'infrastruttura. L'attaccante può aggiornare lo smart contract in qualsiasi momento, puntando a un nuovo dominio. Un'architettura di comando e controllo resistente per progettazione.

La risposta di WordPress.org e i suoi limiti

Il 7 aprile 2026 WordPress.org ha reagito forzando l'aggiornamento dei plugin coinvolti alla versione 2.6.9.1, che disabilita il meccanismo di phone-home tramite semplici istruzioni return;. Un cerotto necessario, ma con un problema critico: l'aggiornamento forzato non ripulisce wp-config.php. Il codice PHP già iniettato resta attivo e operativo anche dopo l'aggiornamento. Chi si affida passivamente agli aggiornamenti automatici rimane compromesso senza saperlo.

Il problema di fondo è di governance. L'attuale processo di trasferimento di proprietà dei plugin su WordPress.org prevede che per i plugin con meno di 10.000 utenti il trasferimento possa avvenire in modalità self-service. Per quelli più diffusi è sufficiente che il proprietario attuale invii una mail a plugins@wordpress.org. WordPress.org verifica che il vecchio proprietario abbia autorizzato il passaggio, ma non esegue alcuna verifica sul nuovo proprietario e non revisiona il primo commit di codice successivo al trasferimento. Gli utenti esistenti non vengono informati.

Il risultato è un modello in cui chiunque disponga di sufficiente denaro può acquistare un canale di distribuzione software con centinaia di migliaia di installazioni attive - e iniettare codice malevolo alla prima occasione utile. Non è un bug: è un difetto architetturale del sistema di fiducia.

Un ecosistema sotto pressione

Questo attacco non è un caso isolato. Nella stessa settimana è stato compromesso anche Smart Slider 3 Pro:

» Leggi: Smart Slider 3 Pro per WordPress e Joomla compromesso per veicolare malware - come controllare se il tuo sito è in pericolo

Un'altra falla critica, CVE-2025-27007 nel plugin OttoKit - installato su oltre 100.000 siti - è stata sfruttata attivamente entro un'ora dalla divulgazione.

Cosa fare adesso

Se gestite un sito WordPress con uno qualsiasi dei plugin del portafoglio Essential Plugin, il vostro sito va considerato potenzialmente compromesso. L'aggiornamento automatico non è sufficiente.

• Aprite wp-config.php e cercate codice PHP estraneo in prossimità della riga require_once ABSPATH . 'wp-settings.php';. Un file infetto risulta più pesante di circa 6 kB rispetto alla versione pulita
• Cercate nella webroot un file chiamato wp-comments-posts.php (con la s). Non è un file del core di WordPress: se esiste, è la backdoor.
• Rimuovete completamente i plugin coinvolti. WordPress.org non li riattiverà.
• Se trovate tracce di compromissione, controllate anche gli account amministrativi del sito e valutate un ripristino da un backup acquisito prima dell'installazione dei plugin manomessi

L'attacco di Essential Plugin è un promemoria scomodo ma necessario: nel modello WordPress, ogni plugin installato è una relazione di fiducia con il suo sviluppatore. Se quello sviluppatore cambia - e nessuno ve lo dice - la fiducia che avevate riposto non vale più nulla. Per chi gestisce un sito professionale, anche piccolo, il momento di verificare è adesso.

Fonti: anchor.host, cybersecuritynews.com, mysites.guru