Quand on parle de désinfection WordPress, on pense souvent aux fichiers, aux thèmes, aux plugins compromis. Pourtant, dans beaucoup d’urgences réelles, c’est la base de données qui porte les traces les plus tenaces, parce qu’elle enregistre des liens, des métadonnées, des options, des utilisateurs, parfois des scripts injectés dans des champs inattendus.
J’ai vu des sites “propres” côté fichiers, avec un WordPress qui charge correctement, et pourtant la page d’accueil renvoyait encore un comportement malveillant. La raison était simple: les modifications étaient stockées quelque part dans wp options, wppostmeta ou wp_comments, et les fichiers remis à zéro n’avaient rien résolu.
L’objectif ici est clair: restaurer la base de données proprement, sans empirer la situation, sans recontaminer au passage, et avec une méthode qui laisse une trace rationnelle de ce qu’on a fait.
Le piège de la restauration partielle
Le scénario revient souvent. On reçoit une alerte, on constate des pages qui changent, des redirections, parfois des faux formulaires. On nettoie ce qu’on voit: .php modifiés, uploads suspects, plugins inconnus. Ça marche… à moitié.
Ensuite, on “réinstalle” ou on “réduit” la base en important une sauvegarde. Problème: si la sauvegarde de base a été prise après l’infection, ou si elle ne correspond pas au moment où les fichiers ont été purgés, on mélange des états. Résultat classique: certains vecteurs restent actifs parce qu’ils sont encore présents dans des options ou des métadonnées.
Il y a aussi le https://gardewp.fr/ cas inverse. On restaure la base depuis une sauvegarde “clean”, mais on laisse des fichiers compromis ou des plugins ajoutés entre-temps. Là encore, la base propre n’empêche pas la réinfection, car le code malveillant peut réécrire des valeurs ou exploiter des hooks.
La restauration propre, c’est donc une restauration cohérente. Soit on reconstruit un couple fichiers + base cohérent, soit on nettoie par étapes en contrôlant à chaque étape ce qui a été réintroduit.
D’abord, figer l’environnement
Avant de toucher à la base de données, je conseille presque toujours de figer le système. Pas parce que c’est “propre”, mais parce que WordPress peut continuer à écrire pendant que vous enquêtez.
Concrètement, si le site est vivant, quelqu’un peut générer des requêtes, des formulaires peuvent être soumis, le trafic peut provoquer de nouvelles écritures dans la base. Si vous lancez une désinfection WordPress en parallèle d’un site actif, vous risquez d’obtenir un résultat incohérent: vous supprimez une valeur, elle revient.
Au minimum:
- passer le site en maintenance ou limiter fortement l’accès, couper l’autoupdate si elle tourne encore en arrière-plan, et, surtout, immobiliser les tâches planifiées non indispensables pendant le nettoyage.
Sur un WordPress normal, on peut généralement se permettre 30 minutes de gel pour faire un dump, vérifier, restaurer, puis seulement ensuite relancer.
Faire une copie de travail: le dump avant tout
Rien n’est plus frustrant que de découvrir une erreur SQL plusieurs heures après coup. Avant toute restauration ou modification, faites un dump de travail complet de la base actuelle, même si vous pensez la “perdre”.
Ce dump sert à deux choses:
Revenir en arrière si la restauration échoue, Comparer ce qui a changé entre la base “actuelle” et la base “cible”.C’est aussi votre preuve interne. En cas d’incident, on a souvent besoin de reconstituer la chronologie. Un dump daté vous évite les souvenirs flous.
Le dump peut être fait via l’outil de votre hébergeur, phpMyAdmin, ou en ligne de commande (mysqldump). L’important est le même: une archive exploitable, et vérifiable.
Choisir la bonne base à restaurer
La question “quelle sauvegarde restaurer” est plus subtile qu’elle n’en a l’air.
Vous aurez généralement trois options, selon ce que votre hébergeur archive:
- restaurer une sauvegarde de base prise avant l’infection, restaurer une sauvegarde proche du moment d’infection, puis nettoyer le delta, ou reconstruire à partir d’une base “ancienne” plus propre, en réinjectant éventuellement des contenus récents.
Je tranche souvent de la façon suivante:
- Si vous avez une sauvegarde clairement antérieure au moment où l’infection a commencé, restaurer cette sauvegarde est la stratégie la plus robuste. Si vous n’avez pas mieux, il faut accepter un nettoyage post-restauration. Dans ce cas, l’enjeu est de supprimer uniquement ce qui a été réinfecté ou modifié après le point de sauvegarde. Si vous devez réinjecter du contenu récent, faites-le après restauration complète et seulement via des mécanismes contrôlés (export/import du contenu), en vérifiant que ce que vous réinjectez ne contient pas aussi des champs compromis.
L’erreur la plus coûteuse consiste à “recoller” des tables une par une sans comprendre les dépendances. Une désinfection WordPress “propre” passe par une base cohérente.
Restaurer sans repropager: la logique de cohérence
Quand vous restaurez une base, WordPress s’attend à une cohérence entre:
- la structure des tables, les options globales, les utilisateurs, les posts et leurs métadonnées, et parfois des tables liées aux plugins installés (selon ceux qui stockent des données en base).
Si votre site utilise des plugins qui créent des schémas spécifiques, restaurer uniquement certaines tables peut casser des comportements ou, plus embêtant, masquer une partie du problème. Vous ne verrez pas forcément tout de suite les traces d’infection, car les plugins ne fonctionnent pas comme prévu.
Donc, la restauration “propre” consiste à restaurer la base complète. Ensuite, vous nettoyez ce qui doit l’être, dans la base restaurée, en ciblant les points où une infection laisse des traces.
Où une désinfection WordPress laisse le plus souvent des traces
Je vais rester concret. Dans une base WordPress, certains emplacements sont des suspects récurrents, surtout quand un site a été compromis via des failles de plugins, des mots de passe faibles, ou une extension malveillante.
Sans faire de promesses, voici les zones à surveiller en priorité:
- wp_options: c’est là qu’on trouve des réglages globaux, des options que certains plugins enregistrent, et parfois des valeurs détournées (redirections, injections, configurations cachées). Selon votre préfixe, la table s’appelle wp_options ou mon_prefix_options. wp_users et wp_usermeta: utilisateurs ajoutés, rôles modifiés, métadonnées qui indiquent une activité anormale. Parfois, l’infection ne passe pas par du PHP modifié, mais par un compte “admin” créé en silence. wp_postmeta: métadonnées d’articles, de pages, de shortcodes, ou de blocs. Une injection peut se retrouver dans des champs de métadonnées plutôt que dans le contenu visible. wp_comments et wp_commentmeta: spams et liens indésirables, y compris des contenus qui déclenchent des affichages indirects. wp_links et autres tables “optionnelles”: selon la configuration et l’age du site, certains schémas évoluent. Les tables abandonnées peuvent contenir des traces, mais elles sont moins fréquentes qu’avant.
Cette liste ne remplace pas une enquête, elle sert de boussole. Le but est d’éviter de partir dans tous les sens en consultant des milliers de lignes au hasard.
Étape clé: vérifier les droits et la surface d’exécution
Avant d’attaquer la base, vérifiez un point qui change tout: le site doit-il exécuter du code malveillant encore présent ailleurs?
Même si l’article se concentre sur la restauration de base, je vous recommande de faire deux contrôles rapides:
- vérifier la liste des plugins installés et les versions, vérifier les utilisateurs et rôles, et surtout, confirmer que les fichiers suspects ont été supprimés, ou au minimum remis à un état cohérent.
Sinon, vous allez désinfecter la base, puis un plugin compromis va réécrire des valeurs.
Une check-list de restauration “propre” (ciblée base + cohérence)
Voici la séquence que j’utilise quand je veux être méthodique et éviter les erreurs classiques. Elle reste courte, parce qu’on gagne surtout en rigueur.
Mettre le site en maintenance et stopper les actions automatiques non indispensables. Faire un dump complet de la base actuelle (preuve + retour arrière). Restaurer une base complète provenant d’un point avant l’infection si disponible. Reprendre ensuite des contrôles ciblés: comptes utilisateurs, options anormales, contenus et métadonnées suspectes. Revalider le comportement du site sur des URLs représentatives, puis seulement rouvrir progressivement.Cette approche limite le “mélange des états”, ce qui est le vrai danger de la restauration partielle.
Restaurer et contrôler: les axes concrets de vérification
Une restauration de base n’est pas terminée parce que “les tables existent à nouveau”. Ce qui compte, c’est ce que la base dit à WordPress.
1) Les utilisateurs: le test le plus rentable
Beaucoup d’attaques créent un compte avec un rôle élevé, ou modifient le rôle d’un compte existant. Après restauration, je commence presque toujours par vérifier:
- quels utilisateurs existent, leurs rôles effectifs, et si certains comptes ont été créés ou activés autour de la fenêtre d’incident.
Selon votre situation, vous devrez peut-être corréler avec les logs d’accès ou les dates de création. Le champ exact dépend des versions, mais l’idée reste: une restauration “clean” doit aussi restaurer une liste utilisateurs cohérente.
Un détail important: si vous avez restauré une base ancienne, des utilisateurs créés après ce point peuvent manquer. C’est un compromis. Dans un incident de sécurité, on privilégie l’intégrité. Ensuite, on peut réimporter des utilisateurs via des méthodes contrôlées, plutôt que de “rapiécer” en copiant des lignes dans des tables.
2) Les options: traquer les valeurs inattendues
Après la restauration, inspectez les options qui peuvent influencer des comportements front. Sans prétendre à une règle universelle, on regarde en pratique:
- les options enregistrées comme si elles étaient des réglages habituels, celles qui contiennent des URLs suspectes, celles qui contiennent des chaînes typiques d’injections (par exemple des fragments HTML, des scripts, ou des patterns cohérents avec une redirection).
Le point délicat est la similarité. Certains plugins stockent des données qui ressemblent à des “injections” quand on les voit en base. Le bon réflexe est d’abord de comparer avec une base connue propre, ou à défaut avec votre historique de configuration (plugins installés, réglages attendus).
Si vous n’avez qu’une seule base à analyser, je privilégie l’approche par comparaison: chercher les valeurs qui changent le plus entre l’ancien dump de l’infection et la base restaurée propre.
3) Les métadonnées de posts: quand le contenu semble intact
Une infection peut laisser un comportement visible seulement après rendu, car un champ dans wp_postmeta injecte quelque chose dans le front via un plugin ou un template.
C’est là que la lecture “humaine” via l’interface ne suffit pas. Un rédacteur voit parfois une page “normale”, mais une courte portion peut être altérée, ou rendue dynamiquement.
Après restauration, il faut donc contrôler:
- les pages et articles qui étaient censés être affectés, et les champs de métadonnées liés aux shortcodes ou aux blocs que vous utilisez.
Je fais souvent une approche pragmatique: je compare les pages concernées avant et après restauration (par exemple via exports, ou via consultation en lecture seule), puis je remonte en base uniquement quand une incohérence apparaît.
4) Les commentaires: surtout quand le site reçoit du spam
Les commentaires et métadonnées de commentaires posent deux problèmes. D’abord, ils peuvent contenir des liens indésirables. Ensuite, certains thèmes affichent des extraits ou des liens d’une façon qui déclenche un comportement non prévu.
Si vous constatez une vague de commentaires postés autour de la fenêtre d’incident, la restauration doit aussi supprimer les entrées correspondantes.
Le compromis ici est clair: restaurer une base ancienne peut effacer des commentaires légitimes. Selon la valeur de votre site, ce n’est pas toujours acceptable. Mais en situation d’incident, on choisit souvent l’assainissement avant la conservation totale.
Restaurer, puis nettoyer, sans casser WordPress
Une fois la base restaurée, vous allez parfois devoir nettoyer des traces qui existent encore. Le piège est de vouloir “nettoyer tout ce qui ressemble”, ce qui casse le site.
Quelques règles pratiques issues du terrain:
- Ne modifiez pas des dizaines de valeurs au hasard. Ciblez ce que vous avez identifié. Si vous devez supprimer, supprimez avec un critère testable. Par exemple, une option contient une URL vers un domaine qui n’a aucun rapport avec votre activité. Évitez les suppressions massives en aveugle sur des tables entières. Une base WordPress “vivante” dépend d’un minimum de données structurantes.
Si vous utilisez des requêtes SQL, faites-le sur une copie, et testez. L’objectif est de garder la main. Une désinfection WordPress échouée ne se voit pas toujours tout de suite, et peut réapparaître au bout d’une semaine.
Réinfection: comment savoir si votre base “propre” le reste
Après restauration et nettoyage, la partie la plus stressante est la validation. Vous avez un site “qui marche”, mais est-ce qu’il redevient dangereux au prochain trafic ou à la prochaine mise à jour?
Pour réduire le risque:
- testez des pages qui déclenchent le comportement initial (home, pages d’atterrissage, pages qui listent des contenus), testez aussi un comportement de formulaire si l’incident touchait les formulaires (sans injecter n’importe quoi), et observez la base pendant un court laps de temps après remise en ligne.
Les indicateurs “revenus” sont souvent des changements d’options ou l’apparition de nouveaux utilisateurs. Parfois, un script remet en place des valeurs uniquement après un déclencheur (comme un accès à une URL spécifique).
Donc, gardez une trace. Comparez au moins quelques points: liste des utilisateurs, changements des options suspectes, et présence éventuelle de nouveaux éléments dans les tables de commentaires.
Deux scénarios difficiles, et comment je les gère
Scénario A: pas de sauvegarde vraiment antérieure
Vous avez peut-être des dumps, mais pas assez tôt, ou une sauvegarde qui est déjà contaminée.
Dans ce cas, il faut restaurer un état “au plus proche”, puis faire une désinfection WordPress curative en identifiant les divergences.
L’approche la plus fiable consiste à:
- restaurer la meilleure sauvegarde disponible, figer le site, comparer les tables clés avec le dump initial de l’infection, et supprimer uniquement ce qui ressort clairement comme anormal.
Cela demande plus de temps, mais au moins vous avancez avec une logique de preuves.
Scénario B: besoin de récupérer du contenu postérieur
Après restauration d’une base ancienne, vous perdez des pages, des articles, des réglages mis en place plus tard.
Vous pouvez récupérer du contenu, mais pas en copiant des fragments de base au hasard. Le risque est d’importer aussi les charges malveillantes via des champs.
Selon votre setup, des options existent:
- exporter/importer via l’outil de WordPress si c’est fiable, ou rétablir uniquement le contenu texte, sans champs personnalisés qui peuvent être infectés.
Le choix dépend des plugins. Certains plugins “stockent” beaucoup dans la base, et pas uniquement dans des champs simples. Si vous importez des métadonnées liées à ces plugins, vous pouvez réinjecter le problème.
Ici, le bon sens s’impose: récupérez ce que vous comprenez. Si vous ne comprenez pas une structure, préférez reconstruire la mise en page plutôt que de réimporter tout.
Après la restauration: durcir pour que la base ne se fasse pas réécrire
Nettoyer la base est une étape. La désinfection WordPress doit aussi empêcher la prochaine.
Sans faire une liste interminable, je peux vous dire ce qui réduit vraiment le risque:
- verrouiller les comptes à haut privilège (mots de passe forts, suppression des comptes non nécessaires), revoir les plugins, supprimer ceux dont vous n’avez pas besoin, mettre à jour ceux qui restent, contrôler les thèmes et les modifications manuelles, et vérifier la configuration des rôles et des utilisateurs.
Le point important est que la base est une cible, mais le facteur déclenchant est souvent une surface d’entrée côté exécution (plugin vulnérable, compte faible, paramètre de rôle, etc.).
Quand faire appel à quelqu’un, et quoi demander
Il y a des cas où la restauration propre de la base prend trop de temps, ou où vous n’avez pas les compétences pour manipuler le SQL sans risque.
Je pense notamment aux situations où:
- vous n’avez pas de sauvegardes exploitables, vous avez des traces dans plusieurs zones de la base, ou vous suspectez une compromission plus large, avec reconfigurations et comptes cachés.
Si vous faites appel à un tiers, demandez un plan de preuve. Par exemple, comment ils valident que les options suspectes sont parties, comment ils vérifient que les utilisateurs de haut privilège ne reviennent pas, et comment ils confirment la cohérence fichiers + base.
Une bonne désinfection WordPress ne se contente pas de “ça marche”. Elle se conclut par une validation.
Les tests de validation qui me paraissent non négociables
Pour finir, voici les contrôles que je considère comme indispensables après une restauration:
Recharger plusieurs pages critiques et vérifier le comportement attendu, y compris les pages qui listent des contenus. Vérifier la liste des utilisateurs et leurs rôles, puis contrôler les éléments pouvant indiquer une activité récente. Contrôler les options et métadonnées qui étaient suspectes avant restauration, avec comparaison si possible. Surveiller pendant un laps de temps la base et le comportement du site après remise en ligne. Confirmer que la surface d’exécution a été assainie (plugins, thèmes, fichiers), sinon vous aurez un effet “whack-a-mole”.
Une base propre, c’est la base qui ne réécrit pas de manière incohérente après restauration. C’est là que vous gagnez vraiment du temps sur la suite, parce que vous réduisez les rechutes.
Si vous voulez, dites-moi votre cas (préfixe des tables si vous l’avez, type d’hébergement, existence ou non d’une sauvegarde antérieure, symptômes exacts visibles). Je peux vous proposer une stratégie de restauration et de contrôle adaptée, en restant pragmatique et sans vous faire perdre du temps sur des étapes qui ne s’appliquent pas à votre situation.