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. Con trenta plugin attivi, quelle finestre si sovrappongono quasi di continuo.

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: modalità manutenzione o blocco del traffico, senza cancellare nulla. I file compromessi sono anche le prove.
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. Valutare gli obblighi GDPR se ci sono dati personali coinvolti.

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 e permessi dei file corretti, così un account compromesso non può riscrivere il codice dal pannello;
• 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.

Cosa cambia con un sito statico

Un sito generato in anticipo e servito da una CDN, come quelli che costruisco con Nuxt 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. Sono tre account, con autenticazione a due fattori, al posto di decine di componenti da aggiornare. E ogni modifica al sito passa da un commit tracciato, quindi una modifica non autorizzata si vede e si annulla in un minuto.

Come la vedo io

Amo WordPress, ma oggi è il bersaglio più attaccato del web proprio perché è ovunque, e il modo in cui viene usato (decine di plugin, temi che fanno tutto) moltiplica le porte d'ingresso. 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 componente trascurato per cadere.

Quando un progetto ha davvero bisogno di WordPress, lo tengo asciutto e lo seguo con una procedura. Quando non ne ha bisogno, propongo di passare a un'architettura statica: è la misura di sicurezza più efficace che conosco.

Perché affidarlo a me

Programmo dal 1999, ho consegnato più di 300 progetti e lavoro come sviluppatore esterno con circa 30 agenzie, da Roma e da remoto. 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.