Malware nel database WordPress: come trovarlo e rimuoverlo<

Quando un sito WordPress viene compromesso, il malware non si trova necessariamente soltanto nei file PHP. Codice JavaScript, redirect, link spam, utenti amministratori abusivi e altri contenuti malevoli possono essere memorizzati direttamente nel database WordPress.

È una situazione particolarmente insidiosa perché puoi sostituire i file del core, reinstallare WordPress, controllare plugin e tema e continuare comunque a vedere redirect, spam SEO o contenuti indesiderati.

In questi casi bisogna verificare anche il database e, soprattutto, capire quali record sono realmente compromessi prima di eliminarli.

Una cancellazione eseguita senza analizzare il contenuto può infatti danneggiare configurazioni del tema, plugin, widget, page builder o altre funzionalità del sito.

Se il sito è già compromesso e preferisci evitare modifiche manuali al database, puoi richiedere il nostro servizio di rimozione malware WordPress, che comprende l’analisi dell’infezione e la verifica sia dei file sia del database.

Il malware può davvero trovarsi nel database WordPress?

Sì. Il database contiene gran parte delle informazioni utilizzate da WordPress per costruire dinamicamente il sito.

Al suo interno vengono memorizzati, tra le altre cose:

• pagine e articoli;
• impostazioni WordPress;
• configurazioni dei plugin;
• utenti;
• metadati;
• widget;
• contenuti dei page builder;
• transient;
• eventi programmati;
• URL e altre configurazioni del sito.

Se un attaccante riesce a modificare questi dati può inserire contenuti che WordPress recupererà successivamente dal database e utilizzerà per generare le pagine.

Questo significa che il file PHP responsabile dell’attacco può anche essere eliminato mentre il contenuto precedentemente inserito nel database rimane presente.

Quali sintomi possono indicare malware nel database?

Non esiste un singolo comportamento che dimostri automaticamente che il database sia infetto. Alcuni sintomi, però, rendono questa verifica particolarmente importante.

• Link spam presenti nel codice HTML delle pagine.
• Testi relativi a casinò, scommesse, farmaci o altri argomenti estranei al sito.
• Redirect che continuano dopo aver sostituito i file WordPress.
• JavaScript sconosciuto caricato nelle pagine.
• Popup che ricompaiono dopo una prima bonifica.
• Nuovi amministratori WordPress non riconosciuti.
• Pagine spam indicizzate da Google.
• Contenuti invisibili al visitatore ma presenti nel sorgente HTML.
• Malware che sembra tornare dopo essere stato eliminato.

Questi segnali non devono essere utilizzati da soli per cancellare record dal database. Servono invece per stabilire cosa cercare e dove approfondire l’analisi.

Dove può nascondersi il malware nel database WordPress?

La struttura può cambiare notevolmente da un sito all’altro. Plugin, temi, WooCommerce e page builder possono aggiungere tabelle proprie oppure utilizzare le tabelle standard di WordPress.

Ci sono comunque alcune aree che meritano particolare attenzione durante un’analisi.

1. Malware nella tabella wp_options

wp_options è una delle tabelle più importanti da controllare.

Contiene numerose impostazioni utilizzate da WordPress, temi e plugin e può quindi diventare un punto interessante per nascondere:

• JavaScript iniettato;
• URL esterni;
• redirect;
• codice HTML;
• opzioni create dal malware;
• payload codificati o offuscati;
• configurazioni utilizzate per mantenere l’infezione.

Particolare attenzione deve essere dedicata alle opzioni caricate automaticamente, ma una voce con autoload attivo non è automaticamente malevola.

Numerosi plugin legittimi utilizzano normalmente questo meccanismo.

Come cercare contenuti sospetti in wp_options

Con phpMyAdmin puoi utilizzare la funzione di ricerca della tabella oppure eseguire query esclusivamente diagnostiche.

Ad esempio, per cercare la presenza di tag script:

SELECT option_id, option_name
FROM wp_options
WHERE option_value LIKE '%<script%';

Oppure, se durante l’analisi del sito hai già individuato un dominio sospetto:

SELECT option_id, option_name
FROM wp_options
WHERE option_value LIKE '%dominio-sospetto.example%';

Queste query non modificano il database: servono soltanto a individuare possibili record da analizzare.

