La sicurezza WordPress è quasi sempre un problema di plugin, non di WordPress. Nel corso del 2025 sono state pubblicate 11.334 nuove vulnerabilità nell'ecosistema: il 91% riguardava i plugin, il 9% i temi e appena sei il codice del CMS. Il dato arriva dal report annuale di Patchstack e ribalta la conversazione che si sente di solito in azienda, dove il sospetto cade sempre sulla piattaforma. La piattaforma, in questa storia, è la parte che funziona.
La cosa riguarda molte più imprese di quanto sembri. WordPress è ancora usato dal 40,7% di tutti i siti web e dal 58,9% di quelli con un CMS riconoscibile, secondo le rilevazioni di W3Techs aggiornate a settembre 2026. Se hai un sito aziendale, statisticamente è probabile che giri su WordPress. E che monti fra dieci e trenta plugin che nessuno ha più guardato da un anno.
Sicurezza WordPress: cosa dicono davvero i numeri del 2025
Le 11.334 vulnerabilità del 2025 sono il 42% in più rispetto all'anno precedente. Di queste, 1.966 — circa il 17% — sono state classificate ad alto rischio, cioè con probabilità concreta di finire in campagne di attacco automatizzate su larga scala. Il dato più scomodo è un altro: le vulnerabilità facilmente sfruttabili sono cresciute del 113% in un anno.
Tradotto per chi gestisce un'azienda: non stanno aumentando solo i bug, sta aumentando la quota di bug che un attaccante può usare subito, senza credenziali e senza competenze particolari. Inoltre le vulnerabilità nei componenti a pagamento si comportano peggio di quelle nei plugin gratuiti — il report registra tre volte più vulnerabilità già sfruttate attivamente nei componenti premium. Pagare una licenza, quindi, non è di per sé una garanzia di manutenzione.
Cinque ore: tanto dura il vantaggio di chi aggiorna in ritardo
Quando una vulnerabilità grave diventa pubblica, il tempo mediano prima del primo sfruttamento di massa è di cinque ore. Circa metà delle falle ad alto impatto viene attaccata entro ventiquattro ore dalla pubblicazione. Non c'è una finestra di grazia di qualche settimana: c'è mezza giornata lavorativa.
Peggio ancora, il 46% delle vulnerabilità non aveva una correzione disponibile al momento della divulgazione. Quasi una su due diventa quindi di dominio pubblico mentre il plugin è ancora scoperto. In quei casi aggiornare non basta, perché non c'è nulla da aggiornare: l'unica difesa è sapere che il componente è vulnerabile e disattivarlo finché non arriva la patch.
E il pacchetto sicurezza dell'hosting? Secondo lo stesso report, le difese generiche dei provider bloccano il 26% degli attacchi complessivi, ma scendono al 12% quando l'attacco sfrutta una vulnerabilità specifica di WordPress. È una rete di protezione, non un tetto. Chi ha comprato un hosting "sicuro" e ha smesso di occuparsi degli aggiornamenti sta di fatto coprendo un ottavo del problema: la sicurezza WordPress resta un lavoro di manutenzione, non un servizio che si attiva una volta.
Il plugin abbandonato è più pericoloso di quello vulnerabile
C'è poi una categoria di rischio che quasi nessuno controlla: i plugin rimossi dal repository ufficiale. Quando un plugin viene chiuso su WordPress.org — perché abbandonato, perché il team di sicurezza ha riscontrato un problema, perché lo sviluppatore ha smesso — il sito continua a funzionare esattamente come prima. Ma la catena degli aggiornamenti si interrompe in silenzio.
Un plugin abbandonato resta attivo e apparentemente sano: è il pezzo che nessuno controlla più.
Il dettaglio che rende la cosa insidiosa lo spiega bene l'analisi di Patchstack sulle chiusure dei plugin: WordPress continua a mostrare il componente come aggiornato, perché non esistono versioni nuove da segnalare. Il pannello dice tutto verde. Nel frattempo, se emerge una falla, la correzione va scaricata a mano dal sito dello sviluppatore — un passaggio che, nella pratica, quasi nessuno compie.
Non parliamo di software di nicchia. Fra i plugin che negli ultimi anni sono usciti temporaneamente dal repository ci sono nomi con milioni di installazioni attive. Il rischio, tuttavia, non è la chiusura in sé: è che nessuno in azienda se ne accorga per mesi.
Come si migliora la sicurezza WordPress in pratica
La documentazione ufficiale di WordPress è chiara sull'obiettivo: si tratta di "riduzione del rischio, non eliminazione del rischio". Le indicazioni della guida all'hardening sono meno esotiche di quello che vendono molti fornitori di sicurezza, e proprio per questo funzionano.
- Attiva gli aggiornamenti automatici dei plugin. Attenzione: non sono attivi per impostazione predefinita. WordPress aggiorna da solo le release minori del core e le traduzioni, ma per plugin e temi l'aggiornamento automatico scatta solo in casi eccezionali decisi dal team di sicurezza. Va abilitato a mano, plugin per plugin o in blocco.
- Cancella, non disattivare. Un plugin disattivato resta sul server e resta codice raggiungibile. La guida ufficiale è esplicita: i componenti inutilizzati vanno eliminati.
- Installa solo da fonti attendibili — repository ufficiale o aziende note. Un tema "premium" scaricato da un marketplace qualsiasi è la via più corta a una compromissione.
- Fai backup regolari e verificati, database compreso. Un backup che nessuno ha mai provato a ripristinare non è un backup, è una speranza.
- Tieni un inventario. Un foglio con plugin, versione, data dell'ultimo aggiornamento del produttore e a cosa serve. Serve a rispondere in dieci minuti alla domanda "siamo esposti a questa falla?".
Infine, un consiglio che vale più di qualsiasi strumento: riduci il numero di plugin. Ogni plugin è codice di terzi che gira con i permessi del tuo sito. Trenta plugin significano trenta fornitori di cui ti stai fidando, trenta cicli di rilascio da seguire, trenta possibili abbandoni.
La domanda che nessuno fa: quanto codice altrui ti serve davvero
Molti siti aziendali fanno sei cose: presentano l'azienda, elencano i servizi, raccolgono contatti, pubblicano un blog, tracciano qualche conversione, gestiscono il consenso ai cookie. Per farle vengono installati venticinque plugin, ciascuno progettato per risolvere il problema di chiunque, non il tuo. La superficie d'attacco cresce in modo proporzionale a funzioni che spesso non vengono nemmeno usate.
Non è un argomento contro WordPress. Per un e-commerce complesso, per una redazione con dieci autori, per chi ha bisogno di un ecosistema di integrazioni già pronte, WordPress resta una scelta razionale — a patto di trattare i plugin come fornitori, con una governance vera. Ne abbiamo parlato in modo più esteso confrontando CMS headless e WordPress.
Per un sito istituzionale, invece, la domanda va posta a monte. Il blog che stai leggendo, per esempio, gira su un sistema su misura in PHP con gli articoli su file JSON: nessun database, nessun plugin, nessuna dipendenza da aggiornare in fretta e furia alle sette di sera. Meno superficie significa meno manutenzione, e meno manutenzione significa che quella poca viene fatta davvero. Lo stesso ragionamento vale per gli altri obblighi che pesano su un sito aziendale, a partire dall'accessibilità.
La sicurezza WordPress, in fondo, non si compra: si progetta insieme al sito e si mantiene ogni mese. Se vuoi capire quanta superficie d'attacco hai accumulato senza accorgertene, parti dall'inventario dei plugin. Studiollice progetta siti e automazioni su misura, e quando serve aiuta le aziende a decidere cosa tenere e cosa smontare.