Non tutti gli attacchi informatici partono da una vulnerabilità tecnica scoperta in laboratorio. Alcuni cominciano con una transazione commerciale perfettamente legale, pubblicata su un marketplace pubblico, con tanto di case study aziendale. È esattamente quello che è successo con Essential Plugin, un’azienda che sviluppava plugin WordPress da quasi un decennio e che, una volta ceduta, è diventata il vettore di uno degli attacchi alla supply chain più elaborati che l’ecosistema WordPress ricordi.

Un’azienda comprata, una backdoor piantata

La storia comincia intorno alla fine del 2024, quando il team originale, fondato nel 2015 sotto il nome WP Online Support da Minesh Shah, Anoop Ranawat e Pratik Jain, registra un calo dei ricavi tra il 35 e il 45%. Shah mette in vendita l’intera attività su Flippa, il marketplace dedicato alla compravendita di business digitali. Un acquirente identificato solo come “Kris”, con un profilo che mescola SEO, criptovalute e marketing nel settore del gioco d’azzardo online, acquisisce tutto per una cifra a sei cifre. Flippa ha persino pubblicato un case study sulla vendita nel luglio 2025, celebrandola come un’operazione di successo.

Quello che non era visibile in superficie è che il primo commit SVN effettuato dal nuovo proprietario sui plugin non era una correzione di bug, né un aggiornamento di compatibilità… ma una backdoor. L’8 agosto 2025, la versione 2.6.7 di Countdown Timer Ultimate viene caricata con un changelog che recita “compatibilità verificata con WordPress 6.8.2”. In realtà aggiunge 191 righe di codice al file class-anylc-admin.php, introducendo un meccanismo di esecuzione remota di codice arbitrario basato su deserializzazione PHP, uno dei pattern di attacco più pericolosi nel panorama della sicurezza web.

Il codice malevolo era strutturato in tre componenti. Un metodo chiamato fetch_ver_info() contattava il server dell’attaccante tramite file_get_contents() e passava la risposta a @unserialize(), la funzione PHP che converte dati serializzati in oggetti (un vettore classico per l’esecuzione di codice arbitrario). Un secondo metodo eseguiva poi una chiamata di funzione il cui nome, argomenti e comportamento erano interamente controllati dal server remoto. A completare il quadro, un endpoint REST API accessibile senza autenticazione rendeva l’intero meccanismo raggiungibile dall’esterno senza alcuna credenziale.

Tutto questo è rimasto dormiente per otto mesi, durante i quali nessun firewall ha rilevato il codice malevolo perché non faceva nulla di apparentemente sospetto. Poi, tra il 5 e il 6 aprile 2026, il comando analytics.essentialplugin.com ha cominciato a distribuire payload malevoli a tutti i siti che eseguivano uno qualsiasi dei plugin del portfolio.

plugin wordpress

Crediti: Shutterstock

Il payload: spam SEO invisibile con C2 su blockchain

Una volta attivata, la backdoor ha scaricato un file chiamato wp-comments-posts.php (volutamente simile al file di sistema wp-comments-post.php) e lo ha usato per iniettare un blocco massiccio di codice PHP all’interno di wp-config.php. Il codice iniettato si occupava di recuperare link spam, redirect e pagine false da un server di comando e controllo, ma li mostrava esclusivamente a Googlebot. Per il proprietario del sito tutto sembrava normale e per Google il sito stava pubblicando contenuti spam.

L’elemento più sofisticato dell’intera operazione riguarda il modo in cui veniva risolto il dominio del server C2, ovvero attraverso uno smart contract Ethereum interrogando endpoint RPC pubblici della blockchain. Un tradizionale sequestro di dominio non avrebbe risolto il problema perché l’attaccante poteva aggiornare il contratto in qualsiasi momento, puntando a un nuovo dominio senza modificare una riga di codice sui siti compromessi.

WordPress.org ha chiuso 31 plugin in un solo giorno

Il 7 aprile, il team Plugin di WordPress.org ha chiuso permanentemente tutti i plugin riconducibili all’account Essential Plugin (almeno 31 in un’unica giornata) e oggi l’endpoint analytics.essentialplugin.com restituisce {“message”:”closed”}. È una risposta rapida una volta scoperto l’attacco, ma arrivata ben otto mesi dopo che la backdoor era già stata piantata.

Crediti: Anchor

Crediti: Anchor

Il problema strutturale che questo caso porta in superficie è che WordPress.org non dispone di alcun meccanismo per rilevare o segnalare i trasferimenti di proprietà dei plugin. Non esiste una notifica automatica agli utenti installati e non scatta alcuna revisione aggiuntiva del codice quando cambia il titolare dell’account. L’acquisizione di Essential Plugin era pubblica, il profilo dell’acquirente era pubblico, ma nessun alert è scattato.

Cosa fare quindi? Il primo passo è verificare se uno dei 31 plugin compromessi (immagine sopra) è installato in qualsiasi sito gestito. Se presente, l’aggiornamento automatico alla versione 2.6.9.1 distribuito da WordPress.org è insufficiente, visto che disattiva il phone-home ma lascia intatto il modulo wpos-analytics con tutto il suo codice.

La soluzione completa è rimuovere l’intera directory wpos-analytics/ dal plugin, eliminare la funzione di caricamento nel file PHP principale e verificare le dimensioni di wp-config.php; se supera significativamente le attese (il payload aggiunge circa 6 KB), il sito è stato compromesso attivamente e richiede una pulizia completa, che va ben oltre la semplice disinstallazione del plugin.

(Immagine in apertura: Shutterstock)