Rimuovere il malware da WordPress: piano passo per passo

Rimuovere davvero il malware da WordPress significa sostituire tutto ciò che si può con copie provenienti da fonti affidabili, chiudere la falla da cui è entrato l'attaccante e cambiare ogni segreto che potrebbe aver visto. Cancellare l'unico file sospetto trovato non basta, perché chi attacca di solito si lascia più di una porta aperta per rientrare.

Il piano si articola in otto passaggi. Vanno seguiti nell'ordine, prendendo appunti man mano: serviranno per Google, per l'hosting e forse per l'autorità di protezione dei dati. Se non è ancora certo che il sito sia compromesso, conviene partire dai nostri 12 segnali di un sito WordPress hackerato.

Prima di rimuovere il malware da WordPress: ripulire, ripristinare o chiedere aiuto?

Questa decisione va presa per prima, perché cambia tutto il resto del piano.

• Ripristinare un backup pulito se si sa, almeno a grandi linee, quando è iniziata l'infezione e si dispone di un backup precedente a quella data. I passaggi 3, 5 e 6 restano comunque necessari, altrimenti l'attaccante rientra dalla stessa falla. Ordini, commenti o messaggi dei moduli arrivati dopo il backup vanno persi, a meno di esportarli prima.
• Rivolgersi a un professionista se il sito accetta pagamenti o contiene dati sensibili, se l'infezione è tornata dopo una pulizia precedente, se sono colpiti più siti sullo stesso server, se serve una relazione forense per un'assicurazione o un'autorità, oppure se non si ha dimestichezza con la riga di comando. Molti hosting offrono anche questo servizio.
• Ripulire in autonomia se si dispone di accesso SSH e WP-CLI, di un elenco dei plugin e dei temi in uso e del tempo necessario per fare le cose per bene.

Contenere: fermare i danni, conservare le prove

Passaggio 1: contenere i danni

Mettere il sito offline o limitarne l'accesso, così che i visitatori non vengano infettati. wp maintenance-mode activate mostra ai visitatori un avviso di manutenzione, ma agisce solo sulle richieste che caricano WordPress: un file backdoor richiamato direttamente continua a funzionare. Il vero contenimento avviene sul server, quindi conviene chiedere all'hosting di bloccare l'accesso pubblico o di limitarlo al proprio indirizzo IP.

Poi va chiusa l'area di amministrazione. Questo comando disconnette tutti gli utenti:

wp user list --field=ID | xargs -n 1 wp user session destroy --all

Cambiare la propria password di amministratore da un dispositivo pulito. Gli account sconosciuti vanno annotati, ma eliminati solo dopo il passaggio 2. Su un sito infetto si può aggiungere --skip-plugins --skip-themes ai comandi WP-CLI, così che il codice di plugin e temi non venga eseguito; i plugin must-use e wp-config.php vengono comunque caricati.

Passaggio 2: salvare uno snapshot dello stato infetto

Prima di toccare qualsiasi cosa, salvare il sito compromesso esattamente com'è: serve per trovare il punto d'ingresso, per rispondere a un'assicurazione o a un'autorità e come ripiego se la pulizia dovesse rompere qualcosa.

