M's Works

Parliamo su

Vulnerabilità WordPress: le 7 che troviamo più spesso negli audit (e come chiuderle)

Nel 2025 sono emerse oltre 11.000 nuove vulnerabilità WordPress, il 91% nei plugin. Le 7 che troviamo più spesso negli audit e come chiuderle.

Antonio Murabito9 minuti di lettura
Una finestra integra poggia su una fila di moduli e su una base piena: uno dei moduli è rosso

Il tuo sito funziona. Le pagine si caricano, gli ordini arrivano, il modulo contatti manda le email. Questo non vuol dire che sia sicuro.

Qualche settimana fa abbiamo fatto un audit su un e-commerce WordPress. Visto da fuori era tutto in ordine. Guardando meglio c'erano componenti con vulnerabilità sfruttabili senza nemmeno fare login, un'utenza amministrativa di un fornitore che non lavorava più con l'azienda da tempo e una versione di PHP vicina alla fine del supporto. Niente di esotico: è il quadro che troviamo quasi ogni volta.

WordPress gira sul 40% di tutti i siti web del mondo (dato W3Techs, ottobre 2026). È comodo per chi lo usa e conveniente per chi lo attacca: una falla in un plugin diffuso vale migliaia di bersagli in un colpo solo. E i numeri dell'ultimo anno dicono che il problema sta crescendo.

Vulnerabilità WordPress nel 2025: i numeri

Il report annuale di Patchstack sul 2025 mette in fila quattro numeri che dovrebbero togliere il sonno a chi gestisce un sito:

11.334

nuove vulnerabilità nell'ecosistema WordPress in un anno, il 42% in più rispetto al 2024

91%

si trovava nei plugin, il 9% nei temi; nel core solo 6, tutte di bassa priorità

46%

non aveva ancora una correzione disponibile quando è stata resa pubblica

5 ore

il tempo mediano tra la pubblicazione e lo sfruttamento di massa, per le falle più prese di mira

Cinque ore. Non il tempo di "ci penso lunedì".

Il messaggio è chiaro: WordPress in sé è solido. Il rischio sta in tutto quello che ci installi sopra e in come è configurato. Ecco le sette vulnerabilità che troviamo più spesso.

1. Plugin WordPress e temi non aggiornati

È il punto di partenza di quasi ogni attacco. Page builder, filtri prodotto, moduli di contatto, plugin SEO, il modulo del gateway di pagamento: sono componenti presenti in buona parte dei siti, e in ognuna di queste categorie negli ultimi anni sono uscite vulnerabilità gravi.

Il caso più frequente non è la pigrizia. È la licenza. Molti temi e plugin premium si aggiornano solo con una licenza attiva, e spesso quella licenza è scaduta, oppure è intestata all'agenzia che ha realizzato il sito anni fa. Risultato: il pannello non segnala nulla, il proprietario pensa di essere aggiornato e il componente resta fermo a una versione vulnerabile.

Non è un dettaglio. Secondo lo stesso report Patchstack, i componenti premium hanno generato il 29% delle segnalazioni e hanno avuto tre volte più vulnerabilità effettivamente sfruttate rispetto a quelli gratuiti.

Cosa fare: un inventario di tutti i plugin e temi, con versione installata, ultima versione disponibile e intestatario della licenza. Quelli inutilizzati vanno rimossi, non solo disattivati. E ogni aggiornamento va provato prima su una copia del sito, uno alla volta.

2. Utenze dimenticate e accessi deboli

Chi ha accesso amministrativo al tuo sito, oggi? Se la risposta è "credo io e l'agenzia", conviene controllare. Negli audit troviamo regolarmente account di ex fornitori, ex collaboratori, utenze di test mai cancellate. Ognuna è una porta aperta che nessuno sorveglia.

A peggiorare le cose, WordPress di default rende facile scoprire i nomi utente. Spesso basta visitare tuosito.it/?author=1 o interrogare l'API pubblica su /wp-json/wp/v2/users per ottenere gli username degli autori. A quel punto all'attaccante manca solo la password.

