Sito WordPress hackerato: superficie d'attacco, risposta all'incidente e cosa cambia davvero

La maggior parte dei siti WordPress compromessi che ho visto non è stata scelta da qualcuno. È stata trovata da uno scanner. Gli attacchi a WordPress sono quasi sempre automatici: bot che provano in massa una vulnerabilità appena pubblicata su un plugin diffuso, o credenziali rubate altrove. Capire questo cambia il modo in cui si risponde e, soprattutto, il modo in cui si previene.

Da dove si entra

Il core di WordPress è maturo e aggiornato con rapidità. Il rischio sta quasi sempre altrove.

• Plugin e temi vulnerabili: la gran parte delle vulnerabilità segnalate nell'ecosistema riguarda componenti di terze parti. Upload di file non controllati, endpoint AJAX o REST senza verifica dei permessi, SQL injection in filtri di ricerca, escalation di privilegi da utente registrato ad amministratore.
• Componenti abbandonati: plugin rimossi dal repository ufficiale ma ancora attivi su migliaia di siti. Nessuno pubblicherà mai la correzione.
• Temi e plugin «nulled»: copie piratate di prodotti commerciali, spesso distribuite con una backdoor già inclusa.
• Credenziali: password riutilizzate, account amministratore condivisi, nessun secondo fattore. wp-login.php e xmlrpc.php sono martellati di continuo.
• Hosting: permessi dei file troppo larghi, versioni di PHP non più supportate, più siti sotto lo stesso utente di sistema, per cui la compromissione di uno contamina gli altri.

Il punto chiave è la finestra di esposizione: tra la pubblicazione di una vulnerabilità e l'aggiornamento effettivo del sito passano ore, giorni o settimane. Gli scanner automatici iniziano a sfruttarla in fretta. La priorità dipende dall’esposizione reale, dai privilegi necessari all’attacco e dalla disponibilità di una correzione o mitigazione.

Riconoscere la compromissione

I segnali visibili (redirect verso altri siti, pagine spam indicizzate, avvisi di Google Safe Browsing) arrivano tardi. Quelli tecnici arrivano prima:

• utenti amministratori sconosciuti in wp_users, o capability modificate in wp_usermeta;
• file PHP in wp-content/uploads, che non dovrebbe contenerne;
• file del core che non corrispondono ai checksum ufficiali (si verificano con WP-CLI);
• must-use plugins o drop-in che nessuno ha installato;
• opzioni in wp_options con codice offuscato, cron job sconosciuti;
• picchi di richieste POST anomale nei log del server.

Spam iniettato solo per Googlebot (cloaking) è un classico: il sito sembra normale a chi lo visita, ma Search Console mostra pagine in lingue o argomenti che non ti appartengono.

La risposta all'incidente, in ordine

1. Contenere e avviare la valutazione privacy: isolare l’ambiente, preservare file e log e informare subito il titolare. Una pagina di manutenzione non blocca necessariamente endpoint, cron o traffico in uscita. Se sono coinvolti dati personali si valutano immediatamente gli obblighi di notifica, senza attendere la fine della pulizia.
2. Fotografare: copia completa di file, database e log così come sono. Serve a capire cosa è successo e da quando.
3. Ruotare tutte le credenziali: amministratori WordPress, database, FTP/SFTP, pannello hosting, chiavi API salvate nel sito. Rigenerare salt e chiavi in wp-config.php per invalidare le sessioni attive.
4. Trovare il vettore: confrontare le date di modifica dei file con i log di accesso, controllare quali componenti avevano vulnerabilità note nel periodo. Senza questo passaggio, la pulizia è temporanea.
5. Ricostruire, non ripulire: core, temi e plugin si reinstallano da fonti ufficiali, mai «ripuliti» a mano. Il database si esamina tabella per tabella. Gli upload si filtrano per tipo di file.
6. Chiudere la falla: aggiornare o eliminare il componente vulnerabile. Se è abbandonato, sostituirlo.
7. Rimettere online e chiedere la revisione in Search Console se il sito è stato segnalato.
8. Documentare l’incidente e completare gli adempimenti privacy, avviati già durante il contenimento, se sono coinvolti dati personali.

Il backup è utile soprattutto in questa fase: non per tornare indietro alla cieca, ma per confrontare uno stato sano con quello compromesso.

Prevenire: meno componenti, non più strati

La risposta istintiva a un attacco è aggiungere un plugin di sicurezza. Aiuta su alcuni fronti, ma è codice in più dentro la stessa applicazione da proteggere. Le misure che contano davvero sono strutturali:

• ridurre i plugin a quelli indispensabili, scelti per manutenzione attiva e storico delle vulnerabilità;
• aggiornamenti tempestivi e provati su un ambiente di staging, con una procedura e non «quando capita»;
• autenticazione a due fattori per tutti gli amministratori, ruoli minimi per gli altri;
• DISALLOW_FILE_EDIT per disabilitare gli editor integrati, insieme a permessi dei file e ruoli minimi. Non impedisce da solo l’installazione di plugin o altre modifiche consentite a un amministratore;
• nessun PHP eseguibile negli upload, a livello di server;
• un WAF davanti al sito, che blocchi gli exploit noti prima che arrivino a WordPress;
• monitoraggio dell'integrità dei file e avvisi sui nuovi amministratori.

Il dettaglio di come imposto questo lavoro nel tempo è in Manutenzione WordPress: il costo reale nel tempo.

Una porta aperta che nessuno usa

Il pannello di WordPress è una porta sempre aperta sul web: chiunque può bussare a wp-login.php, e i bot lo fanno tutto il giorno. Va benissimo se dentro entra davvero qualcuno ogni giorno. Ma nella mia esperienza quasi tutti i clienti chiedono il pannello «per poter modificare il sito», e pochissimi poi lo usano davvero: un testo cambiato ogni tanto, una news ogni qualche mese. Per quella manciata di accessi si mantiene in piedi un database necessario al funzionamento dell’applicazione, PHP eseguito a ogni richiesta e decine di componenti da aggiornare. È una porta lasciata aperta per un ospite che non arriva mai.

Un sito generato in anticipo e servito da una CDN, come quelli che costruisco con Nuxt.js e Netlify, non esegue codice lato server a ogni visita, non espone un database e non ha un pannello di login pubblico. La classe di attacchi più comune contro WordPress semplicemente non ha un bersaglio. La superficie si sposta: restano da proteggere l'account GitHub, quello del provider di hosting e il registrar del dominio, tre account con autenticazione a due fattori al posto di decine di componenti. E ogni modifica passa da un commit tracciato, favorendo l’analisi e il ripristino. Questo richiede repository, permessi e pipeline protetti: la tracciabilità non impedisce da sola una compromissione.

Credenziali e ricostruzione dell’ambiente

Le credenziali esposte vanno revocate da un dispositivo e da un canale affidabili, evitando di introdurre nuove chiavi nel sistema ancora compromesso. Dopo la ricostruzione verifico nuovamente sessioni, token, accessi al provider e privilegi degli account, completando la rotazione necessaria nel nuovo ambiente.

Una modalità manutenzione nell’applicazione non equivale all’isolamento del server. Il contenimento deve considerare endpoint ancora raggiungibili, processi pianificati, altri siti sotto lo stesso utente e connessioni in uscita. Registro le azioni e conservo copie protette delle evidenze, senza includere segreti nei resoconti.

La valutazione privacy procede in parallelo: il termine per l’eventuale notifica decorre dalla conoscenza della violazione dei dati personali, non dalla fine dell’indagine. Il titolare documenta anche la decisione motivata di non notificare, quando ne ricorrono le condizioni.

Riferimento: GDPR, articoli 33 e 34.

Come la vedo io

Ho sviluppato con WordPress per molti anni e lo amo ancora. Ma oggi, per un progetto nuovo, la prima domanda che faccio non è più «quale tema?», è «chi entrerà nel pannello, e ogni quanto?». Se la risposta è «un redattore tutti i giorni», WordPress resta una scelta sensata, tenuto asciutto e seguito con una procedura. Se la risposta è «forse qualche volta l'anno», lasciare la porta aperta per precauzione è il rischio che evito: il sito va in Markdown o in un CMS esterno, e si riducono alcuni vettori d’attacco, mentre restano da proteggere dipendenze, account, pipeline e servizi esterni.

Non è una crociata contro WordPress: ho ripulito abbastanza siti da sapere che il problema raramente è un errore di chi li gestisce, è un'architettura in cui tutto è legato a tutto e basta un plugin trascurato per cadere. Per chi ci resta, la parte di manutenzione conta più di qualsiasi plugin di sicurezza; per chi non ha bisogno del pannello, passare a un'architettura statica è la misura di sicurezza più efficace che conosco.

Perché affidarlo a me

Dal 1999 ho consegnato più di 300 progetti e collaboro con più di 30 agenzie, da Roma e da remoto, e ho ripulito abbastanza siti compromessi da sapere dove si entra. Gestisco incidenti su WordPress con metodo: contenimento, analisi del vettore, ricostruzione pulita, e poi un piano perché non si ripeta.

Se il tuo sito è stato compromesso, o temi che lo sia, scrivimi: prima capiamo da dove sono entrati, poi decidiamo come rimetterlo in piedi. Il servizio è in Manutenzione WordPress.