Non ti hackerano perché sei importante: ti hackerano perché hai un plugin del 2021

Quando un sito aziendale viene compromesso, la prima reazione dell'imprenditore è quasi sempre la stessa: «ma chi vuoi che se la prenda con noi, siamo una piccola azienda». È una domanda ragionevole, e la risposta è che non se l'è presa nessuno. Nessuno ti ha scelto, nessuno ha studiato la tua azienda, nessuno sapeva della tua esistenza fino a cinque minuti prima. Il tuo sito è finito in un elenco insieme ad altre decine di migliaia perché un programma automatico ha bussato a una porta, ha trovato una versione vecchia di un plugin installato tre anni fa e ha proseguito.

È una differenza che sembra filosofica e invece è operativa. Se pensi di essere un bersaglio, ti difendi dai bersaglieri. Se capisci che sei semplicemente uno dei tanti indirizzi in una lista, allora capisci anche che l'unica difesa che conta è non avere la porta che quel programma sta cercando.

C'è un pregiudizio duro a morire, e cioè che WordPress sia insicuro. I numeri raccontano una storia diversa e molto più precisa. Nel corso del 2025 sono state individuate 11.334 nuove vulnerabilità nell'ecosistema WordPress, il 42% in più rispetto all'anno precedente. Di queste, il 91% riguardava i plugin e il 9% i temi. Nel core di WordPress ne sono state trovate sei, tutte a bassa priorità.

Sei, su oltre undicimila.

Il software che fa girare il tuo sito, quindi, è tra i pezzi più solidi della tua infrastruttura. Il problema è tutto quello che ci hai attaccato sopra negli anni: il plugin per il modulo di contatto, quello per la gallery, quello per il cookie banner, quello per il countdown della promozione di Natale 2021 che non hai mai disattivato, quello che l'agenzia precedente aveva installato per fare una cosa che nessuno ricorda più.

Ognuno di questi è codice di terze parti che gira sul tuo server con i permessi del tuo sito. Ognuno è mantenuto, o non mantenuto, da qualcuno che non conosci e con cui non hai un contratto.

Il dato che dovrebbe far riflettere di più non riguarda quante vulnerabilità esistono, ma quanto in fretta vengono sfruttate. Secondo il report Patchstack sullo stato della sicurezza WordPress, il tempo mediano fra la pubblicazione di una vulnerabilità e i primi attacchi reali è di circa cinque ore. Il 20% delle vulnerabilità più sfruttate viene attaccato entro sei ore dalla divulgazione, il 45% entro ventiquattro ore, il 70% entro una settimana.

Cinque ore significa che la finestra fra «si sa che quel plugin ha un buco» e «i bot stanno già provando quel buco su ogni sito che lo usa» è più corta di una mattinata di lavoro. Chi aggiorna i plugin una volta al mese, o ogni volta che se ne ricorda, non sta facendo manutenzione in ritardo: sta arrivando dopo che la partita è finita.

C'è poi un secondo dato, ancora meno rassicurante: nel 46% dei casi la vulnerabilità è stata resa pubblica senza che lo sviluppatore avesse ancora rilasciato una correzione. In quasi la metà delle situazioni, insomma, aggiornare tempestivamente non basta, perché non c'è nulla da aggiornare. In quei casi l'unica difesa è sapere che il problema esiste e disattivare il plugin finché non arriva la patch. E per saperlo bisogna che qualcuno stia guardando.

Questa è la convinzione che smonto più spesso durante gli audit. L'idea è intuitiva: se pago, qualcuno se ne occupa. I dati dicono il contrario. Su quasi duemila segnalazioni di vulnerabilità che nel 2025 hanno riguardato prodotti premium o freemium, il 76% era effettivamente sfruttabile in attacchi reali e i prodotti a pagamento hanno registrato il triplo delle vulnerabilità già note come sfruttate rispetto a quelli gratuiti.

Il motivo, se ci pensi, è banale. I plugin premium non passano dalla revisione del repository ufficiale, si aggiornano attraverso canali proprietari che quasi sempre richiedono una licenza attiva, e quando la licenza scade il plugin continua a funzionare ma smette silenziosamente di ricevere aggiornamenti. Quante licenze scadute hai sul tuo sito in questo momento? È una domanda che vale la pena porsi, perché nella maggior parte dei siti che analizzo la risposta è «almeno una, e nessuno se n'era accorto».

Arriviamo al punto che dà il titolo a questo articolo, e che è il vero buco nero della manutenzione.

