Plugin WordPress vulnerabili: verificare, aggiornare, sostituire

Il punto debole di un sito WordPress raramente è WordPress stesso. Gestire le vulnerabilità dei plugin WordPress si riduce a quattro abitudini: sapere esattamente che cosa è installato, aggiornare in fretta, eliminare ciò che non serve e sostituire ciò che nessuno mantiene più.

Questa guida spiega come consolidare ciascuna abitudine, come riconoscere i plugin abbandonati e che cosa fare nel caso scomodo in cui una vulnerabilità è pubblica ma una correzione non esiste ancora. È una delle voci della nostra checklist per la sicurezza di WordPress e, per la maggior parte dei siti, quella che conta di più.

Che cosa dicono i numeri sulle vulnerabilità dei plugin WordPress

I dati annuali più dettagliati arrivano dal rapporto di Patchstack State of WordPress Security in 2026, che copre il 2025. Patchstack è un'azienda di sicurezza che vende protezione proprio contro questi rischi: il rapporto va letto come una fonte ben informata, non come una statistica ufficiale. I risultati principali:

• 11.334 nuove vulnerabilità nell'ecosistema WordPress nel 2025, il 42% in più rispetto al 2024.
• Il 91% riguardava i plugin e il 9% i temi. Il core di WordPress ne ha avute sei, tutte a bassa priorità.
• Il 17% (1.966) era ad alta gravità e probabilmente destinato ad attacchi automatizzati di massa.
• Per il 46% lo sviluppatore non aveva ancora reso disponibile una correzione al momento della divulgazione pubblica.
• Il controllo degli accessi difettoso (broken access control) è stata la categoria più sfruttata.

In altre parole, l'elenco dei plugin è la superficie di attacco del sito. Ogni plugin è codice scritto da un altro team, a cui si affidano il sito e i dati che contiene.

Perché la velocità di aggiornamento conta

Chi attacca non sceglie i siti uno per uno. Scansiona Internet alla ricerca di una versione vulnerabile di un plugin e sfrutta automaticamente ogni sito che trova. Secondo lo stesso rapporto, per le vulnerabilità più sfruttate il tempo mediano ponderato fino allo sfruttamento di massa è stato di cinque ore, e circa la metà delle vulnerabilità ad alto impatto è stata sfruttata entro 24 ore.

Per questi casi una finestra di manutenzione mensile è troppo lenta: le release di sicurezza hanno bisogno di una corsia più veloce rispetto agli aggiornamenti funzionali. Applicare le patch con tempestività rientra anche tra le misure di sicurezza «adeguate» richieste dall'articolo 32 del GDPR, il Regolamento generale sulla protezione dei dati, e la direttiva NIS2 include la gestione delle vulnerabilità tra le misure minime (art. 21, paragrafo 2, lettera e) per le organizzazioni che rientrano nel suo ambito.

Passaggio 1: tenere un inventario dei plugin

Non si può aggiornare né valutare ciò che non si conosce. Un semplice inventario per ogni sito, anche un foglio di calcolo, dovrebbe riportare:

• nome, slug e versione installata del plugin
• provenienza: WordPress.org, un fornitore commerciale o codice personalizzato
• perché è installato e chi lo ha richiesto
• stato della licenza e data di rinnovo, per i plugin premium
• se gli aggiornamenti automatici sono attivi

Con WP-CLI la maggior parte di queste informazioni si esporta con un solo comando:

wp plugin list --fields=name,status,version,update_version,auto_update

Le versioni recenti di WP-CLI mostrano anche che cosa sa WordPress.org di ciascun plugin, compreso se è stato chiuso:

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

I plugin non ospitati su WordPress.org di solito qui mostrano valori vuoti: per questi conviene informarsi presso il fornitore. Lo stesso vale per i temi, con wp theme list.

Passaggio 2: eliminare i plugin che non si usano

Disattivare un plugin impedisce a WordPress di caricarlo, ma i suoi file restano sul server. Alcune vulnerabilità si possono sfruttare richiamando direttamente i file del plugin, e i plugin inattivi tendono a uscire dalle routine di aggiornamento. Lo stesso strumento Salute del sito di WordPress (Strumenti → Salute del sito) avverte che i plugin inattivi sono bersagli allettanti per chi attacca.

Quando un plugin non serve più, fare un backup, poi disattivarlo ed eliminarlo dalla schermata Plugin. Da riga di comando:

wp plugin uninstall old-slider --deactivate

wp plugin uninstall esegue la routine di disinstallazione del plugin, che può rimuovere anche impostazioni e dati dal database, e poi cancella i file. wp plugin delete rimuove soltanto i file. Ciò che serve ancora va esportato prima.

Candidati tipici: plugin di prova rimasti da un progetto, funzioni doppie (due plugin di cache o di SEO), strumenti di migrazione usati una sola volta e plugin che svolgono funzioni ormai integrate nel core di WordPress.

Passaggio 3: sostituire i plugin abbandonati e quelli nulled

Un plugin senza un manutentore attivo non riceverà alcuna correzione quando verrà scoperta la prossima vulnerabilità.

Segnali che un plugin è stato abbandonato

• Nessun aggiornamento recente. Controllare la data dell'ultimo aggiornamento («Last updated») nella pagina del plugin su WordPress.org. WordPress.org mostra anche un avviso quando un plugin non è stato testato con le ultime 3 versioni principali di WordPress.
• Chiuso su WordPress.org. Un avviso rosso indica che il plugin è stato chiuso e non è più disponibile per il download. Dopo 60 giorni viene aggiunto il motivo, e «Security Issue» (problema di sicurezza) è uno di quelli possibili. Qualunque sia il motivo, finché un plugin resta chiuso non arriva nessun aggiornamento tramite WordPress.org.
• Discussioni di supporto senza risposta, soprattutto quelle che segnalano problemi di sicurezza.
• Plugin premium il cui fornitore è sparito: nessuna nuova voce nel changelog, rinnovi di licenza che non funzionano, nessuna risposta dal supporto.

