Rimuovere un malware da WordPress è la parte facile. La parte difficile è farlo senza distruggere le uniche prove di cosa è successo, senza lasciare in piedi la porta da cui sono entrati, e senza accorgersi tre settimane dopo che quell’infezione era anche una violazione di dati personali che andava valutata entro 72 ore. Quasi tutte le guide italiane su questo tema si fermano al primo punto: installa un plugin, lancia una scansione, cancella i file rossi, cambia le password. Funziona, a volte. Poi il sito torna infetto e nessuno sa dire perché, perché nessuno ha guardato prima di pulire. Questa guida racconta la sequenza corretta, nell’ordine corretto, con le implicazioni che nessuno mette per iscritto.
Cosa significa davvero “il sito ha un malware”
Nel linguaggio comune si dice malware, ma su un sito WordPress quella parola copre situazioni molto diverse fra loro, che richiedono risposte diverse. Può trattarsi di codice iniettato nei file PHP del tema o del core, che serve pagine diverse a Google rispetto a quelle che vedi tu. Può essere spam farmaceutico o di scommesse nascosto nel database e visibile solo al crawler. Può essere una redirect condizionale che manda altrove solo il traffico proveniente da mobile o da ricerca organica, lasciando il sito perfettamente normale quando lo apri dal tuo browser. Può essere una webshell, cioè un file che dà al malintenzionato accesso continuo al server anche dopo che hai cambiato tutte le password. E può essere un utente amministratore fantasma creato tre mesi fa, che dorme e aspetta.
Google, nella sua documentazione ufficiale, distingue fra malware vero e proprio e software indesiderato, e segnala entrambi nel rapporto Problemi di sicurezza di Search Console, come spiegato nelle linee guida di Google Search Central sul malware. La distinzione conta perché determina cosa vede l’utente: un avviso rosso a schermo pieno prima di entrare, oppure una riga di testo sotto il risultato di ricerca. Nel primo caso il traffico si azzera nel giro di ore.
Vale la pena dire subito la cosa scomoda: nella stragrande maggioranza dei casi il tuo sito non è stato preso di mira. È stato trovato. Esistono scanner automatici che setacciano internet alla ricerca di installazioni WordPress con una versione vulnerabile di un plugin specifico, e quando la trovano entrano. Non c’entra quanto sei importante. C’entra solo che avevi quel plugin non aggiornato in quel momento.
I segnali che il sito è compromesso, e quelli che ingannano
Il mio primo incontro con un’infezione su un blog WordPress non è arrivato da un antivirus né da un alert. È arrivato dal feed RSS. Una mattina il feed dell’articolo pubblicato poche ore prima non è partito, si è bloccato. Passandolo a un validatore, in coda comparivano righe di codice che non avevano nulla a che fare con il contenuto. Quello era il malware, che si stava manifestando nel posto più improbabile.
Racconto questo aneddoto perché descrive bene il problema: quando arriva il momento di rimuovere un malware da WordPress, quasi nessuno se ne accorge guardando la homepage. I sintomi arrivano da un canale laterale. I segnali che vedo ricorrere più spesso sono cinque.
- Un messaggio in Search Console nella sezione Problemi di sicurezza, oppure una email di Google al proprietario verificato della proprietà.
- Snippet in SERP che mostrano titoli o descrizioni in un’altra lingua, tipicamente giapponese o cirillico, su URL che non hai mai creato.
- Traffico organico che crolla di colpo su tutto il sito nello stesso giorno, senza un aggiornamento algoritmico in corso.
- Utenti che segnalano redirect verso siti estranei, mentre a te il sito appare perfettamente normale.
- Il provider di hosting che sospende l’account per uso anomalo di risorse, spesso perché il server sta inviando spam.
Ci sono anche segnali che ingannano. Un sito lento non è automaticamente un sito infetto: molto più spesso è un problema di configurazione, di risorse o di ottimizzazione, e su questo ho scritto una guida a parte su come velocizzare un sito web. Allo stesso modo, un plugin che va in errore dopo un aggiornamento è quasi sempre un conflitto, non un attacco. Al contrario, un sito che appare perfettamente sano può essere compromesso da mesi: il malware ben scritto non vuole essere trovato, perché più a lungo resta nascosto più a lungo produce.
Prima regola: congela lo stato del sito, poi pulisci
Qui la strada si divide, ed è il punto in cui la maggior parte delle guide su come rimuovere malware da WordPress sbaglia. La reazione istintiva, quando scopri l’infezione, è aprire l’FTP e cominciare a cancellare. Oppure installare un plugin di sicurezza e lanciare subito la pulizia automatica. Entrambe le cose distruggono informazioni che non potrai più recuperare.
Prima di modificare un singolo byte, fai tre cose. Scarica una copia completa dei file e un dump del database, e mettili da parte in un archivio che non toccherai più: è la fotografia della scena. Scarica i log del server, access log ed error log, per l’intero periodo disponibile: il provider li conserva per un tempo limitato, spesso pochi giorni, e una volta ruotati sono persi per sempre. Annota data e ora precise in cui hai scoperto il problema e da quale canale.
Nella mia pratica peritale ho visto più di una volta la stessa scena: un’azienda che vuole capire se la responsabilità dell’incidente fosse dell’agenzia che gestiva il sito, o dell’hoster, o del fornitore del plugin, e che si trova con zero elementi in mano perché il sito era stato “sistemato” in fretta. I file sovrascritti, i log ruotati, il database rigenerato. Tecnicamente il sito funzionava di nuovo. Giuridicamente non esisteva più nulla da dimostrare, e la discussione si è chiusa lì, a sfavore di chi aveva pulito con le migliori intenzioni.
Questo significa che la sequenza corretta ha un passaggio in più rispetto a quella che leggi ovunque: evidenza, contenimento, analisi, bonifica, valutazione, riapertura. Saltare il primo passaggio fa risparmiare venti minuti e può costare l’intera posizione negoziale. Se il sito sta attivamente danneggiando i visitatori, mettilo in manutenzione o offline mentre lavori: contenere non significa cancellare.
Come si trova il codice iniettato, davvero
Con la copia forense al sicuro, si può cominciare a cercare. Il metodo più efficace non è la scansione a firme, è il confronto. WordPress core, i temi e i plugin sono software pubblico: puoi scaricare la versione identica alla tua dai repository ufficiali e confrontare file per file. Tutto ciò che differisce nel core è, per definizione, da guardare. Su un’installazione media questo riduce migliaia di file a una manciata di sospetti in pochi minuti.
Il secondo criterio è la data di modifica. Ordina i file per mtime e guarda cosa è stato toccato nelle ore attorno al primo sintomo. Un file .php dentro la cartella degli upload, dove dovrebbero esserci solo immagini, è un candidato quasi certo. Un file con un nome plausibile ma leggermente sbagliato, tipo wp-cron.php in una posizione dove non dovrebbe stare, merita attenzione. Detto questo, attenzione al falso senso di sicurezza: chi sa quel che fa modifica anche i timestamp, quindi una data pulita non assolve nessuno.
Il terzo criterio riguarda i pattern tipici del codice offuscato: funzioni di decodifica applicate a stringhe lunghissime, valutazione dinamica di codice, chiamate a risorse esterne dentro file che non dovrebbero fare richieste di rete. Un plugin di sicurezza serio, come Wordfence, fa questo lavoro in modo sistematico e ti restituisce un report file per file. Usalo, ma leggilo con occhio critico e non affidargli la cancellazione automatica finché non hai capito cosa sta rimuovendo.
La parte che quasi tutti dimenticano è il database. Il codice malevolo vive spesso dentro la tabella delle opzioni, dentro i post, dentro i widget, dentro le voci di menu. Cerca tag script, iframe e URL esterni sospetti nei contenuti. Controlla la tabella utenti riga per riga e verifica che non ci siano amministratori che non riconosci. Controlla le attività pianificate di WordPress: una delle tecniche di persistenza più usate è un cron job che reinstalla la backdoor ogni volta che qualcuno visita il sito.
La bonifica: file, database, utenti, credenziali
Rimuovere il malware da WordPress, a questo punto, è quasi meccanico. Sostituisci il core con una copia pulita della stessa versione, tenendo da parte solo wp-config.php e la cartella degli upload, che vanno ispezionati a mano. Reinstalla temi e plugin dalle fonti ufficiali invece di ripulirli riga per riga: è più veloce e più affidabile. Elimina tutto ciò che non usi, perché un plugin disattivato ma presente sul disco è comunque codice raggiungibile e attaccabile.
Sul database, intervieni in modo chirurgico e con un backup pre-intervento sempre a portata di mano. Rimuovi le iniezioni dai contenuti, ripulisci le opzioni compromesse, cancella gli utenti fantasma, azzera le sessioni attive rigenerando i sali di autenticazione in wp-config.php: senza quest’ultimo passaggio chi era dentro resta dentro anche dopo il cambio password.
Poi cambia tutte le credenziali, e per tutte intendo tutte: amministratori e utenti WordPress, database, FTP e SFTP, pannello di hosting, e la casella email associata all’account, che è il vero anello debole della catena perché consente il recupero di ogni altra password. Se hai il dubbio che quella casella sia stata toccata, verificalo prima di procedere: ho raccolto il metodo in questa guida su come capire se la tua email è stata compromessa. Attiva l’autenticazione a due fattori almeno sugli account amministrativi, e verifica la macchina da cui lavori, perché se il tuo computer ha un infostealer stai consegnando le password nuove nello stesso identico modo in cui hai perso le vecchie. I segnali da guardare sono quelli che descrivo in questo approfondimento su come riconoscere un pc infetto.
Un’ultima nota sul ripristino da backup, che molti considerano la scorciatoia definitiva. Ripristinare è utile e spesso è la scelta giusta, ma solo se sei in grado di dire con ragionevole certezza a quale data risale la compromissione. Se l’infezione è di due mesi fa e il backup è di due settimane fa, stai ripristinando un sito già infetto e stai anche cancellando le prove. Il plugin UpdraftPlus, o qualunque soluzione equivalente che conservi copie multiple e distanziate nel tempo, risolve metà del problema; l’altra metà è sapere quando è cominciata.
La causa: senza questa il malware torna
Se dopo la bonifica non sai da dove sono entrati, non hai finito. Hai solo rimandato. La reinfezione a distanza di giorni o settimane è la norma proprio perché questa fase viene saltata, e il sito viene rimesso online con la stessa vulnerabilità aperta.
I numeri aiutano a capire dove guardare per primo. Il report annuale sullo stato della sicurezza di WordPress ha registrato quasi ottomila nuove vulnerabilità nel corso del 2024, delle quali il 96% riguardava plugin, il 4% i temi e meno dell’1% il core; un terzo di quelle vulnerabilità non aveva ancora una patch al momento della divulgazione pubblica, come documentato nello State of WordPress Security 2025 di Patchstack. Tradotto in pratica: il core di WordPress è la parte più solida dell’installazione, e la superficie di attacco reale è quasi interamente nei plugin che hai aggiunto tu.
L’analisi della causa si fa sui log che hai salvato all’inizio. Cerca la prima richiesta anomala verso un endpoint di plugin, le POST verso file che non dovrebbero riceverne, i tentativi di accesso ripetuti andati a buon fine. Incrocia gli orari con le date di modifica dei file infetti. Nella maggior parte dei casi, in mezz’ora hai il quadro: un plugin fermo a una versione con CVE nota, oppure una credenziale amministrativa debole, oppure una vulnerabilità sul server condiviso che ha permesso il salto da un altro sito ospitato sulla stessa macchina. Quest’ultimo caso è più frequente di quanto si creda su hosting economici, e non si risolve mettendo in sicurezza il sito: si risolve cambiando ambiente, valutando soluzioni con isolamento reale come quelle che descrivo nella pagina sul cloud hosting gestito.
Chiudo questa sezione con un limite dichiarato, perché fa parte del mestiere ammetterlo: in una minoranza di casi la causa non si trova. Log troppo corti, provider che non li fornisce, compromissione troppo vecchia. Quando succede, la risposta onesta non è inventare una spiegazione plausibile: è ricostruire il sito da zero su un ambiente nuovo, migrando solo i contenuti verificati, e accettare che quella sia la strada più costosa ma anche l’unica difendibile.
La domanda che nessuno fa: è un data breach?
Cerca in tutta la prima pagina di Google italiana per questa keyword e conta quante guide alla rimozione del malware da WordPress ti dicono che potresti avere un obbligo di legge da valutare entro 72 ore. La risposta, quando ho fatto questo controllo, era zero.
Eppure il ragionamento è semplice. Il tuo WordPress ha un form di contatto, una newsletter, magari un’area riservata o un WooCommerce. Contiene dati personali. Il GDPR definisce violazione di dati personali qualunque violazione di sicurezza che comporti, in modo accidentale o illecito, l’accesso non autorizzato a quei dati, e il Garante per la protezione dei dati personali chiarisce che la notifica va fatta senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui se ne è venuti a conoscenza, salvo che sia improbabile un rischio per i diritti delle persone. Una webshell che dava accesso completo al database per tre settimane rientra esattamente in quella definizione.
Non tutte le compromissioni sono notificabili, e non voglio spingerti a notificare per riflesso condizionato. Un defacement puramente estetico su un sito vetrina senza form è un caso diverso da un accesso persistente al database di un e-commerce. Ma la valutazione va fatta, va fatta in tempi stretti, e va messa per iscritto nel registro delle violazioni anche quando l’esito è che non si notifica. È esattamente il tipo di documento che, un anno dopo, fa la differenza fra un’azienda che ha gestito un incidente e un’azienda che l’ha subito. Se il tema dell’adeguamento del sito è ancora aperto per te, il quadro completo è nella guida al GDPR per i siti web.
Qui non sto dando consulenza legale, e per il caso specifico serve il tuo DPO o il tuo legale. Sto dicendo una cosa più modesta e più urgente: la finestra è di 72 ore, e comincia a scorrere nel momento in cui scopri l’infezione, non nel momento in cui finisci di pulire. Se dedichi quattro giorni alla bonifica prima di porti la domanda, la domanda te la sei già posta in ritardo.
Rimettere online e togliere l’avviso di Google
Quando hai la ragionevole certezza che il sito sia pulito e che la porta d’ingresso sia chiusa, si torna online. L’ordine conta anche qui: prima verifichi, poi chiedi la revisione a Google, non il contrario.
Controlla il sito come lo vede il crawler e non come lo vedi tu, perché il malware condizionale mostra contenuti diversi in base allo user agent e al referrer. Usa lo strumento di controllo URL e il rapporto Problemi di sicurezza di Search Console, che restano il canale ufficiale attraverso cui Google ti dice se considera il sito ancora compromesso; se non hai familiarità con lo strumento, ne ho scritto una guida completa a Google Search Console. Verifica la sitemap e l’indice per URL che non hai mai creato, tipicamente pagine spam generate a migliaia. Se ci sono, vanno rimosse e restituite in 404 o 410 prima di chiedere la revisione.
Solo a quel punto invii la richiesta di riesame. La risposta arriva in genere entro pochi giorni, e se la pulizia è stata parziale la richiesta viene respinta: ogni tentativo fallito allunga i tempi, quindi conviene essere sicuri prima di premere il pulsante. Una volta approvata, l’avviso a schermo pieno sparisce dal browser e la segnalazione sparisce dallo snippet nei risultati di ricerca. Il recupero del posizionamento, invece, non è istantaneo e dipende da quanto è durata l’infezione.
I trenta giorni dopo: come si verifica che sia davvero finita
La bonifica non finisce con il ripristino. Finisce quando hai una prova ragionevole che non stia ripartendo. Aver saputo rimuovere il malware da WordPress conta poco se nessuno controlla i trenta giorni successivi. Nel mese successivo tieni sotto controllo quattro cose: le date di modifica dei file, che non devono cambiare se nessuno sta lavorando sul sito; la lista degli utenti amministratori; le attività pianificate; e il traffico organico segmentato per dispositivo, perché una redirect condizionale si vede prima nei dati che a occhio.
Sul fronte della prevenzione strutturale, il riferimento sono le linee guida ufficiali di hardening di WordPress nella documentazione per sviluppatori: permessi corretti su file e cartelle, disabilitazione dell’editor di file dal pannello, principio del privilegio minimo sugli account, aggiornamenti tempestivi. Sono misure noiose e note da anni, e sono anche quelle che nella pratica mancano nella quasi totalità dei siti che arrivano già compromessi.
Poi c’è l’aspetto organizzativo, che per una PMI conta quanto quello tecnico: chi è responsabile degli aggiornamenti, con quale frequenza, chi riceve gli alert di Search Console, dove sono conservati i backup e ogni quanto viene provato un ripristino. Un backup mai testato non è un backup, è una speranza. Su come si costruisce questo impianto in azienda ho raccolto un quadro più ampio nella pagina dedicata alla sicurezza informatica per aziende e PMI.
Riepilogo dei punti chiave
Rimuovere un malware da WordPress richiede una sequenza precisa, e l’ordine conta più degli strumenti. Prima di toccare qualsiasi file va congelato lo stato del sito: copia completa di file e database, download dei log del server prima che vengano ruotati, annotazione di data e ora della scoperta. Solo dopo si passa all’analisi, confrontando core, temi e plugin con le versioni ufficiali e ordinando i file per data di modifica, senza dimenticare il database, gli utenti amministratori e le attività pianificate, dove il malware nasconde i meccanismi di persistenza. La bonifica sostituisce il codice invece di ripararlo, rigenera i sali di autenticazione e cambia tutte le credenziali, inclusa la casella email di recupero. Il passaggio decisivo è l’analisi della causa: il 96% delle vulnerabilità WordPress riguarda i plugin, e senza individuare il punto di ingresso la reinfezione è questione di giorni. In parallelo va valutato se l’incidente costituisca una violazione di dati personali ai sensi del GDPR, con una finestra di 72 ore che decorre dalla scoperta e non dalla fine della pulizia. La riapertura si fa dopo aver verificato il sito con l’occhio del crawler, chiedendo la revisione a Google solo a bonifica completata, e va seguita da trenta giorni di monitoraggio su file, utenti, cron e traffico segmentato.
Domande frequenti su come rimuovere malware da WordPress
Come capisco se il mio sito WordPress ha un malware?
I segnali più affidabili non si vedono aprendo la homepage. Controlla il rapporto Problemi di sicurezza in Google Search Console, verifica in SERP la presenza di titoli o URL che non hai mai creato, guarda se il traffico organico è crollato di colpo in un solo giorno, e chiedi conferma a utenti che navigano da mobile, perché molte redirect malevole sono condizionali e non si attivano dal browser dell’amministratore. Un ulteriore controllo utile è ordinare i file del sito per data di modifica via FTP: file PHP modificati di recente senza che tu abbia aggiornato nulla sono un indizio forte.
Posso rimuovere il malware da WordPress da solo o serve un tecnico?
Se il sito è semplice, non tratta dati sensibili e sai muoverti fra FTP, database e log, la procedura descritta in questa guida è alla portata di chi ha buone basi tecniche. Il momento in cui conviene fermarsi e chiamare qualcuno è quando il sito gestisce pagamenti o dati personali di terzi, quando l’infezione si ripresenta dopo la pulizia, oppure quando i log non ci sono e non riesci a stabilire da dove sia entrato l’attaccante. In quei casi il rischio non è più solo tecnico ma anche legale, e improvvisare costa più che delegare.
Basta ripristinare un backup per pulire un sito WordPress infetto?
Il ripristino da backup non è di per sé sufficiente a rimuovere il malware da WordPress: funziona solo se sai a quale data risale la compromissione e disponi di una copia precedente a quella data. Molte infezioni restano silenti per settimane o mesi, quindi ripristinare l’ultimo backup disponibile significa spesso ripristinare un sito già infetto, distruggendo per giunta le prove utili all’analisi. Il ripristino inoltre non chiude la vulnerabilità che ha permesso l’ingresso: se rimetti online la stessa versione dello stesso plugin bucato, l’infezione si ripresenta. Prima congela lo stato attuale, poi individua la causa, poi decidi se ripristinare o ricostruire.
Un sito WordPress hackerato è un data breach da notificare al Garante?
Non automaticamente, ma va valutato e la valutazione va documentata. Se il sito contiene dati personali, anche solo i contatti di un form o gli iscritti a una newsletter, e l’attaccante ha avuto accesso al database o al file system, si ricade nella definizione di violazione di dati personali del GDPR. In quel caso il titolare del trattamento deve notificare al Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza del fatto, salvo che sia improbabile un rischio per i diritti delle persone coinvolte. Il termine decorre dalla scoperta, non dal completamento della bonifica. Per il caso concreto occorre il supporto del proprio DPO o di un legale.
Quanto tempo serve per togliere l’avviso di Google dopo la rimozione del malware?
Dopo aver inviato la richiesta di revisione dal rapporto Problemi di sicurezza di Search Console, l’esito arriva di norma entro pochi giorni. Se la pulizia è completa, l’avviso a schermo pieno nel browser e la segnalazione nello snippet spariscono a seguito dell’approvazione. Se la revisione viene respinta perché resta codice malevolo, i tempi si allungano, quindi conviene verificare il sito con l’occhio del crawler prima di inviare la richiesta. Il ritorno del posizionamento organico è un processo separato e più lento, proporzionale alla durata dell’infezione.
Perché il malware torna dopo pochi giorni dalla pulizia?
Nella quasi totalità dei casi per una di tre ragioni. È rimasta una backdoor non individuata, spesso un file dentro la cartella degli upload o un plugin fittizio che non compare nella lista standard. Oppure è rimasto attivo un meccanismo di persistenza nel database, tipicamente un’attività pianificata di WordPress che reinstalla il codice a ogni visita. Oppure la vulnerabilità di ingresso non è mai stata chiusa, perché la causa non è stata cercata. Un quarto scenario, meno frequente ma reale, è la compromissione a livello di server condiviso: in quel caso nessuna pulizia del singolo sito risolve.
Un plugin di sicurezza gratuito basta a proteggere WordPress?
Serve, ma non basta e non va confuso con una strategia. Un buon plugin di sicurezza rileva file modificati, blocca tentativi di accesso ripetuti e filtra parte del traffico malevolo, e nella fase di analisi è uno strumento prezioso. Non compensa però un plugin abbandonato che non riceverà mai una patch, credenziali condivise via email, un hosting senza isolamento o un backup mai testato. La protezione reale nasce dalla combinazione di aggiornamenti tempestivi, privilegi minimi, autenticazione a due fattori, backup verificati e responsabilità organizzative assegnate a qualcuno per nome.
Cosa portare a casa da un incidente
Un sito compromesso è un evento fastidioso, non una catastrofe, a patto di non trasformarlo in una catastrofe con la fretta. La differenza fra chi esce bene e chi esce male da questa situazione non sta nella competenza tecnica sulla rimozione del malware da WordPress, che oggi è ampiamente documentata e alla portata di molti. Sta nell’aver congelato la scena prima di intervenire, nell’aver cercato la causa invece di limitarsi ai sintomi, e nell’aver capito in tempo se quell’incidente aveva anche una dimensione normativa da gestire.
Se stai leggendo questa guida con il sito già offline, l’ordine da seguire è quello: copia forense, log, contenimento, analisi, bonifica, valutazione GDPR, riapertura verificata, trenta giorni di monitoraggio. Se invece la stai leggendo per prevenzione, la domanda giusta da farsi oggi è una sola: se domattina trovassi il sito compromesso, avresti i log, avresti un backup pulito e sapresti chi chiamare?
Prenota una consulenza strategica: se vuoi una valutazione della postura di sicurezza del tuo sito o un supporto nella gestione di un incidente in corso, puoi fissare un confronto diretto in agenda.