E per indovinarla ha spesso campo libero: nessun limite ai tentativi di accesso, nessun secondo fattore di autenticazione e l'interfaccia XML-RPC attiva. Quest'ultima è una seconda porta per provare le password, che spesso sfugge alle protezioni messe sulla pagina di login, ed è stata usata anche per attacchi di tipo pingback contro altri siti.

Cosa fare: revocare le utenze non più riferibili a qualcuno di attivo, bloccare l'enumerazione degli utenti, attivare il 2FA su tutti gli amministratori (non solo sul tuo), limitare i tentativi di accesso e disattivare XML-RPC se non serve a un'app o a un'integrazione.

3. Sicurezza WordPress: configurazione lasciata di default

Un'installazione WordPress "così come esce" non è pensata per essere blindata, è pensata per funzionare ovunque. Alcune impostazioni vanno sistemate a mano:

  • header di sicurezza HTTP assenti: nessuna protezione contro clickjacking, interpretazione errata dei contenuti, caricamento di risorse da domini non autorizzati;
  • file che rivelano le versioni: readme, changelog e meta tag che dicono a chiunque quale versione di WordPress e dei plugin stai usando, cioè quale vulnerabilità provare;
  • cron gestito dai visitatori: WordPress esegue le attività pianificate solo quando qualcuno visita il sito. Su un e-commerce significa email d'ordine e operazioni in coda che partono in ritardo, o non partono. Spostarlo sul cron del server lo rende affidabile, ma va fatto con attenzione perché tocca proprio quelle funzioni.

Ogni misura di hardening ha un possibile effetto collaterale. Una Content Security Policy scritta male, per esempio, può rompere il page builder o il checkout. Per questo va attivata, poi verificata dall'esterno, poi va rifatto un acquisto di prova.

4. Aggiornare PHP su WordPress: la scadenza ignorata

PHP è il linguaggio su cui gira WordPress, e ogni versione ha una data di fine supporto. Oggi PHP 8.1 e tutte le versioni precedenti non ricevono più correzioni di sicurezza. PHP 8.2 le riceverà solo fino al 31 dicembre 2026 (calendario ufficiale di PHP). Se il tuo sito gira su 8.2 o inferiore, tra meno di tre mesi sarà su una piattaforma che nessuno aggiorna più.

Il problema è che passare a PHP 8.4 raramente è un clic dal pannello dell'hosting. Temi personalizzati, temi figli, shortcode scritti su misura e plugin datati possono smettere di funzionare, o peggio funzionare a metà: la pagina si vede, il carrello no.

Cosa fare: un'analisi di compatibilità prima del cambio, una copia di staging con la nuova versione per confrontare il comportamento e un piano per tornare indietro in pochi minuti se qualcosa va storto. Se vuoi approfondire come lavoriamo sulle migrazioni, trovi tutto nella pagina Modernizzazione.

5. Backup mai provati

"Il backup ce l'abbiamo." Bene. L'avete mai ripristinato?

Un backup che non è mai stato ripristinato non è un backup, è una speranza. Troviamo backup incompleti (solo i file senza il database, o viceversa), salvati sullo stesso server che dovrebbero proteggere, o in formati che nessuno sa più rimettere in piedi.

Cosa fare: provare un ripristino completo su un ambiente separato, contare le righe delle tabelle critiche prima e dopo (utenti, ordini, prodotti), aprire un ordine reale e verificare che si legga correttamente. E misurare quanto tempo ci vuole: è il numero che ti servirà nel momento peggiore.

6. Sicurezza WooCommerce: ordini, chiavi e pagamenti

Su un e-commerce la posta in gioco sale. Tre controlli che facciamo sempre.

Riconciliazione degli ordini. Confrontare gli ordini segnati come pagati con i movimenti reali sul gateway di pagamento. Ordini pagati senza movimento, movimenti senza ordine o importi diversi sono un segnale da non ignorare: possono indicare un errore di configurazione, o qualcosa di peggio.

Rotazione delle chiavi. Chiavi API del gateway, token di integrazione, chiavi REST di WooCommerce: se sono le stesse da anni e sono passate per le mani di più fornitori, vanno cambiate.