Quando un plugin viene chiuso o rimosso dal repository ufficiale, perché lo sviluppatore ha smesso di mantenerlo, perché ha violato le linee guida o perché è stato trovato un problema di sicurezza, il tuo sito non ti dice niente. WordPress continua a mostrartelo come aggiornato, perché tecnicamente non esistono versioni successive. La schermata Salute del sito non ti avvisa. Nessuna notifica, nessun badge, nessun colore diverso nella bacheca.

Dal tuo pannello, un plugin morto e sepolto è indistinguibile da un plugin sano.

E non stiamo parlando di software marginale: fra i plugin che negli ultimi tempi sono stati chiusi o hanno perso l'accesso al repository ci sono nomi con milioni di installazioni attive. L'unico modo per accorgersene, oggi, è aprire a mano la pagina di ogni singolo plugin sul repository e controllare. Con quaranta plugin installati su cinque siti diversi, è un lavoro che nessuno fa spontaneamente.

Se il rischio del plugin abbandonato ti sembra teorico, c'è un caso recente che lo rende molto concreto e che in Italia è passato quasi inosservato.

Nell'estate del 2025 un acquirente ha comprato, tramite una piattaforma di compravendita di asset digitali, un pacchetto di oltre trenta plugin WordPress da uno sviluppatore che voleva uscire dal settore. Nell'operazione erano compresi anche gli accessi per pubblicare gli aggiornamenti sul repository ufficiale. Secondo la ricostruzione di chi ha indagato sul caso, il primissimo aggiornamento pubblicato dal nuovo proprietario conteneva già il codice malevolo.

Il codice è rimasto silente per mesi. Poi, ad aprile 2026, si è attivato: scaricava un file esterno, iniettava PHP nella configurazione del sito e cominciava a mostrare spam a Googlebot restando invisibile ai visitatori umani. Il proprietario del sito non vedeva nulla di anomalo. Google, invece, vedeva un sito pieno di pagine di spam. Il 7 aprile 2026 il repository ufficiale ha chiuso trentuno di quei plugin; l'aggiornamento forzato distribuito il giorno dopo ha spento il meccanismo di comunicazione col server esterno, ma non ha ripulito i file già infettati.

I plugin coinvolti erano strumenti ordinari e diffusissimi: countdown, slider, popup, gallerie, griglie di articoli, caroselli di testimonianze. Esattamente il genere di plugin che si installa una volta, si configura in dieci minuti e non si guarda più.

Questo caso spiega meglio di qualunque ragionamento astratto perché un plugin abbandonato è pericoloso anche quando non ha vulnerabilità: perché è un asset che può cambiare proprietario senza che tu lo sappia, e perché nel tuo sito quel proprietario ha il permesso di eseguire codice.

La parte che di solito viene sottovalutata è che un sito violato non è quasi mai un problema tecnico circoscritto. È un problema di visibilità che si trascina per mesi.

Nella maggior parte dei casi che ho gestito, l'obiettivo dell'attacco non era rubare dati o chiedere un riscatto: era usare l'autorevolezza del tuo dominio per posizionare contenuti di spam. Il sito continua a funzionare, il centralino continua a squillare, e nel frattempo su Google compaiono centinaia di pagine che parlano di farmaci, scommesse o repliche di orologi, servite solo al crawler. Di solito il proprietario se ne accorge quando arriva l'avviso in Search Console, oppure quando un cliente segnala che cercando il nome dell'azienda esce qualcosa di imbarazzante.

Da lì in avanti la strada è lunga: rimozione del malware, ripulitura del database, richiesta di riesame, deindicizzazione delle pagine di spam, ricostruzione della fiducia. Nel frattempo, se Google ha marcato il sito come compromesso, chi arriva dai risultati di ricerca vede un avviso rosso a tutto schermo prima ancora di entrare. Il danno commerciale non è la giornata di fermo: sono i mesi di traffico e credibilità che servono a tornare al punto di partenza.

Ed è per questo che la sicurezza di un sito WordPress non è un tema da sistemisti. È parte integrante della SEO tecnica, tanto quanto la velocità o l'indicizzazione, ed è uno dei primi controlli che faccio quando lavoro come u003ca href=u0022https://mauriziopacenza.it/servizi-seo/seo-wordpress/u0022u003eu003cstrongu003econsulente SEO WordPressu003c/strongu003eu003c/au003e. Vale la stessa logica di cui parlavo a proposito dei siti lenti: il danno non arriva tutto insieme, arriva un po' alla volta mentre pensi che vada tutto bene.

C'è un'ultima illusione da smontare, e riguarda la frase «ma il mio hosting ha il firewall».