# eseguire nella root di WordPress; ~/evidence deve stare fuori dalla web root
mkdir -p ~/evidence
wp db export ~/evidence/db-infected-$(date +%F).sql
tar -czf ~/evidence/files-infected-$(date +%F).tar.gz .
sha256sum ~/evidence/*

La riga sha256sum registra i checksum, così in seguito si può dimostrare che le copie non sono state alterate. Scaricare anche i log di accesso e di errore: molti hosting li conservano solo per un periodo limitato.

Ripulire: chiudere la falla e sostituire ciò che è stato toccato

Passaggio 3: trovare il punto d'ingresso

Chi salta questo passaggio rischia di dover ripulire lo stesso sito anche la settimana dopo. I punti d'ingresso tipici sono plugin o temi vulnerabili, password rubate o riutilizzate e altri siti infetti sullo stesso account di hosting.

• Plugin e temi vulnerabili. Eseguire wp plugin list --fields=name,status,version,update e wp theme list, poi cercare ogni elemento non aggiornato in un database di vulnerabilità. La velocità conta: secondo il fornitore di sicurezza Patchstack, nel 2025 il tempo mediano ponderato fino allo sfruttamento di massa delle vulnerabilità più attaccate è stato di 5 ore (State of WordPress Security in 2026).
• Credenziali rubate. Verificare quando sono stati creati gli account amministratore sconosciuti e cercare accessi da indirizzi IP insoliti.
• Log del server. Cercare richieste POST verso file insoliti nel periodo in cui risulta modificato il primo file.

grep '"POST ' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
find . -type f -name '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

Sostituire access.log con il proprio file di log. Il primo comando elenca i percorsi che hanno ricevuto più richieste POST; il secondo elenca i file PHP modificati negli ultimi 14 giorni. Le date dei file si possono falsificare, quindi vanno prese come indizi. Se il punto d'ingresso non salta fuori, meglio partire dall'ipotesi peggiore: sostituire tutti i plugin e i temi e cambiare tutte le credenziali.

Passaggio 4: ripulire da fonti affidabili

Sostituire invece di riparare: le copie nuove dalla fonte ufficiale sono più affidabili di qualunque lettura di codice offuscato.

Core di WordPress. Eliminare wp-admin e wp-includes e scaricare di nuovo la stessa versione, così spariscono anche eventuali file estranei nascosti in quelle cartelle. Il comando va eseguito nella root di WordPress, la cartella che contiene wp-load.php e wp-admin:

VER=$(wp core version)
[ -n "$VER" ] && [ -f wp-load.php ] && rm -rf wp-admin wp-includes && \
  wp core download --version="$VER" --skip-content --force
wp core verify-checksums --include-root

La seconda riga cancella qualcosa solo se è stata trovata una versione e ci si trova nella root di WordPress. --include-root (WP-CLI 2.8 o successivo) elenca anche i file sconosciuti nella cartella principale.

Plugin e temi. Sostituire ogni cartella di plugin e tema con una copia nuova da WordPress.org o dall'area download del fornitore. Per i plugin di WordPress.org, wp plugin install <slug> --force sovrascrive la copia installata; wp plugin verify-checksums --all segnala poi i file modificati e aggiunti. Eliminare tutto ciò che non si usa e non reinstallare mai da una copia «nulled».

Upload. Gli upload non si possono reinstallare, quindi vanno ispezionati: cercare file PHP con find wp-content/uploads -type f -iname '*.php', confrontare la cartella con un backup precedente all'infezione e rimuovere tutto ciò che non è un file multimediale.

Configurazione e drop-in. Controllare a mano wp-config.php, .htaccess, .user.ini, wp-content/mu-plugins e i drop-in come object-cache.php.

Database. Il malware si annida anche in articoli, opzioni, utenti ed eventi pianificati:

wp user list --role=administrator --skip-plugins --skip-themes
wp option get siteurl && wp option get home
wp db search '<script' --all-tables
wp cron event list --fields=hook,next_run_relative,recurrence

wp db search trova anche script legittimi, come gli snippet degli strumenti di analytics. Amministratori sconosciuti, articoli di spam e opzioni iniettate vanno eliminati solo dopo averli controllati uno per uno.

Passaggio 5: cambiare tutte le credenziali e i salt

Il presupposto è che l'attaccante abbia letto wp-config.php e ogni segreto memorizzato sul server. Vanno quindi cambiati:

• tutti gli account WordPress con diritti di amministratore o editore, revocando le password per le applicazioni (Application Passwords) che non si riconoscono;
• pannello di controllo dell'hosting, SFTP/FTP e SSH, comprese le chiavi SSH autorizzate;
• la password del database, contemporaneamente presso l'hosting e in wp-config.php;
• le chiavi API salvate nei plugin: pagamenti, SMTP, storage dei backup, CDN;
• l'account email che riceve le richieste di reimpostazione della password degli amministratori.

Poi vanno sostituite le chiavi di autenticazione e i salt in wp-config.php. Secondo la documentazione per sviluppatori di WordPress, cambiarli invalida tutti i cookie esistenti: chiunque deve accedere di nuovo, compreso un attaccante con una sessione rubata.

wp config shuffle-salts

Follow-up: rafforzare, monitorare, documentare

Passaggio 6: mettere in sicurezza il sito

• Aggiornare core, plugin e temi; la nostra guida ai plugin WordPress vulnerabili spiega come fare l'inventario e gestire gli aggiornamenti automatici.
• Aggiungere define( 'DISALLOW_FILE_EDIT', true ); a wp-config.php per rimuovere gli editor di file dalla bacheca. DISALLOW_FILE_MODS va oltre e blocca anche gli aggiornamenti dalla bacheca e quelli automatici: va usato solo se gli aggiornamenti vengono gestiti in altro modo.
• Attivare l'autenticazione a due fattori per ogni amministratore. Il core di WordPress non la include.
• Bloccare l'esecuzione di PHP negli upload. Con Apache 2.4, in wp-content/uploads/.htaccess:

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

Con nginx, la regola va inserita prima del blocco generico location ~ \.php$, perché nginx applica la prima location con espressione regolare che corrisponde:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ { deny all; }

Eseguire nginx -t prima di ricaricare la configurazione, poi verificare che le immagini vengano ancora caricate.

Passaggio 7: monitorare e chiedere le revisioni

Nelle settimane successive il sito va tenuto d'occhio: ripetere i controlli dei checksum e degli upload, confrontare gli elenchi dei file con lo stato pulito e leggere i log di accesso. Se l'infezione si ripresenta, il punto d'ingresso è ancora aperto: è il momento di chiamare un professionista.

Security Audit & Compliance di secaudit.eu può dare una mano in questa fase: mantiene una baseline di integrità dei file, verifica i checksum del core e cerca amministratori nascosti, eventi cron sospetti e spam SEO nascosto. Rileva e segnala, ma non ripulisce il sito.

Se Google ha segnalato il sito, a pulizia completata aprire Problemi di sicurezza in Search Console, scegliere Richiedi revisione e descrivere gli interventi effettuati. Secondo Google le revisioni richiedono circa un giorno per il phishing, alcuni giorni per il malware e fino a diverse settimane per lo spam inserito tramite hacking. La rimozione dalle blocklist di posta va chiesta solo quando lo spam si è fermato.

Passaggio 8: valutare la violazione ai sensi del GDPR e documentarla

Questo passaggio è l'ultimo dell'elenco, ma il suo conto alla rovescia parte dal primo giorno. Se dati dei clienti, account utente, messaggi dei moduli od ordini sono stati esposti, modificati o resi indisponibili, l'attacco costituisce di norma una violazione dei dati personali. Il GDPR, il Regolamento generale sulla protezione dei dati, impone allora di notificarla all'autorità di controllo (in Italia il Garante per la protezione dei dati personali) senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui se ne è venuti a conoscenza, a meno che sia improbabile che la violazione presenti un rischio (art. 33). Se il rischio per le persone è elevato, vanno informate anche loro (art. 34).

Qualunque sia la decisione, vanno documentati le circostanze, le conseguenze e i provvedimenti adottati per porvi rimedio: l'art. 33, paragrafo 5, lo richiede per ogni violazione, anche per quelle non notificate. La nostra guida alla notifica delle violazioni entro 72 ore guida passo per passo nella valutazione. Se l'organizzazione rientra nell'ambito della direttiva NIS2, anche gli incidenti significativi richiedono un preallarme entro 24 ore; i dettagli vanno verificati nella legge nazionale di recepimento della NIS2.

Domande frequenti

Un plugin di sicurezza può rimuovere il malware al posto mio?

Alcuni strumenti offrono la pulizia automatica del malware noto. Nessuno, però, può dire con certezza come è entrato l'attaccante o quali password ha sottratto: i passaggi 3, 5 e 6 restano compito di chi gestisce il sito.

Reinstallare il core di WordPress cancella i contenuti?

No. Articoli, pagine e impostazioni si trovano nel database e, con --skip-content, plugin, temi e upload non vengono toccati. Vengono sostituiti solo i file del core in wp-admin, wp-includes e nella cartella principale; wp-config.php resta com'è.

Questo articolo ha carattere informativo generale e non costituisce consulenza legale.