È importante non considerare automaticamente malware ogni risultato. Plugin per statistiche, advertising, cookie, chat, tracking o personalizzazioni possono legittimamente memorizzare JavaScript e URL esterni.

2. Malware nella tabella wp_posts

La tabella wp_posts non contiene soltanto gli articoli del blog.

WordPress la utilizza per diversi tipi di contenuto e, a seconda della configurazione del sito, un’infezione può inserire codice direttamente nel campo post_content.

È uno dei punti da controllare quando nel sito compaiono:

• link SEO spam;
• iframe;
• script;
• testi nascosti;
• blocchi HTML estranei;
• contenuti che il proprietario non ha mai pubblicato.

SEO spam nascosto nelle pagine WordPress

Una tecnica particolarmente subdola consiste nell’inserire link e testi nella pagina per poi nasconderli graficamente.

Per esempio, durante una compromissione si possono incontrare strutture simili a:

<div style="position:absolute; left:-9999px;">
    contenuto spam...
</div>

Il visitatore può non vedere nulla di anomalo, ma il contenuto continua a essere presente nell’HTML generato dalla pagina.

È una situazione che abbiamo riscontrato anche durante interventi reali di bonifica WordPress: il sito appariva visivamente normale, mentre il database conteneva blocchi dedicati a casinò e scommesse nascosti all’interno delle pagine.

Come cercare contenuti sospetti in wp_posts

Una prima ricerca diagnostica può essere:

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%';

Se invece hai già individuato una parola o un dominio appartenente all’infezione, la ricerca diventa molto più precisa:

SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%dominio-sospetto.example%';

Lo stesso metodo può essere utilizzato per cercare una particolare stringa di spam rilevata nel sorgente della pagina.

Questo è generalmente più efficace rispetto alla ricerca indiscriminata di parole come script o iframe, che possono comparire anche in contenuti perfettamente legittimi.

3. Malware in wp_postmeta

La tabella wp_postmeta merita altrettanta attenzione.

Molti plugin e temi utilizzano i metadati per memorizzare configurazioni associate alle pagine. Anche alcuni page builder possono utilizzare strutture complesse salvate nel database.

Di conseguenza, il contenuto malevolo potrebbe non essere presente direttamente in post_content.

Può trovarsi invece all’interno di un valore memorizzato in meta_value.

Una ricerca per un dominio malevolo già identificato può essere eseguita con:

SELECT post_id, meta_key
FROM wp_postmeta
WHERE meta_value LIKE '%dominio-sospetto.example%';

4. Elementor e altri page builder possono nascondere il malware nel database

Questo è un aspetto che spesso rende più complicata la bonifica.

Quando una pagina viene costruita con Elementor o con un altro page builder, ciò che visualizzi nell’editor non corrisponde necessariamente a un semplice blocco HTML facilmente individuabile nella tabella wp_posts.

La struttura della pagina può essere memorizzata attraverso metadati e dati strutturati.

Di conseguenza, uno script o un link spam potrebbe trovarsi all’interno di:

• widget HTML;
• widget di testo;
• metadati della pagina;
• template;
• header e footer personalizzati;
• impostazioni globali del page builder.

Prima di eliminare direttamente una riga dal database bisogna quindi capire a quale componente appartiene.

5. Utenti amministratori creati dall’attaccante

Un sito compromesso deve essere controllato anche dal punto di vista degli account.

Le tabelle coinvolte sono principalmente:

• wp_users;
• wp_usermeta.

Un attaccante che riesce a creare un nuovo amministratore potrebbe mantenere un accesso legittimo al backend anche dopo la rimozione dei file malevoli.

Per questo motivo bisogna verificare tutti gli utenti con privilegi amministrativi e confrontarli con gli account realmente autorizzati.

Non è sufficiente guardare soltanto il nome utente. Devono essere controllati anche indirizzo email, data di registrazione, ruolo e coerenza dell’account con la gestione reale del sito.

6. Tabelle create dai plugin

Limitare l’analisi alle sole tabelle standard può essere un errore.

Plugin di redirect, advertising, snippet, page builder, sicurezza, form, cache e altri componenti possono creare proprie tabelle oppure memorizzare codice e URL nelle loro impostazioni.

