Quand un site WordPress “ralentit d’un coup”, la tentation est de regarder d’abord le thème, le caching, ou la bande passante. Pourtant, dans beaucoup d’incidents que j’ai vus en intervention, la cause réelle se cache derrière la base de données. Ce n’est pas une intuition vague. Les malwares ciblent souvent les tables, les options, les utilisateurs, et parfois même les fichiers de plugins ou de thèmes, puis ils en profitent pour garder une présence durable.
La désinfection WordPress ne se résume donc pas à “nettoyer un fichier”. Elle doit viser le couple indissociable code + base. Sinon, on supprime une porte d’entrée, et le script réapparaît par une autre. Dans ce billet, je vais détailler comment raisonner, quoi vérifier, et comment limiter les risques lors du nettoyage d’un site compromis, avec une attention particulière aux signaux dans la base de données.
Le piège classique : croire que tout se joue dans les fichiers
WordPress met à disposition des mécanismes qui facilitent l’attaque. Les plugins ajoutent des tables, des options, des hooks. Les thèmes stockent parfois des configurations dans wp_options. Les utilisateurs et rôles sont enregistrés côté base. Même si l’infection commence par un fichier modifié, elle finit souvent par une persistance en base.
Un exemple concret, fréquent dans les logs : un site qui redirige vers des pages frauduleuses uniquement pour certains pays ou à certaines heures. C’est rarement “un simple fichier mal placé”. La redirection conditionnelle, le masquage, ou la génération d’entrées cachées dans le back-office ressemblent davantage à des requêtes dynamiques pilotées depuis wp options, wpusermeta, ou des tables créées par le malware.
Autre signal, plus simple à détecter : dans phpMyAdmin (ou via un client MySQL), on voit des champs ou des valeurs qui ne correspondent à aucun plugin légitime, des entrées qui ne devraient pas exister, ou des comptes administrateurs créés sans intervention humaine.
La conclusion pratique est la suivante : si vous ne contrôlez pas la base de données, vous nettoyez souvent “le symptôme” et vous laissez vivre l’agent.
Comprendre ce que les malwares attaquent dans WordPress
Sans tomber dans le catalogue de signatures, il est utile de se concentrer sur des zones qui reviennent très souvent.
Dans la base de données, l’attaque cherche généralement trois objectifs.
D’abord, obtenir un accès persistant. Cela passe par la création d’un utilisateur avec des rôles élevés, ou par des paramètres stockés en base qui réactivent automatiquement du code malveillant au prochain chargement.
Ensuite, exécuter du code ou déclencher des comportements. Un malware peut stocker des charges utiles dans des options, puis les réinjecter via un hook, un shortcode, ou une routine déclenchée à un événement WordPress. Certaines campagnes utilisent même des champs stockés pour “servir” du contenu ou rediriger.
Enfin, maintenir l’opacité. Les malwares cherchent à masquer des entrées, à polluer les données, ou à rendre le diagnostic plus coûteux. C’est là que le nettoyage de la base devient plus délicat, car tout ce qui ressemble à du “bruit” n’est pas forcément malveillant.
L’enjeu est donc double : être méthodique pour trouver ce qui compte, et être prudent pour ne pas casser le site au moment du désinfectage.
Avant de toucher à la base : sauvegarde, fenêtre de risque et “rollback”
Le point le plus concret, souvent oublié sous pression, c’est le rollback. Si vous désinfectez la base et que le site ne remonte plus, vous devez pouvoir revenir en arrière sans improviser.
Avant toute opération sur la base, prévoyez https://gardewp.fr/ :
1) une sauvegarde complète de la base (idéalement un dump SQL)
2) une sauvegarde des fichiers (au minimum wp-content, et surtout si un plugin ou thème est suspect) 3) une stratégie de test sur une copie, pas directement en production si vous pouvez l’éviterDans beaucoup de contextes, je conseille de travailler sur un environnement de staging le temps du diagnostic. Même si le staging n’est pas parfait, il réduit fortement la probabilité de casser une intégration client.
Une autre précaution utile : figez le contexte pendant vos tests. Par exemple, si votre site est sous forte charge et que le trafic génère de nombreuses mises à jour, vous pouvez créer un bruit supplémentaire dans les tables. Dans un incident, un “arrêt” doux (mise en maintenance, ou au moins limitation du trafic) aide souvent à stabiliser les indices.
Les signaux qui orientent vers la base de données
Il existe des signes concrets, visibles sans outils sophistiqués.
Premier indice : des utilisateurs créés récemment, surtout avec un rôle d’administrateur. Même si le malware a pu modifier aussi les fichiers, la persistance via un compte est courante. Parfois, le compte n’a pas forcément un nom “bizarre”, et c’est ça qui trompe le plus.
Deuxième indice : des entrées inattendues dans wp_options. Les options sont conçues pour stocker des configurations, donc leur présence ne prouve rien à elle seule. En revanche, des options très longues, des valeurs qui contiennent des fragments de code, ou des dates de modification étrangement synchronisées avec le début des problèmes sont des pistes sérieuses.
Troisième indice : des tables additionnelles ou des colonnes ajoutées sans que vous les ayez demandées. WordPress, de base, n’ajoute pas de tables au hasard. Les plugins peuvent le faire, mais vous devez reconnaître l’origine. Si vous ne savez pas quel composant a créé une table, considérez que vous tenez peut-être un morceau du malware.
Quatrième indice : des journaux applicatifs ou système qui mentionnent des requêtes MySQL inhabituelles. Même sans analyser chaque requête, une hausse nette de certains patterns peut indiquer une exécution répétée de logique malveillante.
Enfin, un indice souvent “terrestre” : la console d’administration montre des comportements impossibles, pages dupliquées, modules qui réapparaissent après suppression, ou contenus injectés. WordPress peut réinjecter du contenu depuis la base, donc cela oriente votre investigation.
Une méthodologie réaliste de désinfection WordPress côté base
La désinfection WordPress n’est pas une recette unique, mais une démarche disciplinée.
L’idée est de découper en couches, comme on démonte une serrure pour comprendre quelle pièce est cassée. Si on commence par supprimer des tables “au hasard”, on peut retirer des données nécessaires à des plugins légitimes.
La démarche la plus sûre consiste à identifier, isoler, puis corriger, dans cet ordre.
1) Identifier ce qui est modifié ou ajouté
Commencez par établir une baseline.
Si vous avez une sauvegarde antérieure saine, comparez. Sinon, comparez l’état actuel à ce que vous savez de votre site : quels plugins sont installés, quels thèmes, quelles extensions ont été ajoutées récemment, et quelles mises à jour ont eu lieu.
Ensuite, ciblez les zones typiques : wp users, wpusermeta, wp options, et le préfixe réel de tables (par exemple wp). Beaucoup d’installations utilisent un préfixe différent, donc ne présumez pas.
Dans wp_users, cherchez des utilisateurs créés récemment, ou des comptes qui ne correspondent pas à votre gestion habituelle.
Dans wp_usermeta, repérez les métadonnées qui définissent des rôles, des sessions, ou des variables de configuration. Certaines valeurs sont binaires ou sérialisées, donc soyez attentif, tout ça n’est pas forcément du “code” au sens littéral, mais un malware peut stocker des structures sérialisées qui déclenchent ensuite du comportement.
Dans wp_options, le repère le plus utile est souvent la valeur elle-même. Elle peut contenir du code, des URLs de destination, des fragments de HTML injecté, ou des données sérialisées anormales.
2) Isoler les anomalies plutôt que tout supprimer
Une erreur fréquente est de vouloir “tout nettoyer” d’un coup. Sur WordPress, une partie du contenu injecté peut être isolée et supprimée, tandis que les options nécessaires au bon fonctionnement peuvent rester.
Par exemple, certains plugins de sécurité, de cache, ou de SEO enregistrent des options en base qui peuvent ressembler à des structures longues ou sérialisées. Ne confondez pas leur contenu légitime avec une charge utile.
Si vous voyez une option dont la clé est inattendue, ou une valeur qui contient des scripts, des fonctions, ou des marqueurs HTML d’un format incohérent pour votre site, vous avez une piste. Mais supprimez seulement ce que vous comprenez, ou ce que vous pouvez relier à l’incident.
3) Corriger la persistance, pas seulement la sortie visible
Le plus dur est de distinguer ce que le visiteur voit de ce qui déclenche le comportement.
Si le site redirige, la sortie visible est la redirection, mais la persistance peut être un plugin compromis, un code dans functions.php, un hook déclenché par une option, ou même un champ stocké dans la base qui alimente un rendu.
Dans la pratique, cela veut dire : même si vous corrigez l’affichage, tant que l’entrée malveillante reste en base, le comportement peut revenir.
C’est pour ça que la désinfection WordPress doit viser les “causes”, pas seulement les symptômes.
Liste pratique : vérifications rapides qui orientent vers une base compromise
Voici les premières vérifications que je fais quand un site semble compromis et que je dois décider où regarder en base. Elles peuvent se faire en une heure environ, selon l’accès dont vous disposez.
- Contrôler les comptes utilisateurs récents dans wp_users, surtout ceux avec rôle administrateur Examiner wp_options pour repérer des clés inattendues et des valeurs suspectes, en particulier celles qui contiennent du code ou des URL Rechercher des entrées dans wp_usermeta qui définissent des rôles ou des capacités au-delà de vos profils habituels Vérifier l’existence de tables supplémentaires ou de colonnes ajoutées sans lien clair avec vos plugins Vérifier l’état des préfixes réels des tables, car les malwares suivent parfois le schéma sans le même nom
Cette courte liste ne remplace pas une analyse plus poussée, mais elle donne un cap et évite de “tourner en rond” en ne fouillant que les fichiers.
Comment gérer les valeurs sérialisées, sans casser WordPress
Le sujet sérialisé est une source de casse classique. WordPress stocke beaucoup de données sous forme sérialisée. Quand on supprime une entrée sérialisée, ou quand on modifie une valeur sans respecter le format, WordPress peut planter ou afficher des erreurs.
C’est là qu’il faut un peu d’humilité : si vous n’êtes pas à l’aise avec le format sérialisé, mieux vaut supprimer une entrée que vous identifiez clairement comme malveillante, plutôt que de “trifouiller” au milieu d’une structure.
Deux principes m’ont évité des catastrophes :
1) ne modifiez que ce que vous pouvez justifier
2) testez après chaque changement significatif, idéalement sur une copieSi vous devez restaurer une option, la meilleure approche est de comparer avec une sauvegarde saine. Si vous n’avez pas de sauvegarde, vous pouvez parfois identifier la valeur attendue en la retrouvant dans un autre environnement (staging), mais cela suppose que vous avez la bonne version de plugins et de thèmes.
Distinguer malware et compatibilités de plugins
Il y a un piège mental très humain : tout ce qui paraît étrange est malveillant. C’est compréhensible, mais ça mène à des suppressions qui abîment des fonctionnalités.
Par exemple, certains plugins enregistrent des configurations longues, des champs HTML, ou des règles. Un plugin de traduction, de formulaire, ou de contenu dynamique peut aussi générer des structures stockées en base.
Le bon réflexe est de relier l’anomalie à un fait. Un utilisateur créé la veille, une option ajoutée au même moment, une table créée lors d’une installation récente, une URL apparue dans des options et qui correspond à la redirection observée. Sans corrélation temporelle ou fonctionnelle, vous avancez à l’aveugle.
Une méthode pragmatique consiste à noter trois colonnes sur vos anomalies : la clé ou la table, la valeur ou un extrait, et la date de modification si elle est disponible. Quand vous trouvez une cohérence, vous tenez une piste solide.
Le rôle des tables de logs et du “bruit” applicatif
Certains sites utilisent des plugins de logging ou des dumps. Dans ce cas, la base contient des tables qui grandissent, et le malware peut aussi s’en servir.
Si vous voyez une base très volumineuse, ce n’est pas forcément un signe d’infection. La base peut grossir pour des raisons légitimes : historique d’exports, révisions de contenu, tables créées par plugins, ou trafic qui augmente des enregistrements.
Dans un incident, ce qui compte, ce n’est pas la taille seule, c’est la présence d’éléments non attendus, et surtout la persistance de l’anomalie.
Si votre base est “sale” sans éléments manifestement malveillants, la désinfection sera moins une chasse aux tables et plus un assainissement ciblé, parfois avec une réinstallation de certains composants.
Deux scénarios fréquents et comment ils se gèrent
Il y a deux cas que je rencontre souvent, et qui changent la stratégie.
Scénario A : persistance en base, code fichier minimal
Le site se comporte de façon étrange, mais les fichiers semblent peu touchés. En fouillant la base, on trouve des options ou des paramètres associés à un comportement malveillant. Parfois une option déclenche une injection de contenu via un hook, ou une valeur stocke une URL de destination.
Dans ce cas, la désinfection WordPress doit être centrée sur la base, avec une vérification des plugins actifs, car le code qui lit ces options peut être dans un plugin.
Scénario B : compromission de plugin, base polluée ensuite
Le malware commence par un plugin ou un thème compromis. Puis il utilise la base pour créer des entrées, installer des hooks, ou injecter des données qui serviront à rediriger.
Ici, nettoyer la base sans traiter le plugin compromis ne suffit pas. La bonne démarche est alors de neutraliser le composant malveillant (désactivation, suppression ou remplacement contrôlé), puis nettoyer la persistance en base.
Dans les deux scénarios, la même règle s’applique : supprimer la cause, pas seulement l’effet.
Réinfection et “nettoyage incomplet” : comment éviter la boucle
Une fois que vous avez nettoyé, le danger réel est la réinfection. Elle arrive pour des raisons classiques.
La première est la faiblesse de l’accès. Mot de passe trop simple, absence de changement après incident, ou réutilisation du même identifiant ailleurs.
La deuxième est la persistance côté fichiers, même si la base a été corrigée. Si un plugin compromis reste actif, il peut re-créer des entrées en base.
La troisième est une mise à jour bloquée. Si vous avez restauré une option ou une table, mais que le plugin reste dans un état incohérent, il peut rejouer des comportements.
Pour casser la boucle, je recommande de traiter l’incident comme un cycle complet : verrouillage d’accès, neutralisation du vecteur, puis nettoyage de la base, puis vérification de la cohérence.
Liste de décision : quel niveau de nettoyage choisir
Selon ce que vous trouvez, l’effort varie. Voici une grille de décision simple, utile quand on hésite entre “on nettoie ciblé” et “on repart”.
- Si vous identifiez un utilisateur administrateur créé de manière suspecte, commencez par révoquer ses privilèges ou le supprimer, puis vérifiez les traces associées dans wp_usermeta Si vous trouvez des options contenant du code ou des URL de redirection manifestes, supprimez ou restaurez celles que vous pouvez relier à l’incident, puis contrôlez les plugins actifs Si des tables non attendues apparaissent et que vous ne pouvez pas identifier leur origine, évaluez d’abord un remplacement contrôlé des composants, avant de supprimer des tables en production Si un plugin ou un thème est compromis, remplacez-le par une version saine et désactivez tout ce qui est douteux, ensuite seulement nettoyez la base Si le site redéclenche l’anomalie après nettoyage, partez d’une sauvegarde saine et recommencez plus strictement, car il reste probablement un point de persistance
Cette liste n’est pas une vérité universelle. Elle force surtout à clarifier la cause avant de supprimer en masse.
Les ajustements de sécurité qui protègent après désinfection
Nettoyer, c’est bien. Empêcher que ça recommence, c’est mieux. Et côté base, on peut réduire la surface d’attaque.
Le premier levier est la gestion des accès. Après un incident, changez tous les mots de passe liés à l’administration WordPress, y compris ceux des comptes techniques. Si votre site utilise un accès SFTP ou un accès base, changez aussi ces identifiants, ou appliquez un contrôle strict.
Le deuxième levier est l’hygiène des plugins et thèmes. Réduisez au minimum ce qui n’est pas nécessaire. Chaque plugin est un potentiel de surface.
Le troisième levier est la surveillance. Les logs d’accès et les logs applicatifs sont utiles pour repérer rapidement une réapparition de comportements. À l’échelle d’un site, même quelques signaux récurrents peuvent accélérer le diagnostic.
Le quatrième levier est la limitation des droits. En production, l’idéal est que WordPress n’ait pas des droits trop larges, et que les comptes de base utilisés aient les permissions minimales nécessaires. Cela ne supprime pas le risque, mais peut limiter l’impact d’un malware.
Quelques pièges à éviter pendant la désinfection
Je termine avec des erreurs fréquentes qui coûtent du temps et qui, parfois, aggravent la compromission.
Supprimer “toutes les options” suspectes, sans identification. Sur WordPress, vous pouvez casser un plugin essentiel, ou déstabiliser un système de cache.
Désactiver un plugin au lieu de le remplacer quand il est probablement infecté. Désactiver peut suffire parfois, mais un plugin compromis peut rester présent dans les fichiers ou dans la base sous d’autres formes.
Nettoyer la base sans vérifier les fichiers associés. Si le code malveillant existe encore, il réécrit la base.
Remettre en ligne directement après correction, sans test. Il suffit parfois d’un seul hook déclenché à une action spécifique pour que l’incident reparaisse au premier utilisateur curieux.
Enfin, ne pas documenter vos changements. Sans notes, vous perdez la capacité de comprendre ce qui a marché et ce qui a échoué. Or, en sécurité, chaque incident est un retour d’expérience.
Ce que je retiens des cas “base de données” (et pourquoi c’est souvent là)
Quand on voit un site compromis, la scène la plus visible est souvent le contenu injecté, les redirections, ou les pages falsifiées. Mais dans beaucoup d’incidents réels, ce qui rend la compromission tenace, ce n’est pas uniquement le fichier. C’est la capacité du malware à reconstituer sa présence au bon moment.
Une désinfection WordPress efficace traite la base comme une pièce à conviction. Elle demande une méthode, une comparaison quand c’est possible, et une suppression ciblée quand c’est pertinent. Et elle n’oublie jamais que la sécurité, ce n’est pas un “coup de balai”, c’est une chaîne. Si une maillon manque, la compromission trouve une autre voie.
Si vous êtes au stade du diagnostic, commencez par ce qui est observable, comptes et options, puis élargissez à ce qui explique le comportement. En procédant ainsi, vous gagnez du temps, vous évitez la casse inutile, et vous transformez une crise en plan de durcissement concret pour l’avenir.