Gli script sulla pagina di pagamento. Gli attacchi di tipo skimming (noti come Magecart) inseriscono codice JavaScript nelle pagine del checkout per rubare i dati inseriti dal cliente. Lo standard PCI DSS 4.0.1 chiede di inventariare e autorizzare ogni script presente sulle pagine di pagamento e di rilevarne le modifiche non autorizzate (requisiti 6.4.3 e 11.6.1, obbligatori dal 31 marzo 2025). Anche chi usa una pagina di pagamento ospitata dalla banca o un iframe deve confermare che il proprio sito non sia esposto ad attacchi tramite script. Pochi negozi online sanno di dover rispondere a questa domanda.

7. Il server sotto il sito

Puoi avere WordPress configurato alla perfezione e un server che lascia aperti porte, servizi e accessi. Su una VPS il sistema operativo, i servizi esposti, gli accessi SSH e i permessi sui file sono responsabilità di qualcuno. Spesso non è chiaro di chi.

Su un hosting condiviso il margine d'intervento è minore, ma restano da verificare la versione di PHP disponibile, i permessi delle cartelle e chi ha accesso al pannello di controllo.

Come lavoriamo in un audit di sicurezza WordPress

Un audit non è un antivirus e non è uno scanner automatico che sputa una lista di 200 avvisi. È un'analisi ragionata, in tre momenti.

Analisi esterna e non intrusiva. Guardiamo il sito come lo vedrebbe un attaccante, senza toccare nulla: componenti e versioni, utenze esposte, configurazione, header, pagina di pagamento.

Report con priorità. Ogni rilievo ha una gravità e una soluzione. Prima le vulnerabilità sfruttabili senza autenticazione, poi il resto. Così sai cosa va fatto subito e cosa può aspettare.

Interventi senza rischi per la produzione. Se decidi di procedere, nulla tocca il sito pubblicato senza essere passato da una copia di staging isolata. Gli aggiornamenti si fanno uno alla volta, con un test dopo ciascuno. E prima di ogni intervento c'è un piano di rollback provato, non solo scritto.

Il negozio resta aperto mentre lavoriamo. È questo il punto.

La conformità (cookie, privacy, consenso) è un capitolo a parte, di cui abbiamo parlato in GDPR e cookie 2026.

Domande frequenti

Basta installare un plugin di sicurezza?

No. Un plugin di sicurezza aiuta, ma non aggiorna un componente con la licenza scaduta, non revoca l'utenza di un ex fornitore e non migra PHP. È un tassello, non la soluzione.

Ogni quanto vanno aggiornati i plugin?

Appena esce una correzione di sicurezza, e comunque con un controllo almeno settimanale. Visti i tempi di sfruttamento, aspettare un mese è troppo. L'importante è avere una copia di staging dove provare l'aggiornamento prima di farlo sul sito vero.

Come capisco se il mio sito WordPress è vulnerabile?

Alcuni segnali si vedono anche da soli: plugin premium che da mesi non propongono aggiornamenti, utenti amministratori che non riconosci, una versione di PHP pari o inferiore alla 8.2. Ma la maggior parte delle vulnerabilità non dà sintomi finché qualcuno non le sfrutta.

Cos'è un audit di sicurezza WordPress?

È un'analisi di componenti, accessi, configurazione, server e, per gli e-commerce, del flusso di pagamento. Il risultato è un report che dice cosa è a rischio, quanto è grave e come si risolve.

La sicurezza non si aggiunge a un sito, si costruisce dentro. E un sito che "funziona" può continuare a farlo fino al giorno in cui smette, di solito nel momento peggiore. Per questo offriamo un check-up gratuito del tuo sito WordPress: un'analisi esterna e non intrusiva che ti dice se sei tra i siti di cui abbiamo parlato sopra. Se il quadro è pulito, meglio così. Se non lo è, sai da dove partire.

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

Argomentivulnerabilità WordPresssicurezza WordPressaudit di sicurezza

Commenti

Carico i commenti…

«Se l'opportunità non bussa, costruisciti una porta.»

Milton Berle