Hanno comprato 30 plugin WordPress: perché questo caso ci riguarda più di quanto sembri

Quando parliamo di sicurezza su WordPress, quasi sempre immaginiamo lo stesso scenario. Un plugin ha una vulnerabilità, qualcuno la scopre, esce una patch, e chi gestisce il sito deve aggiornare in fretta. È il racconto classico della sicurezza informatica applicata ai CMS. Un racconto vero, certo, ma non completo.

Perché a volte il problema non nasce da un errore nel codice scritto male. A volte nasce da qualcosa di più sottile, e forse anche più pericoloso: nasce dal fatto che un software di cui ci fidavamo cambia proprietario, cambia gestione, cambia intenzioni. E a quel punto il rischio non è più soltanto tecnico. Diventa un problema di fiducia, di filiera, di controllo nel tempo.

Ho letto un articolo pubblicato da Anchor Hosting che racconta proprio un caso di questo tipo. La vicenda riguarda un gruppo di plugin WordPress acquistati in blocco e poi, secondo la ricostruzione tecnica pubblicata, trasformati in un veicolo per introdurre una backdoor. Non un attacco rumoroso e immediato, ma un’operazione paziente: acquisto, modifica del software, attesa di mesi, attivazione successiva. Anchor Hosting parla di oltre 30 plugin compromessi, 31 plugin chiusi da WordPress.org e una backdoor rimasta dormiente per circa otto mesi. mySites.guru, riprendendo il caso, parla a sua volta di 31 plugin del portafoglio Essential Plugin e colloca l’attivazione tra il 5 e il 6 aprile 2026, dopo l’inserimento del codice malevolo nell’agosto 2025.

Ed è proprio questo che rende la storia interessante. Non tanto perché coinvolga WordPress in sé, ma perché ci costringe a ragionare su una domanda che quasi nessuno si pone davvero quando installa un plugin: di chi mi sto fidando, esattamente?

Non è la solita vulnerabilità

Questo caso colpisce perché ci porta fuori dal modello mentale più comune. Non siamo davanti alla classica falla scoperta da un ricercatore e poi corretta con un aggiornamento. Qui il punto, almeno in base alle analisi pubblicate, è diverso.

Il problema non sarebbe un bug accidentale

Secondo Anchor Hosting e mySites.guru, il codice malevolo non sarebbe il frutto di un errore involontario, ma di una modifica introdotta dopo l’acquisizione del portafoglio di plugin. In altre parole, non staremmo parlando di una vulnerabilità “trovata” da un attaccante dentro un plugin esistente, ma di una funzionalità malevola inserita da chi avrebbe avuto accesso diretto alla distribuzione del software. È un passaggio fondamentale, perché cambia completamente il tipo di difesa mentale che un amministratore di siti dovrebbe avere.

La parola giusta è supply chain

mySites.guru presenta esplicitamente la vicenda come un supply chain attack, cioè un attacco alla catena di distribuzione del software. Questo significa che il bersaglio non è soltanto il singolo sito WordPress finale. Il punto di ingresso diventa la relazione di fiducia tra l’utente e il plugin che installa o aggiorna. E quando si rompe quella fiducia, il problema non resta confinato a un solo sito: può propagarsi a tutti quelli che usano quel componente.

Perché questa storia è importante anche per chi non è un esperto

La cosa più interessante di questo episodio è che non riguarda soltanto gli addetti ai lavori. Riguarda anche chi ha un piccolo blog, un sito professionale, un sito aziendale semplice, oppure un progetto realizzato anni fa e mantenuto in modo essenziale.

Il motivo è molto semplice: tantissime persone scelgono i plugin in base a segnali apparentemente rassicuranti. Il plugin esiste da anni, ha molte installazioni, sembra conosciuto, magari ha anche recensioni positive. E allora si pensa che sia affidabile.

La reputazione del passato non basta