Il report Patchstack ha messo alla prova le difese di diversi provider contro attacchi che sfruttavano vulnerabilità già note e pubblicamente documentate. Il risultato è che le protezioni testate hanno bloccato circa il 12% degli attacchi, percentuale che sale a poco più di un quarto allargando il campo di prova. Il provider che si è comportato meglio si è fermato intorno al 60%. Qualcuno ha bloccato zero.

Non è un motivo per cambiare hosting domani mattina, ed è giusto dire che un buon servizio di hosting fa moltissima differenza su altri fronti: isolamento degli account, backup affidabili, versioni di PHP aggiornate, tempi di risposta. Ma il firewall del provider non è una manutenzione, e non lo diventa perché nel pannello c'è una spunta verde. È uno strato, utile, che copre una parte del problema.

Non serve un audit completo per farsi un'idea onesta della situazione. Bastano quattro domande, e puoi rispondere da solo aprendo la bacheca del sito.

La prima: quanti plugin hai installati e quanti ne usi davvero? Non è raro trovare venticinque plugin attivi su un sito vetrina di dieci pagine. Ogni plugin che non serve è superficie d'attacco regalata, e disinstallarlo è l'intervento di sicurezza col miglior rapporto fra costo e beneficio che esista. Attenzione: disattivare non basta, il codice resta sul server. Va rimosso.

La seconda: da quanto tempo non viene aggiornato ciascun plugin? Apri la pagina del plugin sul repository ufficiale e guarda la data dell'ultimo aggiornamento e la versione di WordPress con cui è dichiarato compatibile. Se leggi che il plugin non è stato testato con le ultime tre versioni di WordPress, quel plugin è di fatto in stato di abbandono, a prescindere da quello che ti dice la bacheca.

La terza: quali licenze premium sono scadute? Ogni plugin a pagamento con licenza non rinnovata è un plugin che ha smesso di aggiornarsi, spesso da anni, spesso senza che nessuno lo abbia notato.

La quarta, la più scomoda: se domani mattina il sito fosse compromesso, in quanto tempo torneresti online e da quale backup? Non «esiste un backup», ma: dove si trova, ogni quanto viene fatto, quante copie vengono conservate e soprattutto quando è stata l'ultima volta che qualcuno ha provato a ripristinarlo. Un backup mai testato è una speranza, non una procedura. E se il backup risiede sullo stesso server del sito, in caso di compromissione seria hai un problema in più, non uno in meno.

Un sito aziendale WordPress in salute richiede pochissime cose fatte con regolarità: aggiornamenti applicati entro giorni e non entro mesi, un numero di plugin ridotto all'essenziale e periodicamente ripulito, un monitoraggio che ti avvisi quando un componente installato risulta vulnerabile o chiuso, backup esterni e testati, autenticazione a due fattori sugli accessi amministrativi, e la rimozione degli utenti di chi non lavora più con te, vecchie agenzie comprese.

Non è un progetto. È un'ora al mese, fatta da qualcuno che sa dove guardare.

Il punto è che quest'ora, nella stragrande maggioranza delle aziende, non è di nessuno. Il sito è stato fatto anni fa, l'agenzia che l'ha realizzato ha chiuso il rapporto alla consegna, l'hosting è pagato con addebito automatico e nessuno ha mai definito chi sia responsabile della manutenzione. Il sito è di tutti e quindi non è di nessuno, finché non succede qualcosa. È lo stesso nodo che salta fuori quando ci si chiede se il sito sia davvero tuo o dell'agenzia: cambia il sintomo, la causa è sempre che nessuno ha in mano quel sito.

Se questa descrizione ti somiglia, il primo passo non è comprare un plugin di sicurezza. È fare un inventario onesto di cosa gira sul tuo sito e di quanto è vecchio: è esattamente il punto di partenza di un check-up del sito WordPress, e nella maggior parte dei casi le sorprese saltano fuori nella prima mezz'ora.

• I dati sulle vulnerabilità del 2025, sulla velocità di sfruttamento, sui prodotti premium e sull'efficacia delle difese degli hosting provengono dal whitepaper Patchstack, State of WordPress Security in 2026.
• La ricostruzione dell'attacco alla catena di fornitura di aprile 2026 e l'elenco dei plugin coinvolti sono documentati nell'analisi pubblica dell'incidente.
• Sul fatto che WordPress non segnali all'utente i plugin chiusi o rimossi dal repository, il riferimento è all'approfondimento di Patchstack sulle implicazioni di sicurezza delle chiusure nel repository.