Se durante l’analisi individui una stringa chiaramente appartenente al malware, può essere utile cercarla nell’intero database invece di concentrarsi soltanto su wp_options e wp_posts.

Attenzione ai dati serializzati di WordPress

Questo è uno dei motivi principali per cui sconsigliamo di effettuare sostituzioni massive direttamente con query SQL senza conoscere la struttura dei dati.

WordPress, temi e plugin possono memorizzare array e altre strutture sotto forma di dati serializzati.

In una stringa serializzata vengono memorizzate anche informazioni sulla lunghezza dei valori. Modificare manualmente una parte della stringa senza aggiornare correttamente la serializzazione può corrompere l’intero valore.

Il risultato può essere la perdita delle impostazioni di un plugin, di un widget, del tema o di altri componenti.

Per questo una bonifica professionale non dovrebbe seguire la logica:

“trovo una stringa sospetta → faccio DELETE”.

Il processo corretto è:

trovo la stringa → identifico il record → verifico quale componente lo utilizza → stabilisco se è realmente malevolo → scelgo il metodo più sicuro per rimuoverlo.

Prima di modificare il database: fai sempre un backup

Prima di eliminare o modificare qualsiasi record è indispensabile creare un’esportazione completa del database.

Con phpMyAdmin puoi utilizzare la funzione Esporta e salvare una copia SQL.

Se disponi di WP-CLI puoi utilizzare:

wp db export database-prima-bonifica.sql

È utile identificare chiaramente questo backup come copia precedente alla bonifica e potenzialmente infetta, in modo da non confonderlo in futuro con un backup pulito.

Il backup non serve soltanto contro un errore umano. Durante l’analisi può diventare anche una fotografia dello stato dell’infezione utile per confrontare i dati prima e dopo l’intervento.

Wordfence può trovare malware nel database?

Gli scanner di sicurezza sono estremamente utili, soprattutto per individuare file modificati, firme malware, backdoor e vulnerabilità.

Non bisogna però interpretare una scansione senza segnalazioni come prova assoluta che ogni dato memorizzato nel database sia pulito.

Un link spam inserito nel contenuto di una pagina, un widget HTML compromesso o un valore appartenente a un page builder possono richiedere una verifica specifica del database e del sorgente generato dal sito.

Per questo durante una bonifica è importante combinare scanner automatici e analisi manuale.

Perché il malware nel database può tornare dopo averlo eliminato?

Questo è uno dei punti più importanti dell’intera bonifica.

Puoi eliminare perfettamente una stringa malevola dal database e ritrovarla nuovamente qualche ora dopo.

In quel caso il database potrebbe essere soltanto la destinazione dell’infezione, non la sua origine.

Una backdoor PHP, un plugin compromesso, un account amministratore abusivo, un evento programmato o un altro meccanismo presente nell’installazione potrebbe riscrivere periodicamente il payload nel database.

Per questo motivo una vera analisi di un sito WordPress hackerato non deve separare completamente filesystem e database.

Bisogna controllare entrambi e capire quale componente ha permesso all’infezione di comparire e, soprattutto, cosa potrebbe consentirle di tornare.

Nella seconda parte vedremo come procedere alla rimozione in sicurezza, come utilizzare phpMyAdmin e WP-CLI, cosa controllare dopo la pulizia, come individuare una possibile reinfezione e quali errori possono danneggiare seriamente il database WordPress.

Come rimuovere malware dal database WordPress in sicurezza

Una volta individuato un record sospetto, la fase più delicata è stabilire come rimuoverlo senza danneggiare il sito.

Non esiste una query universale in grado di ripulire automaticamente qualsiasi database WordPress. La struttura dell’infezione cambia da sito a sito e la stessa stringa che appare sospetta può appartenere a un plugin legittimo, a un page builder oppure a una configurazione realmente compromessa.

Prima di intervenire bisogna quindi conoscere almeno tre elementi:

• quale tabella contiene il contenuto malevolo;
• quale record è coinvolto;
• quale componente WordPress utilizza quel record.

Solo dopo questa verifica è possibile scegliere se correggere il contenuto dall’amministrazione WordPress, modificare direttamente il database oppure rimuovere completamente il record.

1. Individua una firma riconoscibile del malware

Cercare genericamente parole come script, iframe o base64 può produrre moltissimi falsi positivi.

