Il mio sito WordPress è stato violato: cosa fare, in 10 passi
Par AIFORYA — 26 luglio 2026 — 12 min de lecture
In questa pagina (15)
Se sta leggendo questa pagina in emergenza, cominci da qui: non cancelli nulla, non reinstalli nulla per ora. L'errore più costoso nella prima mezz'ora non è pulire male — è cancellare le tracce prima di aver capito da dove è entrato l'aggressore. Senza quell'informazione pulirà, e verrà reinfettato nei giorni successivi, quasi sempre dalla stessa porta.
Questa guida dà i dieci passi nell'ordine giusto, con che cosa verificare a ognuno. È scritta per chi gestisce il proprio sito senza essere un amministratore di sistema. Consideri due-quattro ore per un caso semplice; di più se il sito è grande o se l'hosting è condiviso e lento.
I segnali che l'hanno portata qui sono probabilmente uno di questi: il sito reindirizza i visitatori a una pagina sconosciuta, Google mostra «Questo sito potrebbe danneggiare il tuo computer», nei risultati di ricerca sono comparse pagine in lingua straniera, l'accesso all'amministrazione è negato, oppure il suo hosting ha sospeso l'account. Portano tutti allo stesso protocollo.
Sommario
- Passo 0: i primi cinque minuti
- Passo 1: salvare lo stato infetto
- Passo 2: chiudere l'accesso senza rompere tutto
- Passo 3: riprendere il controllo degli account
- Passo 4: chiudere tutte le sessioni aperte
- Passo 5: trovare che cosa è stato modificato
- Passo 6: cercare le porte di servizio
- Passo 7: pulire o ripristinare
- Passo 8: richiudere la porta d'ingresso
- Passo 9: far togliere l'avviso di Google
- Passo 10: l'obbligo che si dimentica — i dati personali
- Evitare la recidiva
Passo 0: i primi cinque minuti
Tre riflessi, in quest'ordine.
Non tocchi nulla dal computer che potrebbe essere compromesso. Se la sua postazione è infetta, cambiare le password da lì equivale a consegnarle all'aggressore. Usi un altro computer, o il telefono.
Non cancelli i registri. I registri di accesso del suo hosting (spesso 7-30 giorni di conservazione) sono l'unica cosa che le dirà da dove è entrato. Li richieda subito se il suo piano non glieli mostra: scadono.
Avvisi il suo hosting. Molti hanno un reparto dedicato e, soprattutto: se il suo server invia spam, la sospenderanno senza preavviso. Averli informati cambia la conversazione.
Passo 1: salvare lo stato infetto
Controintuitivo, eppure indispensabile. Faccia una copia completa — file e database — dello stato attuale, infetto, e la conservi fuori linea.
Tre ragioni: è la sua rete di sicurezza se la pulizia rompe il sito; è l'unica traccia utile per capire l'attacco; e se sono coinvolti dati personali, è ciò che le permetterà di documentare l'accaduto (vedi passo 10).
La nomini in modo chiaro, con la data e la parola «INFETTO», e non la ripristini mai per errore.
Passo 2: chiudere l'accesso senza rompere tutto
Se il sito serve reindirizzamenti o contenuti dannosi, ogni visitatore in più peggiora la sua situazione agli occhi di Google e dell'hosting.
Il gesto corretto è la pagina di manutenzione a livello di server, non la cancellazione del sito. Lei resta padrone dei contenuti, i visitatori vedono un messaggio onesto, e i motori ricevono un codice HTTP 503 (indisponibilità temporanea) che non distrugge il posizionamento — a differenza di un sito che risponde con errori per giorni.
Passo 3: riprendere il controllo degli account
Cambi tutte le password, da una macchina pulita, in quest'ordine: hosting, FTP/SFTP, database, account amministratore di WordPress, casella di posta collegata. Una sola dimenticanza basta a ricominciare da capo.
Poi apra l'elenco degli utenti di WordPress e cerchi ciò che non dovrebbe esserci: un amministratore che non riconosce, un account creato di recente, o un account esistente il cui ruolo è passato ad amministratore. Non li elimini subito — annoti prima indirizzo e-mail e data di iscrizione: è un'informazione utile per capire l'ingresso. Poi declassi o elimini.
Verifichi anche chiavi e token di accesso: chiavi API, password applicative, collegamenti a servizi di terzi. Sono i dimenticati classici di una pulizia, e restano validi dopo il cambio password.
Passo 4: chiudere tutte le sessioni aperte
Cambiare una password non disconnette chi è già collegato: il suo cookie di sessione resta valido. Un aggressore con una sessione aperta se la tiene.
La manovra consiste nel rigenerare le chiavi di sicurezza di WordPress (i «salt») nel file wp-config.php. WordPress mette a disposizione un generatore ufficiale per questi valori. Sostituendoli, invalida in un colpo solo tutte le sessioni esistenti, compresa la sua: dovrà riconnettersi, e anche l'aggressore — solo che lui non ha più la password.
Passo 5: trovare che cosa è stato modificato
L'obiettivo è separare ciò che è suo da ciò che è stato aggiunto.
Il cuore di WordPress è verificabile. I file del core hanno impronte ufficiali pubblicate dal progetto: ogni scostamento segnala un file modificato. La maggior parte degli strumenti di analisi fa questo confronto in automatico — è la verifica più affidabile di cui dispone, perché non si basa su un elenco di firme di virus ma su un riferimento esatto.
Dove guardare per primo: wp-config.php, il .htaccess della radice (e quelli nelle sottocartelle), index.php, la cartella wp-content/uploads — nessun file .php ha motivo di viverci — e la cartella wp-content/mu-plugins, che carica codice automaticamente senza comparire mai nell'elenco dei plugin.
L'ordinamento per data di modifica è il suo migliore alleato: elenchi i file modificati nei giorni precedenti l'incidente. Un file del tema modificato il giorno in cui è iniziato tutto, mentre lei non ha toccato nulla, le dà il punto di partenza.
Passo 6: cercare le porte di servizio
È il passo che si salta, ed è quello che spiega le reinfezioni.
Una porta di servizio è un pezzo di codice che permette di tornare anche dopo la pulizia. Sopravvive a un cambio di password e spesso a un aggiornamento. I posti abituali:
- Un plugin o un tema che non ha mai installato — guardi anche i temi disattivati, raramente ispezionati.
- Un'attività pianificata che reinstalla il codice dannoso. Elenchi le attività pianificate di WordPress e cerchi quelle il cui nome non corrisponde a nulla di noto.
- Un account amministratore discreto, creato diversi giorni prima dell'incidente visibile.
- Codice iniettato direttamente nel database, spesso nella tabella delle opzioni o negli articoli.
Finché la porta di servizio è lì, ogni pulizia è temporanea. Se non è sicuro, è il momento di rivolgersi a un professionista: non è un fallimento, è una valutazione di costo.
Passo 7: pulire o ripristinare
Due strade, e la scelta dipende da una sola domanda: ha un backup precedente all'infezione?
Se sì, lo ripristini — ma sappia che il ripristino da solo non basta mai. Rimette il sito com'era, con la falla che ha permesso l'ingresso. Bisogna ripristinare e poi applicare subito il passo 8, prima di rimettere il sito online. Un ripristino senza correzione è un conto alla rovescia.
Se no, la pulizia si fa a strati: sostituisca il cuore di WordPress con un archivio ufficiale fresco, reinstalli ogni plugin e ogni tema dalla fonte ufficiale invece di correggere i file uno per uno, e conservi a mano solo wp-content/uploads — dopo averlo ripulito da ogni file eseguibile.
Una parola sul backup, dato che è il perno di questo passo: un backup che non ha mai testato non è un backup, è un'intenzione. Il giorno dell'incidente è il momento peggiore per scoprire che era incompleto.
Passo 8: richiudere la porta d'ingresso
La pulizia tratta le conseguenze. Questo passo tratta la causa, ed è l'unico che impedisce la ripetizione.
- Aggiorni tutto: il core, i plugin, i temi e la versione di PHP. Una versione di PHP che non riceve più correzioni di sicurezza è una decisione, non una fatalità — il suo hosting quasi sempre permette di cambiarla.
- Elimini ciò che non serve. Ogni plugin disattivato e ogni tema inutilizzato restano codice presente sul disco, quindi sfruttabile. Un plugin disattivato non è un plugin assente.
- Verifichi i permessi degli utenti. Un redattore non ha bisogno di essere amministratore. La maggior parte delle compromissioni passa da un account che aveva più diritti del necessario.
Passo 9: far togliere l'avviso di Google
Se il suo sito è stato segnalato, la pulizia non basta: l'avviso resta finché non chiede un esame.
In Search Console, apra la sezione dedicata ai problemi di sicurezza. Indica il tipo di compromissione rilevata e spesso alcune URL di esempio — le usi per verificare di non aver dimenticato nulla. Poi chieda un esame descrivendo che cosa ha corretto: una richiesta precisa passa più in fretta di una vaga.
Consideri qualche giorno. Chieda l'esame solo quando è davvero pulito: un rifiuto allunga i tempi.
Ne approfitti per controllare i proprietari della sua proprietà Search Console: un aggressore che si aggiunge come proprietario mantiene visibilità sul suo sito molto tempo dopo la pulizia.
Passo 10: l'obbligo che si dimentica — i dati personali
Se il suo sito ospitava account clienti, ordini, moduli o una lista di iscritti, una violazione non è solo un incidente tecnico: è potenzialmente una violazione di dati personali.
In Europa il GDPR impone al titolare del trattamento di notificare l'autorità di controllo competente entro 72 ore da quando ne è venuto a conoscenza, salvo che sia improbabile che la violazione presenti un rischio per le persone interessate — e di informare direttamente gli interessati quando il rischio è elevato. Il termine decorre dal momento in cui ne viene a conoscenza, non da quando tutto è riparato.
Questo paragrafo non è un parere legale e non sostituisce il suo responsabile della protezione dei dati o il suo consulente. Ciò che conta: non archivi la questione come puramente tecnica senza porsi la domanda, e documenti ciò che ha constatato e fatto — è esattamente a questo che serve la copia dello stato infetto del passo 1.
Evitare la recidiva
Un sito pulito senza cambiare abitudini è un sito che verrà ripreso. Tre misure coprono la stragrande maggioranza dei casi reali, e non costano quasi nulla.
L'autenticazione a due fattori sugli account con privilegi. È la misura che rende inefficace il furto di password, che resta la via d'ingresso più banale.
La protezione della pagina di accesso. Limitazione dei tentativi, blocco dopo ripetuti fallimenti, sorveglianza degli indirizzi che insistono: gli attacchi automatizzati sono stupidi e massicci, e si fermano davanti a una porta che conta.
La sorveglianza dell'integrità dei file. È ciò che fa la differenza tra scoprire l'incidente da soli in poche ore e apprenderlo da un cliente o da un avviso di Google tre settimane dopo. Il costo di una violazione non è proporzionale alla sua gravità tecnica: è proporzionale al tempo in cui è passata inosservata.
I quattro errori che costano di più
- Cancellare tutto e ripartire da zero senza aver capito l'ingresso. Perde l'informazione, e la falla resta.
- Ripristinare un backup e rimettere subito online. La falla viene ripristinata con il resto.
- Cambiare le password senza invalidare le sessioni. L'aggressore resta collegato.
- Limitarsi a pulire ciò che si vede. I reindirizzamenti visibili sono il sintomo; la porta di servizio è la malattia.
FAQ
1. Quanto tempo serve per pulire un sito WordPress violato? Due-quattro ore per un caso semplice con un backup sano. Una giornata o più senza backup, o se l'infezione è vecchia e si è propagata nel database. La parte più lunga non è quasi mai la pulizia: è la ricerca della porta d'ingresso.
2. Posso semplicemente reinstallare WordPress sopra?
Sostituisce i file del core, il che è utile, ma non tocca né i plugin, né i temi, né il database, né i file depositati in uploads — dove si nasconde la maggior parte delle porte di servizio. È un passo, non una soluzione.
3. Il mio hosting dice che è colpa mia. È vero? Su un hosting condiviso l'origine può essere anche un sito vicino o una falla lato server. Detto questo, nella grande maggioranza dei casi osservati l'ingresso avviene da un componente obsoleto o da una password debole — cioè da qualcosa su cui lei ha il controllo. Chieda i registri di accesso: risolvono la questione meglio della discussione.
4. Devo avvisare i miei visitatori? Se dati personali possono essere stati esposti, la questione non è solo commerciale ma normativa: veda il passo 10. Al di fuori di questo caso, la trasparenza è quasi sempre meno costosa del silenzio scoperto più tardi.
5. Come faccio a sapere che è davvero finita? Tre segnali: i file del core corrispondono di nuovo alle impronte ufficiali, non resta alcuna attività pianificata sconosciuta, e nulla riappare dopo diversi giorni. È il terzo che conta di più — una reinfezione avviene di solito entro la settimana.
6. Può succedere di nuovo? Sì, se la causa non è stata trattata. No, nei fatti, se ha eseguito il passo 8 e attivato autenticazione a due fattori, protezione dell'accesso e sorveglianza dell'integrità. Gli attacchi automatizzati cercano bersagli facili; tirano dritto.
Per approfondire la prevenzione invece della riparazione, legga la nostra guida per mettere in sicurezza WordPress contro gli attacchi automatizzati.