Come rimuovere malware da un sito WordPress

Un sito WordPress infetto raramente si presenta con un messaggio esplicito. Più spesso sono i segnali indiretti a far scattare l’allarme: un cliente scrive che dal telefono il sito apre una pagina di scommesse, Google aggiunge l’avviso «Questo sito potrebbe essere stato violato», l’hosting sospende l’account per invio di spam, oppure tra gli utenti compare un amministratore che nessuno ricorda di aver creato. A quel punto la domanda è una sola: come si rimuove il malware, e come si fa in modo che non torni?

Questa guida descrive il metodo che usiamo ogni giorno nelle bonifiche, dalla prima messa in sicurezza alla revisione in Google Search Console. Non è una lista di plugin da installare: è un procedimento, perché la differenza tra una pulizia che regge e una che si ripete ogni due settimane non sta nello strumento, ma nell’ordine in cui si fanno le cose e in quanto a fondo si cerca. Alcuni passaggi richiedono l’accesso SSH e un minimo di familiarità con la riga di comando; dove servono, lo diciamo chiaramente.

Prima di toccare qualsiasi cosa

La reazione istintiva davanti a un sito compromesso è cancellare subito tutto ciò che sembra sospetto, oppure ripristinare l’ultimo backup e considerare chiusa la faccenda. Entrambe le mosse distruggono le informazioni che servono per capire cosa è successo, e il ripristino da solo riporta online la stessa vulnerabilità che ha permesso l’attacco, spesso insieme a una backdoor già presente nel backup. Ne abbiamo parlato nell’articolo sul perché ripristinare un backup non basta.

I primi passi sono tre, in quest’ordine.

1. Conservare le prove. Una copia completa dei file, un dump del database e i log del web server così come sono, prima di qualsiasi modifica. È la base di tutto il lavoro successivo: permette di confrontare, di ricostruire la cronologia e, se serve, di dimostrare cosa è accaduto. Le date di modifica dei file vanno preservate, quindi la copia si fa con strumenti che le mantengono, come tar o rsync -a. Il procedimento è descritto passo per passo nella guida su cosa fare nelle prime due ore.
2. Contenere il danno. Se il sito reindirizza i visitatori verso pagine malevole, distribuisce falsi aggiornamenti del browser o raccoglie dati di pagamento, ogni ora online significa altre vittime. Una pagina di manutenzione servita dal web server, oppure un accesso limitato al proprio indirizzo IP, ferma il danno senza cancellare nulla.
3. Valutare gli obblighi. Se il sito tratta dati personali, come gli account dei clienti, gli ordini o i moduli di contatto, una violazione può configurare un data breach da notificare al Garante entro 72 ore dalla scoperta. Il conto alla rovescia parte subito, non a pulizia finita: trovi i criteri nell’articolo su sito hackerato e GDPR.

Conviene anche avvisare l’hosting: su un server condiviso l’infezione può non essere limitata al tuo sito, e il fornitore può avere log o strumenti che dal tuo pannello non vedi.

Riconoscere l’infezione: i sintomi e i falsi negativi

Molti malware per WordPress sono progettati per non farsi vedere dal proprietario del sito. I segnali più comuni sono questi:

• reindirizzamenti verso siti di scommesse, farmaci o truffe, che compaiono solo da mobile, solo arrivando da Google o solo alla prima visita;
• risultati di ricerca invasi da pagine in giapponese o da prodotti che il sito non vende;
• avvisi di Google Search Console nella sezione «Problemi di sicurezza», o l’avviso rosso di Navigazione sicura nel browser;
• utenti amministratori sconosciuti, password che non funzionano più, plugin che compaiono o scompaiono;
• CPU del server costantemente alta, rallentamenti senza un aumento di traffico, posta in uscita bloccata perché l’indirizzo del server è finito in una blocklist;
• file PHP con nomi casuali, o con nomi che imitano quelli di WordPress, in cartelle dove non dovrebbero esserci.