È molto più efficace partire da un elemento già osservato durante l’analisi del sito, ad esempio:

• un dominio verso cui viene effettuato un redirect;
• un URL presente nei link spam;
• una porzione particolare di JavaScript;
• una classe CSS insolita;
• una parola appartenente al contenuto spam;
• un nome utilizzato da un file o da un payload individuato nel filesystem.

Supponiamo, per esempio, di avere identificato nel sorgente della pagina il dominio:

dominio-sospetto.example

Questa stringa diventa un indicatore molto più preciso da cercare nel database rispetto a termini PHP o JavaScript generici.

2. Cerca l’indicatore nell’intero database

Quando non sai ancora in quale tabella sia memorizzato il payload, limitarsi a wp_posts può non essere sufficiente.

Il contenuto potrebbe trovarsi in:

• wp_posts;
• wp_postmeta;
• wp_options;
• tabelle create dal tema;
• tabelle create dai plugin;
• dati utilizzati da un page builder.

phpMyAdmin permette di effettuare una ricerca su più tabelle. Questa funzione può essere particolarmente utile quando possiedi una stringa precisa ma non conosci ancora la posizione del record.

Ricorda inoltre che il prefisso wp_ è soltanto quello predefinito. Un’installazione può utilizzare un prefisso differente, quindi le query devono essere adattate alla struttura effettiva del database.

3. Analizza il record prima di modificarlo

Una corrispondenza non equivale automaticamente a un’infezione.

Prima di modificare il dato bisogna verificare:

• nome della tabella;
• ID del record;
• nome dell’opzione o della meta key;
• contenuto completo del valore;
• pagina, plugin o componente associato;
• eventuale presenza di dati serializzati o strutturati.

Se, per esempio, un dominio sospetto compare in wp_postmeta, bisogna utilizzare il relativo post_id per capire a quale pagina o contenuto appartiene.

Questa fase permette di distinguere una vera iniezione da una stringa legittima memorizzata da WordPress o da un plugin.

4. Rimuovere malware da wp_posts

Quando il contenuto malevolo è presente nel campo post_content, spesso il metodo più sicuro consiste nell’identificare la pagina interessata e correggerla attraverso l’editor WordPress.

Questo approccio è particolarmente utile quando l’infezione riguarda soltanto una porzione di contenuto e il resto della pagina deve essere conservato.

Una query diagnostica può aiutare a identificare i contenuti interessati:

SELECT ID, post_title, post_type, post_status
FROM wp_posts
WHERE post_content LIKE '%dominio-sospetto.example%';

Una volta ottenuto l’ID, è possibile controllare direttamente la pagina corrispondente.

Non consigliamo di eseguire un comando del tipo:

DELETE FROM wp_posts
WHERE post_content LIKE '%dominio-sospetto.example%';

Una query simile potrebbe infatti eliminare l’intera pagina o l’intero articolo, non soltanto la parte malevola.

È uno degli errori più pericolosi durante una bonifica eseguita senza conoscere la struttura del database.

5. Rimuovere malware da wp_postmeta

La bonifica di wp_postmeta richiede ancora maggiore attenzione.

Il campo meta_value può contenere semplici valori testuali ma anche JSON, configurazioni complesse o dati serializzati.

Prima di modificare una riga sospetta puoi identificarla con:

SELECT meta_id, post_id, meta_key
FROM wp_postmeta
WHERE meta_value LIKE '%dominio-sospetto.example%';

Successivamente bisogna determinare a cosa corrisponde post_id e quale componente utilizza meta_key.

Se il dato appartiene a Elementor o a un altro page builder, una modifica manuale eseguita direttamente con phpMyAdmin potrebbe compromettere la struttura della pagina.

6. Come pulire un’infezione Elementor nel database

Elementor merita un’attenzione particolare perché le informazioni utilizzate per costruire una pagina possono essere memorizzate in strutture complesse.

Durante un’infezione può capitare di trovare:

• un widget HTML aggiunto dall’attaccante;
• un link spam inserito in un widget esistente;
• testo nascosto attraverso CSS;
• JavaScript aggiunto a una sezione;
• contenuti inseriti in header o footer costruiti con Elementor.

