Vulnerabilità WordPress: le 7 da controllare in un audit (e come chiuderle)

Nel 2025 sono state pubblicate 11.334 nuove vulnerabilità nell'ecosistema WordPress, il 42% in più dell'anno prima. Il conto è del report annuale di Patchstack: il 91% stava nei plugin, il 9% nei temi, e nel core ne sono state trovate 6, tutte di bassa priorità. Il 46% è diventato pubblico prima che esistesse una correzione, e per le falle più prese di mira fra la pubblicazione e lo sfruttamento di massa sono passate in mediana 5 ore.

WordPress fa girare il 39,6% dei siti web del mondo (W3Techs, dato del 22 ottobre 2026), quindi una falla in un plugin diffuso apre migliaia di siti in un colpo. Il core regge; il rischio sta in quello che ci si installa sopra e in come è configurato.

1. Plugin WordPress e temi non aggiornati

Spesso un plugin resta indietro per colpa della licenza. Molti temi e plugin premium scaricano gli aggiornamenti solo con una licenza attiva: se è scaduta, o è intestata all'agenzia che ha fatto il sito anni fa, la bacheca non segnala niente e il componente resta fermo a una versione vulnerabile. Sempre secondo Patchstack, i componenti premium e freemium hanno prodotto il 29% delle segnalazioni valide e hanno avuto tre volte più vulnerabilità sfruttate davvero di quelli gratuiti.

Fai un inventario con la versione installata di ogni plugin e tema, l'ultima disponibile e l'intestatario della licenza. Quelli che non usi vanno cancellati, non lasciati disattivati. Gli aggiornamenti provali su una copia del sito, uno alla volta: se qualcosa si rompe, sai quale è stato.

2. Utenze dimenticate e accessi deboli

Chi ha un accesso da amministratore al tuo sito, oggi? Gli account di ex fornitori ed ex collaboratori restano attivi finché qualcuno non li cancella. I nomi utente, poi, si scoprono in fretta: spesso basta aprire tuosito.it/?author=1 o leggere l'API pubblica su /wp-json/wp/v2/users. Se il sito non limita i tentativi di accesso e non chiede un secondo fattore, la password si può provare all'infinito, e XML-RPC (xmlrpc.php) offre un secondo ingresso che spesso sfugge alle protezioni messe sulla pagina di login.

Togli le utenze di chi non lavora più con te, blocca l'enumerazione degli utenti e attiva il 2FA per tutti gli amministratori, non solo per te. Poi limita i tentativi e spegni XML-RPC, a meno che non lo usi un'app o un'integrazione.

3. Sicurezza WordPress: configurazione di default

WordPress appena installato è fatto per funzionare su qualunque hosting, e alcune cose vanno chiuse a mano. Mancano gli header di sicurezza HTTP, che proteggono dal clickjacking e dicono al browser da quali domini può caricare script. Readme, changelog e meta tag generator raccontano a chiunque quale versione di WordPress e dei plugin stai usando, cioè quale falla provare.

WordPress esegue le attività pianificate solo quando qualcuno visita il sito: su un e-commerce vuol dire email d'ordine e operazioni in coda che partono in ritardo, o non partono. La documentazione ufficiale spiega come spegnerlo con define( 'DISABLE_WP_CRON', true ); in wp-config.php e far chiamare wp-cron.php dal cron del server. Dopo il cambio rifai un acquisto di prova, come dopo ogni intervento di hardening: basta una Content Security Policy scritta male per bloccare il checkout.

4. Aggiornare PHP su WordPress: la scadenza ignorata

PHP 8.1 e le versioni precedenti non ricevono più correzioni di sicurezza, e PHP 8.2 le riceve fino al 31 dicembre 2026 (calendario ufficiale di PHP). Cosa succede dal 1° gennaio e a quale versione passare l'abbiamo spiegato in PHP 8.2 senza correzioni di sicurezza dal 1° gennaio.

Passare a PHP 8.4 raramente è un clic nel pannello dell'hosting. Temi su misura, shortcode scritti a mano e plugin vecchi possono smettere di funzionare, o funzionare a metà: la pagina si vede, il carrello no. Prima serve un'analisi di compatibilità, poi una prova della nuova versione su una copia di staging, con un modo per tornare indietro in pochi minuti.

5. Backup mai provati

Un backup mai ripristinato può contenere i file senza il database, o stare sullo stesso server che dovrebbe proteggere. La prova si fa su un ambiente separato: ripristino completo, conteggio delle righe di utenti, ordini e prodotti prima e dopo, un ordine vero aperto per vedere se si legge. Cronometra quanto ci vuole, perché è il tempo in cui il sito resterà fermo se un giorno va giù.

6. Sicurezza WooCommerce: ordini, chiavi e pagamenti

In un negozio online confronta gli ordini segnati come pagati con i movimenti sul gateway: un ordine pagato senza movimento, o con un importo diverso, può essere un errore di configurazione o qualcosa di peggio. Le chiavi del gateway e quelle REST di WooCommerce, se sono le stesse da anni e sono passate per più fornitori, si cambiano.

Gli attacchi di skimming, noti come Magecart, inseriscono JavaScript nel checkout per copiare i dati che il cliente digita. Per questo i requisiti 6.4.3 e 11.6.1 di PCI DSS chiedono che gli script della pagina di pagamento siano autorizzati, verificati e sorvegliati contro le modifiche, e sono obbligatori dal 31 marzo 2025. Chi usa la pagina di pagamento della banca o un iframe non ne è fuori: per il questionario semplificato SAQ A deve confermare che il proprio sito non sia esposto ad attacchi tramite script (le FAQ di Report URI lo spiegano in parole semplici).

7. Il server sotto il sito

Con una VPS il sistema operativo, i servizi esposti, gli accessi SSH e i permessi dei file sono responsabilità di qualcuno, e spesso non è scritto di chi. Con un hosting condiviso si può fare meno, ma la versione di PHP e chi entra nel pannello di controllo vanno verificati comunque.

Come lavoriamo in un audit di sicurezza WordPress

Cominciamo da fuori, senza toccare niente: guardiamo il sito come lo vedrebbe un attaccante. Nel report ogni rilievo ha una gravità e una soluzione, e in cima ci sono le falle sfruttabili senza login. Se si va avanti, sul sito pubblicato non arriva niente che non sia passato da una copia di staging isolata, gli aggiornamenti si fanno uno alla volta con un test dopo ciascuno e il ritorno indietro lo proviamo prima di cominciare. Il negozio intanto continua a vendere.

Domande frequenti

Basta installare un plugin di sicurezza?

Aiuta a limitare i tentativi di accesso e a vedere cosa succede, ma non aggiorna un plugin con la licenza scaduta e non cancella l'utenza di un ex fornitore.

Ogni quanto vanno aggiornati i plugin?

Appena esce una correzione di sicurezza, e comunque con un controllo ogni settimana: con i tempi di sfruttamento visti all'inizio, un mese è troppo.

Se vuoi sapere com'è messo il tuo sito su questi sette punti, scrivici: facciamo un check-up gratuito dall'esterno, senza toccare niente, e ti diciamo da dove partire.

Richiedi il check-up gratuito · Scopri il servizio di Security Audit