Il primo punto merita attenzione: un redirect condizionale controlla chi sta visitando la pagina e si attiva solo per i visitatori che non sono il proprietario. Chi apre il sito dal proprio computer, magari già autenticato in WordPress, vede tutto normale. Lo stesso vale per lo spam SEO giapponese, che mostra le pagine iniettate solo al crawler di Google.

Per questo un controllo «tutto pulito» di uno scanner esterno o di un plugin di sicurezza non dimostra che il sito sia sano. Gli scanner online vedono solo l’HTML che il sito restituisce a loro; i plugin a firme riconoscono il codice malevolo già noto e già catalogato, e faticano con quello offuscato in modo nuovo, nascosto nel database o fuori dalla cartella di WordPress. Sono strumenti utili per un primo orientamento, non per una diagnosi: ne abbiamo spiegato i limiti degli scanner a firme in un articolo dedicato.

Fase 1: capire da dove è entrato

È la fase che le guide sbrigative saltano, ed è la ragione principale per cui le infezioni ritornano. Se non si individua il punto di ingresso, si pulisce un sito che resta aperto: chi è entrato una volta rientra con lo stesso metodo, spesso entro pochi giorni e quasi sempre in modo automatico.

Le cause che troviamo più spesso sono quattro:

• Un plugin o un tema vulnerabile, non aggiornato oppure colpito da una falla non ancora corretta. In questi casi l’ingresso lascia tracce precise negli access log: richieste POST verso un file del plugin o verso admin-ajax.php con un’azione insolita, seguite dalla comparsa di un file nuovo. Per le falle senza patch vale quanto scritto sulle vulnerabilità 0-day nei plugin.
• Un plugin o un tema «nulled», cioè una versione premium scaricata gratis da siti non ufficiali, con la backdoor già inclusa. Qui non c’è un attacco da cercare nei log: il malware è stato installato dal proprietario stesso, senza saperlo. Ne parliamo in plugin nulled e temi «gratuiti».
• Credenziali rubate: password riutilizzate e finite in un database di violazioni, oppure credenziali FTP salvate nel client di uno sviluppatore il cui computer era infetto. In questo caso i log mostrano accessi validi, non tentativi di attacco, e la pulizia del sito non serve a nulla se prima non si cambiano le password. Il caso tipico è descritto nell’articolo sulle credenziali FTP rubate.
• Un altro sito sullo stesso account, magari una vecchia installazione dimenticata in una sottocartella, da cui l’infezione si è estesa a tutti i siti che condividono lo stesso utente di sistema. È la contaminazione incrociata tipica degli hosting condivisi.

Lo strumento principale sono gli access log del web server. Si parte dalla data di modifica del primo file malevolo trovato e si cercano, a ritroso, le richieste che lo hanno creato o che lo hanno usato per la prima volta. Il metodo è descritto in dal log al vettore d’attacco; se i log sono tanti, un modello di intelligenza artificiale eseguito in locale può aiutare a scremarli senza mandare dati a servizi esterni, come spiegato nell’articolo sull’analisi dei log con l’AI locale.

Non sempre il punto di ingresso si trova con certezza: molti hosting conservano i log per pochi giorni, e un’infezione scoperta dopo mesi può aver cancellato le tracce. In quel caso si procede per esclusione, chiudendo tutte le strade plausibili: aggiornamento o sostituzione di ogni componente, rimozione di tutto ciò che non è indispensabile, cambio di tutte le credenziali.

Fase 2: trovare tutto ciò che il malware ha lasciato

Un’infezione reale non è quasi mai un singolo file. Chi entra in un sito installa di solito più punti di accesso in posti diversi, così che la rimozione di uno lasci in funzione gli altri. Prima di cancellare qualcosa bisogna quindi fare l’inventario completo, livello per livello.

Il core di WordPress

I file del core sono identici per ogni installazione della stessa versione, quindi si possono confrontare con l’originale. Con WP-CLI basta un comando:

wp core verify-checksums

Il comando confronta ogni file con i checksum pubblicati da WordPress.org e segnala i file modificati e quelli che non dovrebbero esserci, come un wp-login.php alterato o un file in più dentro wp-includes. La sua documentazione descrive le opzioni. Non controlla però wp-config.php, che è diverso per ogni sito e va letto a mano: le righe da cercare sono le inclusioni di file esterni, il codice prima della riga /* That's all, stop editing! */ e le costanti che non hai impostato tu.

Plugin e temi

Per i plugin pubblicati su WordPress.org esiste lo stesso controllo: wp plugin verify-checksums --all. I plugin premium e i temi non hanno checksum pubblici, quindi il confronto si fa con una copia scaricata dall’account ufficiale dello sviluppatore, della stessa versione installata. I punti più colpiti nei temi sono functions.php, l’header e il footer, come spiegato nell’articolo sul malware nei temi WordPress. Attenzione ai file cifrati: un plugin legittimo può essere protetto con ionCube, e non va scambiato per malware, ma neanche il contrario va escluso; il criterio per distinguerli è nell’articolo sui file PHP offuscati.

La cartella uploads

In wp-content/uploads dovrebbero esserci solo immagini, documenti e file generati dai plugin, quasi mai file PHP. Una ricerca come find wp-content/uploads -name "*.php" fa emergere spesso le webshell, i piccoli script che permettono di eseguire comandi sul server da un browser. Vanno cercati anche i file con doppia estensione e le immagini che contengono codice PHP. Dopo la pulizia, l’esecuzione di PHP in quella cartella va bloccata a livello di web server, come descritto nella guida sulle webshell nella cartella uploads.

mu-plugins, drop-in e file di configurazione

Alcuni file vengono caricati da WordPress o da PHP in automatico, senza comparire nella lista dei plugin. I must-use plugin in wp-content/mu-plugins e i drop-in come object-cache.php o db.php sono eseguiti a ogni richiesta e non si disattivano dal pannello: per un attaccante sono il posto ideale, come spiegato nell’articolo su mu-plugins e drop-in. Ancora più a monte agiscono .htaccess e .user.ini, che con direttive come auto_prepend_file fanno eseguire un file prima di qualsiasi pagina del sito, anche se quel file è fuori dalla cartella di WordPress: trovi i dettagli in backdoor nascoste in .htaccess e .user.ini.

Il database

Un sito con tutti i file sostituiti da copie ufficiali può restare infetto, perché parte del malware vive nel database. I punti da controllare sono:

• la tabella wp_options, dove opzioni con nomi plausibili contengono codice serializzato, codificato in base64 o eseguito da un frammento rimasto in un file; il metodo per trovarle è nell’articolo sui payload serializzati in wp_options;
• gli utenti: amministratori creati dal malware, spesso nascosti dalla lista del pannello con un filtro, che si vedono solo interrogando direttamente il database o con wp user list --role=administrator, come spiegato nella guida sugli amministratori fantasma;
• i contenuti di articoli e pagine, dove script esterni e link nascosti vengono inseriti direttamente nel testo, e i widget;
• i trigger SQL, poco noti ma molto efficaci: istruzioni salvate nel database che si riattivano a ogni nuovo articolo o a ogni nuovo utente, e che nessuno scanner di file vede. Si elencano con SHOW TRIGGERS; ne parliamo in trigger SQL e malware nel database.

Sui siti WooCommerce va controllato con particolare attenzione tutto ciò che finisce nella pagina di pagamento: uno skimmer JavaScript può stare in un’opzione del database, in un widget o in uno script caricato da un dominio esterno, e raccoglie i dati delle carte senza alterare il funzionamento del negozio.

Oltre WordPress: il server

È il livello che separa una pulizia da una bonifica. Se l’attaccante ha potuto eseguire comandi sul server, ha potuto anche lasciare meccanismi di persistenza fuori dalla cartella del sito:

• cron job di sistema che ogni pochi minuti riscaricano il malware o ricreano i file cancellati: è il motivo più comune per cui un sito «si reinfetta da solo» il giorno dopo la pulizia, come spiegato nell’articolo sulle backdoor nascoste nei cron job;
• chiavi SSH aggiunte al file authorized_keys dell’utente, che permettono di rientrare anche dopo il cambio di tutte le password;
• processi residenti, cioè script PHP o binari che restano in esecuzione anche dopo che il loro file è stato cancellato dal disco, descritti nell’articolo sui processi PHP «deleted»; il caso più frequente è il cryptominer che tiene la CPU al massimo;
• script di invio posta che usano il server per mandare spam e rovinano la reputazione del dominio, come descritto in il server che invia spam;
• gli altri siti dello stesso account, che vanno controllati tutti: basta una sola installazione infetta per ricontaminare le altre.

Su un hosting condiviso molti di questi controlli non sono possibili dal pannello: in quel caso va chiesto al fornitore di verificare cron, processi e chiavi dell’account.

Un aiuto pratico in questa fase sono le date. Il comando find . -type f -newermt "2026-10-01" elenca i file modificati dopo una certa data, e i file malevoli tendono a concentrarsi attorno al momento dell’ingresso. Non è una prova, perché le date si possono falsificare e gli aggiornamenti legittimi modificano molti file, ma aiuta a dare un ordine alla ricerca.

Fase 3: la pulizia, sostituendo invece di correggere

Solo a questo punto, con l’inventario completo e il punto di ingresso individuato o almeno circoscritto, si passa alla pulizia. Il principio è semplice: un file infetto non si corregge cancellando le righe sospette, si sostituisce con una copia ufficiale. Correggere a mano significa fidarsi di aver visto tutto, e il codice malevolo è scritto apposta per non farsi vedere.

1. Core. Si scarica di nuovo la stessa versione di WordPress con wp core download --force --skip-content o dal sito ufficiale, e si rimuovono i file in più segnalati dal controllo dei checksum. Le cartelle wp-admin e wp-includes si possono sostituire per intero.
2. Plugin e temi. Ogni plugin si reinstalla da WordPress.org o dall’account dello sviluppatore, nell’ultima versione disponibile. Quelli disattivati, abbandonati da anni o di provenienza incerta si eliminano: ogni componente in meno è una porta in meno. I plugin nulled si sostituiscono con la licenza ufficiale o con un’alternativa.
3. Uploads e configurazione. Si eliminano i file PHP e gli script trovati in uploads, i mu-plugins e i drop-in che non hai installato tu, le direttive estranee in .htaccess e .user.ini. Il file wp-config.php si ricostruisce partendo dal modello originale, ricopiando solo i dati di connessione e le costanti che conosci.
4. Database. Si rimuovono le opzioni malevole, i trigger, gli utenti non riconosciuti e il codice iniettato nei contenuti. Qui serve cautela: un DELETE sbagliato su wp_options può rompere il sito, quindi ogni intervento si fa dopo il backup e con interrogazioni mirate, non con un cerca e sostituisci generico.
5. Server. Si eliminano i cron job, le chiavi SSH e i processi residenti estranei, e si controllano allo stesso modo gli altri siti dell’account.

Se il contenuto del sito è sostanzialmente statico, una strada alternativa è la ricostruzione: installazione nuova e pulita, plugin reinstallati da zero, importazione del solo database ripulito e dei soli file media verificati. Richiede più tempo ma dà le garanzie più alte, ed è la scelta consigliata quando l’infezione è molto estesa o va avanti da mesi.

Fase 4: chiudere gli accessi

Dopo la pulizia vanno cambiate tutte le credenziali, e l’ordine conta. Se l’attaccante legge ancora la tua casella email, ogni password nuova che ti arriva per posta finisce anche a lui. Si parte quindi dall’esterno e si arriva a WordPress:

1. la casella email collegata all’hosting e agli account amministratore, con la verifica in due passaggi attiva;
2. il pannello dell’hosting e il registrar del dominio;
3. gli accessi FTP, SFTP e SSH, eliminando gli utenti FTP che non servono e le chiavi SSH che non riconosci;
4. la password del database, aggiornata poi in wp-config.php;
5. le chiavi segrete (i salt) di wp-config.php, che si rigenerano con wp config shuffle-salts e invalidano in un colpo tutte le sessioni aperte, comprese quelle dell’attaccante;
6. le password di tutti gli utenti con ruolo amministratore o editore, e le password applicative, che permettono l’accesso alle API senza passare dal login e sopravvivono al cambio della password principale;
7. le chiavi dei servizi collegati: gateway di pagamento, API di WooCommerce, servizi di posta, CDN e strumenti di backup esterni.

Se il punto di ingresso erano credenziali rubate dal computer di chi gestisce il sito, quel computer va controllato prima di digitare le password nuove: altrimenti verranno rubate anche quelle. Per gli account amministratore conviene attivare subito l’autenticazione a due fattori.

Fase 5: verificare e tenere d’occhio il sito

Una bonifica non è finita quando l’ultimo file è stato cancellato, ma quando si è verificato che il sito sia pulito da ogni punto di vista:

• i controlli dei checksum di core e plugin non segnalano più differenze;
• il sito, visitato da mobile, in una finestra anonima e con lo user agent di Googlebot, mostra lo stesso contenuto;
• lo strumento «Controllo URL» di Search Console mostra la pagina come la vede Google, senza contenuti estranei;
• gli access log non mostrano più richieste verso i file rimossi andate a buon fine, e i tentativi di raggiungerli restituiscono errore;
• CPU, processi e coda di posta del server sono tornati normali.

Poi il sito va tenuto sotto osservazione per qualche settimana. Le richieste verso le vecchie backdoor continueranno ad arrivare, perché chi le ha installate le ha registrate in elenchi automatici: è normale, e i log aiutano a capire se qualcuno sta provando strade nuove. Un monitoraggio dell’integrità dei file segnala subito qualsiasi modifica inattesa. A quel punto si completano le misure di difesa con la checklist di hardening dopo la bonifica: permessi corretti, esecuzione di PHP bloccata dove non serve, modifica dei file disattivata dal pannello, e se serve un WAF.

Fase 6: recuperare la reputazione

Se Google ha segnalato il sito, l’avviso non sparisce da solo appena il malware è stato rimosso. Nella sezione «Problemi di sicurezza» di Search Console si richiede una revisione, descrivendo cosa è stato trovato e cosa è stato fatto; la richiesta va inviata solo quando la pulizia è davvero completa, perché un rifiuto allunga i tempi delle revisioni successive. Il procedimento, con gli errori da evitare, è descritto nell’articolo sulla rimozione dalle blacklist.

Lo stesso vale per le altre blocklist: quelle dei produttori di antivirus, quelle dei filtri di posta se il server ha inviato spam, e quelle dei servizi di phishing se il sito ha ospitato un kit di phishing. Per lo spam SEO, infine, le pagine iniettate vanno fatte sparire dall’indice: devono restituire un errore 404 o 410, e se sono molte si può chiederne la rimozione temporanea da Search Console mentre Google le ripassa.

Gli errori che fanno tornare il malware

Nella maggior parte delle reinfezioni che ci arrivano, la pulizia precedente è caduta su uno di questi punti:

• è stato ripristinato un backup senza controllarlo e senza correggere la vulnerabilità;
• si è usato solo un plugin di sicurezza, e si è cancellato ciò che segnalava, lasciando il resto;
• i file sono stati corretti a mano invece che sostituiti;
• il database e il server non sono stati controllati;
• le password sono state cambiate prima della pulizia, oppure non sono state cambiate tutte;
• un vecchio sito di prova nella stessa area dell’hosting è stato dimenticato;
• il plugin vulnerabile è stato reinstallato nella stessa versione, o quello nulled è tornato al suo posto.