Quando possibile, dopo aver identificato la pagina e il widget interessato, è preferibile rimuovere il contenuto attraverso Elementor invece di manipolare direttamente la struttura memorizzata nel database.

Dopo la modifica è opportuno rigenerare i file e i dati CSS di Elementor e svuotare le eventuali cache utilizzate dal sito.

7. Come intervenire su wp_options

Una voce sospetta in wp_options deve essere analizzata con particolare cautela perché potrebbe influire sull’intero sito.

Per visualizzare il record completo:

SELECT option_id, option_name, option_value, autoload
FROM wp_options
WHERE option_value LIKE '%dominio-sospetto.example%';

Prima di eliminarlo bisogna stabilire chi ha creato quell’opzione.

Il nome dell’opzione può fornire un’indicazione sul plugin o sul tema che la utilizza. Se invece appare completamente estraneo all’installazione e contiene un payload già identificato come malevolo, il livello di sospetto aumenta considerevolmente.

Anche in questo caso, però, la cancellazione dovrebbe essere eseguita soltanto dopo aver creato un backup e aver verificato che l’opzione non faccia parte di una struttura necessaria al sito.

8. Controlla gli utenti amministratori

La pulizia del database non riguarda soltanto script e link.

Controlla da Utenti → Tutti gli utenti ogni account con privilegi amministrativi.

Se trovi un amministratore che non riconosci, non limitarti a eliminarlo.

La presenza dell’account indica che qualcuno potrebbe aver avuto privilegi sufficienti per modificare il sito. È quindi necessario approfondire anche:

• file WordPress;
• plugin installati;
• tema;
• credenziali;
• sessioni attive;
• eventuali altre backdoor.

Dopo la bonifica è inoltre consigliabile modificare le credenziali amministrative e rigenerare le chiavi di autenticazione e i salt presenti in wp-config.php, così da invalidare le sessioni esistenti.

9. Controlla cron e attività programmate

Se il malware ricompare nel database a intervalli regolari, bisogna verificare anche le attività programmate.

WordPress utilizza WP-Cron per eseguire operazioni automatiche. Plugin e temi possono registrare eventi perfettamente legittimi, ma un sito compromesso può contenere anche attività create abusivamente.

Il semplice fatto che un evento Cron abbia un nome sconosciuto non dimostra che sia malware.

Bisogna verificare quale componente lo ha registrato e cosa viene eseguito.

10. Controlla il filesystem prima di dichiarare pulito il database

Questo passaggio è fondamentale.

Se una backdoor PHP continua a essere presente nel filesystem, può reinserire il malware nel database dopo la pulizia.

Devono quindi essere controllate almeno le aree più sensibili dell’installazione:

• root WordPress;
• wp-admin;
• wp-includes;
• wp-content/plugins;
• wp-content/themes;
• wp-content/uploads;
• wp-content/mu-plugins;
• wp-config.php;
• .htaccess.

Particolare attenzione va prestata ai file PHP presenti in directory nelle quali normalmente ci si aspetterebbero soprattutto immagini o altri file caricati.

La presenza di PHP in uploads non costituisce da sola una prova di malware, ma merita una verifica.

11. Reinstallare WordPress pulisce il database?

No.

La reinstallazione del core sostituisce principalmente i file standard di WordPress. Non elimina automaticamente:

• contenuti compromessi in wp_posts;
• payload presenti in wp_postmeta;
• opzioni malevole in wp_options;
• amministratori abusivi;
• dati compromessi creati dai plugin;
• backdoor presenti in wp-content.

Reinstallare il core può essere una delle operazioni della bonifica, ma non deve essere confusa con una rimozione completa del malware WordPress.

12. phpMyAdmin o WP-CLI: quale utilizzare?

Entrambi possono essere utili, ma rispondono a esigenze differenti.

phpMyAdmin

È particolarmente comodo quando vuoi:

• esaminare manualmente un record;
• navigare tra le tabelle;
• eseguire una ricerca mirata;
• visualizzare il contenuto completo di un’opzione;
• esportare rapidamente il database.

WP-CLI

È molto utile quando hai accesso SSH e devi lavorare in maniera più strutturata sull’installazione.

Per esempio, puoi esportare il database:

wp db export backup-prima-bonifica.sql

oppure controllare gli amministratori:

wp user list --role=administrator

Puoi anche esaminare gli eventi Cron:

wp cron event list

Lo strumento utilizzato è meno importante del metodo: prima identificare, poi verificare, infine modificare.

13. Cambia le credenziali dopo la bonifica

Quando il sito è stato compromesso, bisogna considerare la possibilità che alcune credenziali siano state esposte.

Dopo aver eliminato le backdoor e gli altri meccanismi di persistenza, è opportuno modificare almeno:

• password degli amministratori WordPress;
• credenziali FTP/SFTP;
• password del pannello hosting;
• password del database, quando necessario;
• altre credenziali tecniche conservate nell’ambiente compromesso.

L’ordine è importante: cambiare tutte le password mentre una backdoor è ancora attiva potrebbe non risolvere il problema.

14. Aggiorna WordPress, plugin, tema e PHP

Terminata la bonifica, bisogna ridurre la superficie di attacco.

Verifica quindi:

• versione WordPress;
• plugin installati;
• tema attivo e temi inutilizzati;
• versione PHP;
• componenti abbandonati o non più supportati.

I plugin e i temi inutilizzati dovrebbero essere rimossi completamente, non soltanto disattivati.

Se vuoi approfondire questo aspetto puoi leggere la nostra guida su perché WordPress viene hackerato.

Come verificare che il database WordPress sia realmente pulito

La scomparsa del sintomo iniziale non è sufficiente.

Dopo la bonifica è opportuno ripetere le ricerche utilizzate durante la diagnosi.

Se avevi trovato un dominio malevolo, cercalo nuovamente nell’intero database.

Se avevi individuato una particolare stringa SEO spam, verifica che non sia presente in altre pagine o metadati.

Controlla inoltre:

• sorgente HTML delle pagine precedentemente compromesse;
• utenti amministratori;
• filesystem;
• error log;
• eventi Cron;
• frontend da utente non autenticato;
• versione mobile del sito;
• eventuali URL spam già conosciuti.

Controlla anche Google Search Console

Un’infezione SEO può lasciare conseguenze anche dopo la bonifica tecnica.

Google potrebbe aver già scoperto URL o contenuti generati durante la compromissione.

Dopo aver ripulito il sito è quindi utile controllare Google Search Console per verificare:

• eventuali problemi di sicurezza segnalati;
• URL sconosciuti indicizzati;
• pagine spam;
• anomalie nell’indicizzazione;
• URL che continuano a comparire nonostante non esistano più.

La bonifica tecnica del sito e la normalizzazione dell’indicizzazione sono due fasi collegate, ma non sempre avvengono contemporaneamente.

Malware eliminato ma continua a tornare: cosa controllare

Se dopo qualche ora o qualche giorno ritrovi la stessa stringa nel database, non continuare semplicemente a cancellarla.

La ricomparsa è un’informazione diagnostica molto importante.

Controlla in particolare:

• backdoor ancora presenti;
• file PHP modificati;
• mu-plugins sconosciuti;
• plugin vulnerabili;
• tema compromesso;
• account amministrativi;
• WP-Cron;
• credenziali compromesse;
• altre installazioni WordPress nello stesso hosting.

Se sullo stesso account hosting sono presenti più siti, anche le altre installazioni devono essere controllate. Un secondo sito compromesso può diventare una sorgente di reinfezione.

Errori da evitare durante la pulizia del database

• Cancellare tutti i record contenenti <script>.
  Molti script possono essere legittimi e utilizzati da plugin, tracking o altre funzionalità.
• Eseguire un DELETE direttamente su wp_posts.
  Potresti eliminare intere pagine invece del solo codice malevolo.
• Fare sostituzioni massive nei dati serializzati.
  Una modifica errata può rendere il valore inutilizzabile.
• Pulire il database ignorando i file.
  Una backdoor ancora attiva può reinserire il payload.
• Ripristinare un backup senza sapere quando è iniziata l’infezione.
  Il backup potrebbe essere già compromesso.
• Considerare pulito il sito perché Wordfence non segnala più problemi.
  Una scansione automatica è un elemento della verifica, non la prova definitiva dell’assenza di qualsiasi compromissione.
• Eliminare tabelle sconosciute soltanto perché non iniziano con nomi familiari.
  Molti plugin creano tabelle proprie perfettamente legittime.