La documentazione di WordPress.org su avvisi e segnalazioni spiega questi messaggi. Quando compaiono, conviene pianificare la sostituzione prima che sia un'emergenza a imporla.

Mai usare plugin nulled

I plugin «nulled» sono copie piratate di plugin premium da cui è stato rimosso il controllo della licenza. Il codice è stato modificato da terzi sconosciuti e nessuno può sapere che cos'altro sia stato cambiato. Le backdoor nascoste sono un problema ben noto di queste copie. Inoltre non ricevono mai aggiornamenti né supporto, quindi non si possono correggere quando emerge la vulnerabilità successiva.

Se se ne trova uno su un sito, va sostituito con una copia regolarmente licenziata e il sito va considerato potenzialmente compromesso.

Passaggio 4: aggiornare in fretta, con aggiornamenti automatici o staging

Da WordPress 5.5 gli aggiornamenti automatici si possono attivare plugin per plugin, nella colonna «Aggiornamenti automatici» della schermata Plugin. Per impostazione predefinita WordPress li esegue due volte al giorno e invia l'esito via email (documentazione di WordPress.org). Con WP-CLI: wp plugin auto-updates enable --all.

Vista la rapidità con cui arrivano gli attacchi, gli aggiornamenti automatici sono la scelta predefinita giusta per la maggior parte dei plugin. Lo staging ha comunque senso dove un aggiornamento difettoso costa denaro vero:

Qualunque sia la scelta, servono backup che siano stati effettivamente ripristinati almeno una volta, e qualcuno deve leggere le email sugli aggiornamenti.

Passaggio 5: monitorare le vulnerabilità e intervenire

Dove cercare le vulnerabilità dei plugin

• Il changelog nella pagina del plugin su WordPress.org o sul sito del fornitore. Cercare voci come «security fix», tenendo conto che alcuni fornitori descrivono le correzioni in modo vago.
• Database pubblici di vulnerabilità come quelli di WPScan e Patchstack, consultabili per nome del plugin. Entrambi sono gestiti da aziende che vendono anche servizi di sicurezza.
• Bollettini e newsletter dei fornitori per i plugin premium.

Controllare a mano decine di plugin non è sostenibile. Security Audit & Compliance, il plugin di audit di secaudit.eu, segnala già nella configurazione di base plugin, temi e core non aggiornati. Attivando il controllo delle vulnerabilità, confronta anche le versioni installate con il database gratuito delle vulnerabilità di secaudit.eu, generato ogni notte dalla lista ufficiale dei CVE; l’elenco dei plugin non lascia mai il sito.

Cosa fare quando la correzione non esiste ancora

Quasi la metà delle vulnerabilità (46%) non aveva una correzione al momento della divulgazione. Se una di queste riguarda un plugin in uso:

1. Valutare l'esposizione. La funzione vulnerabile è raggiungibile da visitatori anonimi o solo da amministratori collegati?
2. Disattivare il plugin se se ne può fare a meno per un po', ed eliminarlo se la correzione non arriva.
3. Sostituirlo con un'alternativa mantenuta se il fornitore non dà segni di vita.
4. Ricorrere al virtual patching se il plugin è indispensabile: alcuni web application firewall (WAF) e servizi di sicurezza forniscono regole che bloccano le richieste corrispondenti all'exploit noto. Così si guadagna tempo, ma il codice resta da correggere.
5. Verificare se il sito è stato compromesso, soprattutto se la falla era pubblica da tempo prima che ce ne si accorgesse. Il nostro elenco dei segnali di un sito WordPress hackerato è un buon punto di partenza.

Per chi vende plugin: il Cyber Resilience Act

Per i fornitori la gestione delle vulnerabilità sta diventando un obbligo di legge, e una parte è già in vigore. Un plugin o un tema a pagamento venduto a clienti nell'UE è un «prodotto con elementi digitali» ai sensi del Cyber Resilience Act (CRA), e chi lo vende ne è il fabbricante. Dall'11 settembre 2026 i fabbricanti devono segnalare le vulnerabilità attivamente sfruttate nei propri prodotti tramite la piattaforma unica di segnalazione dell'ENISA: un preallarme entro 24 ore, una notifica entro 72 ore e una relazione finale entro 14 giorni dalla disponibilità di una misura correttiva.

Dall'11 dicembre 2027 si aggiungono gli obblighi principali, tra cui gli aggiornamenti di sicurezza per tutto il periodo di assistenza, un processo di gestione delle vulnerabilità, una politica di divulgazione coordinata e una distinta base del software (SBOM). I plugin open source gratuiti e non monetizzati restano in genere esclusi da questo regime dei fabbricanti. I dettagli sono nella nostra guida al Cyber Resilience Act per chi vende plugin.

Domande frequenti

Un plugin disattivato è sicuro?

No. I suoi file restano sul server e possono ancora contenere codice sfruttabile. I plugin che non si usano vanno eliminati.

Conviene attivare gli aggiornamenti automatici per tutti i plugin?

Per la maggior parte dei plugin sì, insieme a backup affidabili. I plugin critici per l'attività vanno prima testati in staging, ma il ritardo deve restare breve.

E se un plugin indispensabile è stato chiuso su WordPress.org?

Va considerato non più mantenuto finché non viene riaperto con una versione corretta, e conviene cominciare subito a cercare un'alternativa.

Questo articolo ha carattere informativo generale e non costituisce consulenza legale.