Quando il fai da te non basta

Una parte delle infezioni si risolve con le indicazioni di questa guida, soprattutto quando il malware è recente, limitato ai file e il sito è piccolo. Ci sono però situazioni in cui conviene affidarsi a chi fa questo lavoro ogni giorno:

• il sito è già stato pulito una volta e l’infezione è tornata;
• non hai accesso SSH, o non hai dimestichezza con la riga di comando e il database;
• il sito vende online o tratta dati personali, e ogni ora offline ha un costo;
• Google ha già segnalato il sito, o l’hosting ha sospeso l’account;
• i sintomi riguardano il server: CPU alta, spam in uscita, processi sconosciuti.

Se cerchi un aiuto esterno, prima di scegliere leggi le domande da fare a un servizio di rimozione malware: chiarire cosa viene controllato, se è incluso il server e cosa succede in caso di reinfezione evita molte sorprese.

Il nostro servizio di bonifica segue il procedimento descritto in questa pagina, con un prezzo fisso e un tempo massimo di intervento scritto nel contratto. Puoi scegliere il piano in base all’urgenza: bonifica entro 6 ore o entro 12 ore, contate in ore consecutive anche di notte e nei festivi, oppure entro 24 ore lavorative. Con ogni piano rimuoviamo malware, backdoor e persistenze nei file, nel database e sul server, chiudiamo la porta da cui sono entrati e ti guidiamo nella richiesta di revisione a Google; se entro 30 giorni il malware si ripresenta, lo rimuoviamo di nuovo gratuitamente.

Domande frequenti

Basta un plugin di sicurezza per rimuovere il malware?

Raramente. I plugin di sicurezza sono utili per individuare i file noti e per segnalare le modifiche, ma lavorano dall’interno di WordPress: non vedono il server, faticano con il codice nel database e con quello offuscato in modo nuovo, e un malware che controlla già il sito può disattivarli o ingannarli. Vanno considerati uno strumento della diagnosi, non la diagnosi.

Posso semplicemente ripristinare un backup?

Solo se sai con certezza quando è avvenuto l’ingresso, se il backup è precedente e se prima di rimettere il sito online correggi la vulnerabilità che è stata sfruttata. Nella pratica le infezioni vengono scoperte settimane o mesi dopo, quindi anche i backup più vecchi possono contenere le backdoor; in più il ripristino non tocca cron, chiavi SSH e altri siti dell’account.

Quanto tempo serve per pulire un sito WordPress?

Dipende dall’estensione dell’infezione più che dalla dimensione del sito. Un’infezione recente e limitata ai file si risolve in poche ore; una presente da mesi, con codice nel database, persistenza sul server e più siti coinvolti, richiede una giornata di lavoro o più. A questo si aggiungono i tempi di Google per la revisione, che di solito vanno da un giorno a qualche giorno dopo la richiesta.

Il sito infetto può danneggiare i visitatori?

Sì. Molti malware usano il sito per attaccare chi lo visita: lo reindirizzano verso truffe, gli mostrano falsi aggiornamenti del browser o falsi CAPTCHA che installano programmi malevoli, oppure ne rubano i dati di pagamento. È il motivo per cui Google segnala i siti infetti e per cui, finché la pulizia non è conclusa, conviene tenere il sito offline o in manutenzione.

Come evito che succeda di nuovo?

Chiudendo la causa e riducendo le occasioni: aggiornamenti regolari di core, plugin, temi e versione di PHP, solo componenti da fonti ufficiali, password uniche e autenticazione a due fattori, backup verificati e conservati fuori dal server, e un controllo periodico dell’integrità dei file. Nessuna misura da sola rende un sito invulnerabile, ma insieme rendono un attacco molto più difficile e molto più facile da scoprire in tempo.