Quand un site WordPress se “comporte bizarrement”, la tentation est de courir vers les fichiers: .php modifiés, thème touché, répertoires incompréhensibles. C’est souvent justifié, mais j’ai déjà vu l’inverse: le code PHP semblait propre, et pourtant le site injectait des redirections ou des scripts à partir de données stockées dans la base. Dans ce cas, la vraie scène du crime se trouve dans les tables SQL.
Un nettoyage malware WordPress efficace commence donc par une vérification structurée des tables, sans se contenter de “tout supprimer” à l’aveugle. La base peut contenir du contenu malveillant, des options empoisonnées, des webhooks enregistrés, des identifiants créés de nulle part, ou des données qui déclenchent des injections au moment du rendu.
Voici une méthode pratique, centrée sur la vérification des tables SQL, avec des requêtes concrètes et les pièges qui font perdre du temps.
Comprendre ce que “infecté” veut dire dans une base WordPress
Dans WordPress, l’infection via SQL ne signifie pas seulement “une table contient du texte suspect”. Ça peut aussi vouloir dire:
- une option WordPress ajoutée avec une valeur qui exécute du comportement (par exemple un slug redirigé, une configuration de plugin, une chaîne qui sera traitée par un morceau de code), un champ de métadonnées qui déclenche une injection, une entrée dans wp_posts qui ressemble à du contenu normal, mais qui a des composants inhabituels, des tables créées en dehors du schéma WordPress, souvent avec un nom “tordu” (ou un préfixe inattendu), des utilisateurs ou rôles modifiés (wp users, wpusermeta), ou des routines programmées via wp_cron et des hooks stockés dans les options.
Le point important, c’est que la base peut être “contaminée” partiellement. J’ai déjà vu des sites où seule la table wp options portait la charge utile, et où toutes les autres tables étaient parfaitement propres. Inversement, une table wpposts légèrement altérée a pu suffire à déclencher une injection sur des pages précises.
Première lecture: repérer les tables à risque avant même les requêtes
Avant de lancer des requêtes, gagnez du temps en observant l’architecture réelle de votre base.
1) Vérifiez le préfixe des tables. Souvent, un site “classique” a wp_ comme préfixe, mais certains ont customisé. Le malware profite parfois du préfixe pour que les requêtes des attaquants restent simples, et il peut aussi en créer d’autres.
2) Regardez la liste des tables, puis repérez celles qui ne collent pas au schéma WordPress attendu. Selon les plugins installés, il peut y avoir des tables supplémentaires légitimes, mais le repérage initial reste utile.
3) Notez les tables contenant des “grosses” colonnes texte. Dans WordPress, ça concerne surtout wp options (autoload et optionvalue), wp posts (postcontent, guid), et les méta (wp postmeta, wpusermeta, wp_options si elle contient des structures particulières).
À ce stade, vous ne “prouvez” rien. Vous préparez une campagne de requêtes ciblées, ce qui réduit fortement le risque de générer trop de bruit.
Sauvegarde et plan de vérification, sans casser la base
Je recommande toujours de partir d’un dump de la base avant investigation, surtout si vous allez exécuter des requêtes de correction ou si vous envisagez de supprimer des lignes.
Le piège que j’ai vu plusieurs fois: le propriétaire du site supprime des options “suspectes”, puis découvre que la fonctionnalité du site dépendait de ces options, ou que le malware avait plusieurs points d’entrée. Mieux vaut d’abord identifier précisément quelles tables portent la charge utile.
Si vous avez accès à phpMyAdmin ou à un outil équivalent, commencez par exporter:
- un dump complet pour référence, et, au besoin, des exports ciblés (les tables suspectes) pour revenir en arrière rapidement.
Pendant la vérification, évitez les opérations destructrices. Votre objectif ici est de classifier les tables: suspectes, probablement normales, et à confirmer.
Travailler sur les tables typiquement utilisées pour l’injection
Le malware “SQL” a souvent des endroits préférés. Sur WordPress, les plus fréquents restent wp options, wpposts, wp postmeta, wpusermeta, wp users, et parfois wpcron.
wp_options: le terrain le plus courant
La table wp_options stocke une grande quantité de configuration et de données plugin. Un attaquant peut y injecter des valeurs qui déclenchent des comportements, parfois via un plugin compromis, parfois via du contenu qui sera interprété plus tard.
Voici des requêtes utiles pour repérer des valeurs contenant des motifs caractéristiques. L’idée est de chercher des chaînes qui n’ont pas leur place dans une valeur option “normale”.
Exemples de motifs à tester (à adapter à votre contexte): chaînes base64, appels à fonctions PHP dans des contenus, balises HTML inattendues, URLs d’exfiltration, scripts.
SELECT option_name, LEFT(option_value, 200) AS preview FROM wp_options WHERE option_value LIKE '%base64%' OR option_value LIKE '%eval(%' OR option_value LIKE '%base64_decode%' OR option_value LIKE '%