Questo è il punto su cui secondo me vale davvero la pena fermarsi. Un plugin può essersi costruito una reputazione eccellente nel corso degli anni. Può essere nato da un team serio, può essere stato scritto bene, può aver servito migliaia di siti senza problemi. Ma tutto questo non garantisce che il livello di fiducia resti identico nel tempo.

Se il progetto cambia mano, cambia anche il rischio. E questo passaggio può essere molto meno visibile di quanto si immagini. WordPress.org documenta sia il trasferimento a un nuovo proprietario sia il take over di plugin esistenti, con regole specifiche e l’indicazione di aggiornare la documentazione del plugin per riflettere il cambio di ownership. Quindi il cambio di proprietà non è affatto un evento anomalo nell’ecosistema: è qualcosa che può succedere legittimamente. Il problema è che per l’utente finale questo passaggio spesso resta sullo sfondo, mentre dal punto di vista della sicurezza è un momento delicatissimo.

Installare un plugin significa delegare fiducia

Quando installiamo un plugin, non stiamo semplicemente aggiungendo una funzione al nostro sito. Stiamo dicendo a quel software che può vivere dentro l’applicazione, leggere dati, interagire con il database, ricevere aggiornamenti futuri e continuare a operare nel tempo. In pratica, gli stiamo consegnando una porzione della fiducia del nostro progetto.

E questa è una cosa che spesso dimentichiamo, perché siamo abituati a pensare ai plugin come a oggetti tecnici, piccoli mattoncini funzionali. In realtà ogni plugin è anche un rapporto di fiducia continuativo con chi lo sviluppa e con chi lo aggiorna.

Il punto non è “WordPress è insicuro”

Qui secondo me bisogna stare molto attenti. Sarebbe facile trasformare questa vicenda nel solito titolo superficiale: ecco, WordPress è insicuro, i plugin sono pericolosi, non ci si può fidare di niente. Ma sarebbe una conclusione sbagliata.

Quello che questo caso ci mostra non è che WordPress abbia un problema unico e speciale. Ci mostra piuttosto qualcosa di molto più generale: tutti gli ecosistemi basati su componenti di terze parti hanno un problema di fiducia nella supply chain.

Succede ovunque ci siano dipendenze esterne

Il principio non riguarda solo WordPress. Vale anche per i pacchetti Python, per npm nel mondo JavaScript, per le immagini Docker, per i plugin del browser, per le librerie che importiamo nei nostri progetti, per qualsiasi software aggiornabile da terzi. WordPress rende questa dinamica molto visibile, perché l’ecosistema dei plugin è enorme e perché molti siti sono gestiti da persone che non fanno sviluppo in modo professionale. Ma il meccanismo di fondo è universale.

Per questo, a mio avviso, il messaggio utile non è “abbiate paura dei plugin”. Il messaggio utile è un altro: non valutate il software solo per quello che fa oggi, ma anche per chi lo controllerà domani.

Perché non basta dire “aggiornate tutto”

Uno dei consigli più ripetuti in assoluto nella sicurezza WordPress è: aggiornate core, temi e plugin. Ed è un consiglio giusto. Nella grande maggioranza dei casi, aggiornare resta una pratica fondamentale. Ma vicende come questa ci ricordano che la realtà è un po’ più complessa.

Perché se l’aggiornamento arriva attraverso una filiera compromessa, l’aggiornamento stesso può diventare parte del problema. Non vuol dire che bisogna smettere di aggiornare. Quella sarebbe una reazione sbagliata. Vuol dire però che aggiornare non è l’unica difesa, e soprattutto che la sicurezza non coincide solo con il patching.

Quando la fiducia nell’update diventa cieca

Molti siti WordPress vivono in una specie di automatismo permanente. Plugin installati anni fa, aggiornamenti fatti quasi per inerzia, poca revisione periodica, poche domande sul progetto che c’è dietro. È una situazione molto comune, soprattutto nei siti piccoli. E in parte è comprensibile, perché nessuno può fare auditing profondo di tutto.