Procedura completa per bonificare un database WordPress infetto

Riassumendo, un intervento strutturato dovrebbe seguire questo ordine:

1. documentare i sintomi dell’infezione;
2. creare una copia completa di file e database;
3. individuare indicatori specifici del malware;
4. cercarli nelle tabelle WordPress;
5. identificare i record e i componenti coinvolti;
6. controllare eventuali dati serializzati o strutturati;
7. rimuovere il contenuto malevolo con il metodo meno invasivo;
8. analizzare contemporaneamente il filesystem;
9. eliminare eventuali backdoor e meccanismi di persistenza;
10. controllare utenti e attività programmate;
11. aggiornare i componenti vulnerabili o obsoleti;
12. modificare le credenziali interessate;
13. ripetere le scansioni e le ricerche nel database;
14. monitorare il sito nei giorni successivi.

Quando è meglio non modificare manualmente il database

La modifica manuale è sconsigliata quando non riesci a determinare con sicurezza la funzione del record individuato.

Serve particolare cautela quando il valore appartiene a:

• Elementor o altri page builder;
• WooCommerce;
• plugin complessi;
• configurazioni del tema;
• dati serializzati;
• array o JSON di grandi dimensioni.

In questi casi una cancellazione apparentemente semplice può provocare problemi che emergono soltanto successivamente.

FAQ sul malware nel database WordPress

Come faccio a sapere se il database WordPress contiene malware?

Bisogna cercare indicatori concreti dell’infezione nelle tabelle e confrontarli con ciò che viene generato dal sito. Link spam, domini sconosciuti, script, amministratori abusivi e contenuti che ricompaiono sono segnali da approfondire, ma ogni risultato deve essere verificato prima della rimozione.

Quali tabelle WordPress vengono infettate più spesso?

Durante un’analisi vengono controllate frequentemente wp_options, wp_posts, wp_postmeta, wp_users e wp_usermeta. Tuttavia, plugin e temi possono utilizzare tabelle personalizzate, quindi non esiste un elenco valido per ogni installazione.

Posso eliminare il malware direttamente con phpMyAdmin?

Sì, ma soltanto dopo aver identificato con precisione il record e aver creato un backup. Modificare direttamente il database senza conoscere la struttura del dato può danneggiare pagine, plugin o configurazioni.

Reinstallare WordPress elimina il malware dal database?

No. La reinstallazione del core non ripulisce automaticamente le tabelle del database e non elimina le eventuali backdoor presenti in wp-content.

Wordfence può dichiarare pulito un sito che contiene ancora SEO spam?

Una scansione senza segnalazioni non deve essere considerata da sola una garanzia assoluta. Contenuti compromessi memorizzati nelle pagine, nei metadati o nelle strutture di un page builder possono richiedere controlli manuali.

Perché il malware ricompare dopo aver pulito il database?

Una delle possibili spiegazioni è la presenza di un meccanismo di persistenza ancora attivo, come una backdoor, un file compromesso, un account amministrativo abusivo o un’attività programmata. In questi casi il database viene nuovamente contaminato dopo la pulizia.

È sufficiente ripristinare un vecchio backup?

Dipende dalla data in cui è iniziata la compromissione. Se il malware era già presente quando è stato creato il backup, il ripristino può riportare online anche l’infezione.

Bonifica professionale del database WordPress

Quando un’infezione coinvolge contemporaneamente file e database, la priorità non è semplicemente cancellare ciò che appare sospetto.

Bisogna ricostruire il funzionamento della compromissione: cosa è stato modificato, quale componente genera il contenuto malevolo e quale meccanismo potrebbe permettergli di tornare.

WpSupporto esegue interventi di rimozione malware WordPress con analisi dei file, del database e degli elementi utilizzati per mantenere la compromissione.

Dopo la bonifica è inoltre importante intervenire sulle cause di rischio individuate e applicare misure di protezione adeguate. Puoi approfondire questo passaggio nella guida su come mettere in sicurezza WordPress.

Se il tuo sito continua a mostrare link spam, redirect, codice sconosciuto oppure il malware ricompare dopo essere stato eliminato, puoi contattare WpSupporto indicando il dominio e i sintomi riscontrati. Prima dell’intervento analizziamo il problema per capire se la compromissione interessa i file, il database o entrambi.