Oltre il 40% dei siti WordPress fa girare almeno un plugin obsoleto con una vulnerabilità nota. Non è una stima approssimativa: è un dato verificato regolarmente dai ricercatori di sicurezza WordPress. Se non ha aggiornato plugin o temi nelle ultime settimane, c'è una probabilità concreta che il Suo sito rientri in questa categoria.
Il rischio non è astratto. Quando una vulnerabilità viene corretta, il patch stesso rivela qual era il difetto. I ricercatori pubblicano i dettagli tecnici. Gli scanner automatizzati iniziano a sondare i siti vulnerabili nel giro di ore. Entro il terzo giorno, lo sfruttamento attivo è tipicamente in corso su larga scala.
Con quale rapidità vengono sfruttate le vulnerabilità
Il tempo che intercorre dalla divulgazione pubblica allo sfruttamento di massa si è ridotto significativamente. Nel 2023 la media era di circa 15 giorni. Nel 2025, le vulnerabilità principali nei plugin più diffusi vengono tipicamente sfruttate attivamente entro 24-72 ore dalla pubblicazione del patch.
| Fase | Tempistica tipica |
|---|---|
| Vulnerabilità scoperta dal ricercatore | Giorno 0 |
| Patch rilasciato dallo sviluppatore del plugin | Giorni 1-30 (se mai) |
| Dettagli tecnici pubblicati | Lo stesso giorno del patch |
| Codice exploit proof-of-concept pubblicato | 24-72 ore dopo il patch |
| Inizia la scansione massiva automatizzata | 24-72 ore dopo il patch |
| Il sito non aggiornato a rischio attivo | Dal giorno 3 in poi |
Il Suo sito può essere compromesso senza essere preso di mira specificamente. Gli attaccanti usano scanner automatizzati che sondano milioni di siti contemporaneamente, cercando firme di versione che indicano installazioni vulnerabili. Se il sito corrisponde, viene messo in coda per lo sfruttamento.
Vulnerabilità reali del 2024-2025
Non sono ipotesi. Sono vulnerabilità specifiche in plugin installati su milioni di siti WordPress, tutte pubblicamente documentate.
LiteSpeed Cache: 5 milioni di siti a rischio
Nell'agosto 2024 i ricercatori hanno divulgato CVE-2024-28000, una vulnerabilità critica nel plugin LiteSpeed Cache. Il difetto consentiva a un attaccante non autenticato di escalare i privilegi e creare account amministratore su qualsiasi sito interessato. LiteSpeed Cache è installato su oltre 5 milioni di siti WordPress. I siti rimasti senza patch per più di qualche giorno hanno regolarmente subito la creazione di account amministratore non autorizzati da parte di bot automatizzati nell'arco della stessa settimana, un pattern documentato nei resoconti degli incidenti di Wordfence e Patchstack.
Really Simple Security: 4 milioni di siti a rischio
Nel novembre 2024 è stato divulgato CVE-2024-10924 in Really Simple Security (precedentemente Really Simple SSL), un plugin installato su 4 milioni di siti. La vulnerabilità consentiva un bypass completo dell'autenticazione: un attaccante poteva accedere come qualsiasi utente, inclusi gli amministratori, senza conoscere la password. WordPress.org ha classificato questo come critico con un livello di gravità di 9,8/10. Tentativi di sfruttamento massiccio sono stati registrati entro 24 ore dalla divulgazione pubblica.
WP Automatic: SQL injection su larga scala
All'inizio del 2024 è stato scoperto CVE-2024-27956 in WP Automatic, un plugin usato da oltre 30.000 siti per la pubblicazione automatizzata di contenuti. La vulnerabilità SQL injection consentiva agli attaccanti di estrarre il contenuto del database e creare account amministratore. Nel giro di settimane dalla divulgazione, migliaia di siti erano stati compromessi e backdoor installate.
Cosa significa davvero "obsoleto"
Quando si pensa agli aggiornamenti WordPress, si pensa di solito alla versione del core. Ma la vera superficie di attacco è molto più ampia.
| Componente | Perché è importante | Rischio se obsoleto |
|---|---|---|
| WordPress core | Il fondamento, aggiornato regolarmente | Alto: gli exploit noti prendono di mira le versioni precedenti |
| Plugin | Il vettore di attacco principale: migliaia di plugin, qualità variabile | Critico: la maggior parte degli exploit prende di mira i plugin |
| Temi | Spesso contengono vulnerabilità, specialmente i temi premium dei marketplace | Medio-Alto |
| Versione PHP | Linguaggio lato server su cui gira WordPress | Alto: PHP 7.4 (EOL 2022) non riceve patch di sicurezza |
Una parte significativa dei siti WordPress gira ancora su PHP 7.x, una versione in end-of-life dal 2022 che non riceve più aggiornamenti di sicurezza. Le vulnerabilità in PHP stesso rimangono senza patch, creando una lacuna di sicurezza al di sotto di tutto il resto.
Il paradosso degli aggiornamenti
La risposta logica a tutto questo è: aggiornare tutto, immediatamente. Il problema è che gli aggiornamenti WordPress rompono spesso qualcosa.
I conflitti tra plugin dopo i principali aggiornamenti di versione di WordPress sono comuni. Un tema che funzionava perfettamente su WP 6.3 può avere problemi di visualizzazione su WP 6.5. Un aggiornamento del plugin di pagamento può interrompere il processo di checkout. La maggior parte dei titolari d'azienda ha vissuto almeno una situazione di sito non funzionante dopo un aggiornamento. Il risultato: gli aggiornamenti vengono rinviati finché non si riesce a testare, e le settimane diventano mesi.
Abilitare gli aggiornamenti automatici riduce la finestra di vulnerabilità ma introduce un rischio di malfunzionamenti imprevedibili. Molte aziende disabilitano gli aggiornamenti automatici dopo una brutta esperienza. Non esiste una soluzione netta nel modello WordPress.
Cosa fanno gli attaccanti con l'accesso
Una volta che un sito è compromesso, gli attaccanti tipicamente non lo distruggono immediatamente: questo rivelerebbe la violazione. Preferiscono un accesso silenzioso e persistente.
- Iniezione di spam SEO: Migliaia di link nascosti verso siti farmaceutici, di gioco d'azzardo o per adulti vengono aggiunti alle pagine. Il posizionamento su Google declina. Alla fine Google inserisce il dominio nella blacklist.
- Hack di reindirizzamento: I visitatori, ma non il titolare del sito, vengono silenziosamente reindirizzati verso siti malevoli. Il traffico organico scompare misteriosamente, perché il reindirizzamento prende di mira specifici pattern di traffico.
- Furto di dati dei clienti: I moduli inviati, i dettagli di contatto e tutti i dati utente memorizzati vengono esfiltrati.
- Pagine di phishing: False pagine di login vengono ospitate sul dominio e usate per raccogliere le credenziali dei visitatori.
- Installazione di backdoor: Una backdoor persistente viene lasciata in modo che gli attaccanti mantengano l'accesso anche dopo che la vulnerabilità originale è stata corretta.
La Sua responsabilità GDPR
Se il Suo sito raccoglie dati identificabili, come moduli di contatto, iscrizioni alla newsletter o account clienti, e quei dati vengono esposti a causa di una vulnerabilità nota e non corretta, si configura un problema con il GDPR.
L'articolo 32 del GDPR obbliga le organizzazioni a implementare misure tecniche adeguate per garantire la sicurezza dei dati. Fare girare software con vulnerabilità critiche pubblicamente documentate senza correggerle è una posizione difendibile solo se si riesce a dimostrare di non aver avuto una ragionevole opportunità di aggiornare. La riluttanza ad aggiornare non è generalmente accettata dalle autorità di protezione dei dati come difesa per le violazioni legate al trattamento dei dati.
Le sanzioni GDPR possono raggiungere 20 milioni di euro o il 4% del fatturato annuo globale, a seconda di quale importo sia più elevato. Anche le azioni di enforcement di portata intermedia sono materialmente significative per le PMI.
Perché il patching non è una strategia a lungo termine
Nel 2024 i ricercatori di sicurezza hanno divulgato circa 8.000 nuove vulnerabilità di plugin WordPress, più di 20 al giorno. Questo numero è cresciuto ogni anno.
Stare al passo richiede: monitorare gli avvisi di sicurezza per ogni plugin in uso, testare gli aggiornamenti in un ambiente di staging prima di applicarli in produzione, applicare i patch rapidamente (entro 24-72 ore per i problemi critici), gestire le interruzioni del sito quando gli aggiornamenti entrano in conflitto, e gestire la rimediazione d'emergenza quando qualcosa sfugge.
Questo è un onere di manutenzione continuo. Per un'azienda che vuole semplicemente un sito web che funzioni, questo overhead è un costo nascosto significativo del modello WordPress.
L'alternativa: eliminare la superficie di attacco
Un sito Next.js ha una superficie di attacco WordPress-specifica più ridotta, perché le classi di vulnerabilità di plugin e temi non esistono nella stessa forma.
- Nessun database esposto a internet: nessuna superficie di attacco SQL injection
- Nessuna esecuzione PHP lato server: nessuna vulnerabilità di esecuzione di codice PHP
- Nessun ecosistema di plugin da aggiornare: le dipendenze sono gestite esplicitamente, non prese da un marketplace di 60.000 opzioni
- Nessuna pagina di login wp-admin: un URL noto, universalmente preso di mira, che semplicemente non esiste
- Sicurezza a livello infrastrutturale: protezione DDoS, SSL e sicurezza edge gestiti da piattaforme come Vercel
Passare a un sito JavaScript statico o renderizzato lato server non azzera le considerazioni di sicurezza. Significa però che il team di manutenzione non corre ogni giorno contro le divulgazioni di nuove vulnerabilità in un ecosistema di plugin.
Verifichi la Sua esposizione attuale
Se sta usando WordPress, il primo passo è conoscere la situazione reale. L'audit gratuito controlla gli indicatori WordPress visibili, le intestazioni di risposta del server e le metriche di performance in 60 secondi.
Esegua l'audit su webvise.io/wp-health-report. Se i risultati mostrano software obsoleto o problemi di sicurezza, webvise è disponibile a discutere le opzioni realistiche: un processo disciplinato di aggiornamento e monitoraggio, oppure una migrazione verso un'architettura senza il tapis roulant degli aggiornamenti.
Le pratiche di webvise sono allineate agli standard ISO 27001 e ISO 42001.