Però casi come questo interrompono quella comodità mentale. Ci ricordano che un plugin sicuro in passato non è automaticamente sicuro per sempre. Può cambiare il team, può cambiare il modello di business, può cambiare il proprietario, può cambiare anche il tipo di intenzione dietro gli aggiornamenti.

In questo caso il problema non sarebbe stato solo il plugin

Secondo mySites.guru, non si tratterebbe di una semplice vulnerabilità con patch disponibile, ma di plugin chiusi in modo permanente su WordPress.org, con un possibile impatto che andrebbe oltre il singolo file del plugin. L’analisi parla infatti di iniezione di spam SEO in wp-config.php, che è un dettaglio importante perché suggerisce una persistenza anche fuori dal normale perimetro del componente compromesso. Se questo quadro tecnico è corretto, significa che per alcuni siti non basterebbe disattivare il plugin e andare avanti: servirebbero controlli più profondi.

La vera lezione: guardare la governance del software

A me sembra che il valore più grande di questo caso sia proprio qui. Ci obbliga a fare un salto di maturità. Ci porta a vedere il software non solo come codice, ma come codice più governance.

Questo significa guardare non soltanto la funzione del plugin, ma anche la storia del progetto. Chi lo mantiene. Come comunica. Quanto è trasparente. Se ci sono cambiamenti improvvisi. Se il ciclo di aggiornamento ha una logica coerente. Se il plugin è ancora davvero seguito. Se ci sono segnali strani.

Un plugin non è solo una funzionalità

Ogni volta che aggiungiamo un plugin, stiamo ampliando due cose. La prima è la superficie tecnica del sito. La seconda è la superficie di fiducia. E spesso la seconda è persino più importante della prima, perché è quella che determina da chi riceveremo codice in futuro.

Per questo, secondo me, uno dei messaggi più utili da portarsi a casa da questa vicenda è molto semplice: meno plugin, ma scelti meglio. Non significa rinunciare alle estensioni. Significa ridurre la complessità inutile, evitare i plugin ridondanti, rivalutare periodicamente quelli vecchi, e soprattutto smettere di considerarli tutti equivalenti.

La manutenzione non è solo “funziona ancora?”

Un errore molto diffuso è tenere un plugin perché “tanto funziona”. Ma il fatto che funzioni non ci dice nulla sulla qualità della manutenzione, sullo stato del progetto, sulla continuità del team o sul livello di attenzione dietro gli aggiornamenti.

La manutenzione vera non è solo verificare che il sito non vada in errore. È anche chiedersi se stiamo ancora affidando parti del nostro progetto a soggetti che meritano quella fiducia.

Conclusione

L’articolo di Anchor Hosting è, secondo me, un ottimo punto di partenza per affrontare un tema serio senza scadere nel sensazionalismo. La ripresa del caso da parte di mySites.guru aggiunge ulteriore contesto tecnico e rafforza l’idea che non siamo davanti alla solita vulnerabilità classica, ma a un possibile attacco di supply chain costruito nel tempo.

La lezione più importante, però, va oltre questo episodio. La sicurezza non dipende solo dai bug. Dipende anche da chi controlla il software che facciamo entrare nei nostri sistemi. E forse è proprio questa la domanda che dovremmo imparare a farci più spesso: non soltanto “questo plugin è utile?”, ma anche “sto ancora dando fiducia al soggetto giusto?”

Perché nel web di oggi il rischio non passa solo dalle vulnerabilità evidenti. A volte passa da qualcosa di molto più silenzioso: un software che sembrava affidabile, un nome che conoscevamo, una reputazione costruita nel tempo, e poi un cambio di mano che quasi nessuno nota.

Ed è qui che questa storia diventa davvero interessante. Perché ci ricorda che la sicurezza non è fatta solo di aggiornamenti, patch e configurazioni corrette. È fatta anche di attenzione, di selezione, di contesto e di memoria. In altre parole, è fatta di fiducia. E la fiducia, nel software, non dovrebbe mai essere automatica.