Quand un site WordPress est infecté, la plupart des équipes se précipitent sur le “nettoyage” comme on éteint un feu. Le problème, c’est que l’incendie n’est souvent que la partie visible. Juste après, la vraie difficulté commence: que faire des backups, surtout ceux créés avant l’incident, et comment éviter de réintroduire le malware au moment où vous croyez remettre les choses d’aplomb.
Je l’ai vécu plusieurs fois, sous des formes différentes: un core un peu abîmé mais surtout des plugins et thèmes compromis, des redirections invisibles dans des fichiers “inutiles”, ou encore des comptes administrateurs créés sans trace évidente dans l’interface. Dans ces scénarios, la gestion des sauvegardes devient le pivot de la reprise. Une restauration mal comprise peut transformer un incident de “nettoyage” en une boucle interminable, avec une infection qui revient à chaque redéploiement.
Le point de départ: distinguer nettoyage et remise en état exploitable
Le nettoyage malware WordPress, au sens strict, vise à supprimer le code malveillant. Mais la “remise en état” ne se limite pas à ça. Vous voulez un site qui:
- ne réinstalle pas automatiquement la charge via un mécanisme persistant, ne réauthentifie pas un utilisateur compromis, et ne regénère pas la compromission depuis une base de données “contaminée”.
Or les backups peuvent être à la fois votre meilleure assurance et votre pire accélérateur. Tout dépend de ce qu’ils contiennent au moment où vous les avez pris, et de la façon dont vous les restaurez.
Je conseille de raisonner en temporalité. Si vous savez (même approximativement) quand l’intrusion a eu lieu, vous pouvez décider quels backups ont des chances d’être “propres”. Si vous ne savez pas, vous devez adopter un protocole plus prudent, qui suppose que certains backups contiennent encore des éléments compromis.
Comprendre ce que les backups transportent vraiment
Un backup WordPress standard, qu’il s’agisse d’un zip “fichiers + base de données” ou de dumps séparés, transporte généralement:
Le code applicatif (core, plugins, thèmes), Les uploads (images, fichiers ajoutés via le front ou l’admin), La base de données (utilisateurs, options, posts, métadonnées), Parfois des caches (selon les solutions), Des secrets indirects, comme des éléments stockés dans la base (jetons, options).Le malware peut vivre dans l’un de ces compartiments, ou dans plusieurs. Par exemple, une porte dérobée peut être dans un plugin modifié, mais aussi dans des options de la base qui déclenchent une redirection. Résultat: même si vous restaurez les fichiers “propres”, une base contaminée peut reconfigurer le site pour réinfecter l’environnement à la prochaine action administrative. À l’inverse, une base propre peut quand même recréer des comptes ou des backdoors si les fichiers sont compromis.
Ce point change la stratégie de restauration. Ce n’est pas “un backup, donc retour à l’avant”. C’est “un backup, donc retour à un état qui peut être incomplet ou encore corrompu”.
La première décision: restaurez-vous un backup ou reconstruisez-vous depuis une base saine ?
Il y a deux écoles en https://gardewp.fr/ phase post-incident.
La première consiste à restaurer un backup supposé propre, puis à vérifier que tout fonctionne et que le site ne réinfecte pas. C’est rapide, mais c’est aussi la voie la plus risquée si vos backups ne correspondent pas à une période réellement “avant infection”.
La seconde consiste à reconstruire la base saine en repartant d’éléments de référence (core WordPress officiel, plugins et thèmes connus, uploads contrôlés) et en appliquant une base de données potentiellement filtrée. Cette approche demande plus d’efforts, mais elle réduit drastiquement le risque de “copier-coller la cause”.
Dans la pratique, je choisis selon deux paramètres:
- le niveau de confiance dans la fenêtre temporelle de l’incident, la capacité à inspecter finement ce que contient chaque backup.
Si vous avez des logs d’accès, des traces d’administrateurs créés, ou des timestamps de fichiers modifiés, la restauration peut devenir assez fiable. Si, au contraire, vous n’avez pas d’historique solide, la reconstruction encadrée devient plus rationnelle.
L’erreur la plus coûteuse: restaurer “trop tôt”, puis se battre contre un ghost
Le scénario classique: vous restaurez un backup pris quelques heures avant la détection. Le site revient en ligne. Très bien. Puis, après quelques minutes ou au prochain cycle d’activité (cron, visite front, tentative de connexion), l’infection réapparaît. Ce n’est pas forcément que le backup était mauvais. Parfois, l’environnement n’a pas été nettoyé dans la totalité.
Par exemple, vous avez nettoyé les fichiers en production, mais le plan de sauvegarde a continué à synchroniser des éléments depuis une source contaminée. Ou bien vous avez restauré la base de données, mais les fichiers compromis restent présents et finissent par re-exécuter une logique cachée. Dans d’autres cas, le “malware” n’est pas un fichier, mais un mécanisme: création de compte, modification d’options, ajout d’un champ qui charge un script depuis un autre domaine.
Le résultat est frustrant: on croit être en train de corriger, alors qu’on reconstitue le même état. La clé est donc de traiter les backups comme des “preuves” à évaluer, pas comme des remèdes automatiques.
Mettre en place un protocole de décision sur la restauration
Avant de restaurer quoi que ce soit en production, je recommande de créer une copie de travail dans un environnement isolé, idéalement hors de la zone exposée. Vous testez la restauration, vous examinez, puis vous décidez.
Concrètement, l’idée n’est pas seulement de “voir si ça marche”, mais de vérifier si l’état restauré est cohérent avec une période saine. Cela implique parfois d’inspecter des fichiers, de comparer des listes de plugins, et d’observer le comportement après restauration (par exemple, exécution de cron, tentatives de connexion, pages qui redirigent).
Voici le cadre que j’utilise quand je dois décider vite, sans tomber dans la paranoïa.
Check rapide avant restauration
Identifier la période probable d’intrusion à partir de logs (accès, erreurs, changements de fichiers, création d’utilisateurs). Vérifier que les backups disponibles couvrent bien cette période, et noter leurs timestamps exacts. Contrôler dans l’archive du backup la présence de plugins et thèmes modifiés (dates, taille inhabituelle, fichiers suspects). Planifier une restauration en environnement isolé pour valider le comportement (cron, chargements, redirections). Repartir d’identifiants propres: rotations mots de passe, suppression des comptes inconnus, et vérification des rôles.Cette mini check évite deux pièges. Le premier, c’est de restaurer un backup “au hasard” juste parce qu’il est là. Le second, c’est d’oublier la base de données ou les fichiers d’uploads, qui sont souvent les vecteurs oubliés.
Si vous choisissez la restauration: comment gérer la base de données sans recoller la cause
La base de données est un terrain miné, surtout parce que beaucoup d’attaques WordPress s’y logent sous forme d’options modifiées, de contenus malveillants dans la structure de posts, ou de comptes administrateurs discrets. Quand vous restaurez une base, vous importez aussi des éléments qui peuvent rester actifs même si vous avez remplacé les fichiers.
Mon approche consiste à considérer la base comme un objet à valider. Selon la situation, cela peut vouloir dire:
- ne restaurer que certaines tables ou schémas, ou restaurer l’ensemble puis vérifier des indicateurs précis, ou, si l’incident est grave, reconstruire une base plus propre et réimporter le contenu de manière ciblée.
Le “juste milieu” existe. Par exemple, si l’attaque a manifestement touché des options et des comptes, vous pouvez restaurer un backup base antérieur et ensuite appliquer une procédure de filtrage sur les tables critiques. Je ne donne pas de recette universelle, parce que les schémas diffèrent selon les plugins, et une restauration partielle mal faite casse parfois le site au bout de quelques jours, quand un plugin s’appuie sur une relation attendue.
Ce qui marche bien, c’est de coupler la restauration base avec un cycle de vérification: regarder les comptes, comparer la liste des plugins actifs avec celle attendue, et observer les pages qui déclenchent des redirections ou du code additionnel.
Nettoyer les fichiers en gardant les backups, sans les “contaminer par retour”
Un détail sous-estimé: votre processus de nettoyage peut contaminer les backups, au sens opérationnel. Si vous avez une routine qui replie des archives ou synchronise des dossiers, vous risquez d’écraser un fichier “propre” par un fichier “encore compromis”.
C’est arrivé dans un contexte où le backup automatique du plugin a été reconfiguré sur un répertoire qui se trouvait dans le même espace de stockage que les fichiers déjà compromis. Résultat: les nouveaux backups semblaient corrects au premier regard, mais ils contenaient des traces de l’infection, surtout dans les uploads et certains fichiers temporaires.
Pour éviter ça, je recommande de:
- garder les backups en lecture seule dès l’investigation commencée, créer des copies horodatées distinctes pour restauration, et ne jamais générer de “nouveau backup” depuis un environnement déjà suspect avant d’avoir rétabli un socle propre.
Vous gagnez du temps sur le long terme, parce que vous arrêtez de produire des “preuves” incohérentes.
Quel backup restaurer quand plusieurs versions existent ?
Quand vous avez plusieurs backups, la tentation est de prendre le plus récent. C’est logique, mais dangereux. Le malware peut s’être installé juste après le moment du backup, ou bien une charge peut persister plus longtemps que l’infection visible. Du coup, le backup “le plus proche” n’est pas forcément le backup “le plus sûr”.
Sans logs précis, la meilleure pratique est d’évaluer un petit ensemble de versions candidates: par exemple deux ou trois backups couvrant différents intervalles. Vous restaurez dans un environnement isolé, vous contrôlez, puis vous choisissez.
La question qui revient toujours est: “Comment savoir si c’est propre ?”. Il y a rarement un bouton magique. En revanche, il y a des signaux concrets: redirections récurrentes, présence de fichiers inattendus, tentatives de connexion suspectes, et comportement anormal au chargement.
L’autre angle, c’est la cohérence. Si votre site utilise des plugins spécifiques et que le backup en présente d’autres, ou que des fichiers montrent des dates modifiées inattendues, c’est un indice. Vous ne devez pas chercher une certitude absolue, vous cherchez à réduire le risque.
Deux stratégies selon votre niveau de certitude
- Si vous avez des logs qui pointent une fenêtre d’intrusion claire, vous pouvez restaurer un backup strictement antérieur et concentrer le nettoyage sur les changements survenus ensuite. Si vos logs sont incomplets, privilégiez la reconstruction contrôlée (core + plugins connus + uploads validés) et n’importez la base que si vous pouvez la vérifier ou la filtrer.
Ces choix ne sont pas théoriques, ils changent le résultat final.
Cas fréquent: la base de données est contaminée, mais les fichiers ne le sont pas (ou l’inverse)
Il arrive souvent que l’attaque laisse une signature asymétrique. Par exemple:
- Les fichiers de plugins affichent des modifications, mais la base ressemble à une base “normale”. Ou, au contraire, les fichiers sont intègres, mais la base a des options et comptes modifiés.
Pourquoi c’est important pour les backups ? Parce que vous pouvez être tenté de restaurer uniquement un compartiment, ce qui est parfois faisable.
Dans un cas où les fichiers étaient propres, j’ai restauré la base à partir d’un backup antérieur, puis j’ai réappliqué les modifications légitimes du contenu entre-temps (posts et pages), au lieu de restaurer tout le paquet. Cela a réduit le risque de réintroduire un plugin compromis. Mais cela exige un travail de reconstruction partielle, et un contrôle sur l’intégrité du schéma et des relations.
À l’inverse, si la base est suspecte, restaurer seulement les fichiers ne règle pas forcément l’origine. Un compte administrateur ajouté peut continuer à fonctionner, surtout si les identifiants ont été changés ou si le site a été reconfiguré via les options.
La règle que j’adopte: quand vous n’êtes pas certain, traitez la restauration comme une réinstallation complète, puis validez. Ça évite d’avoir des zones “un peu propres”.
Après restauration: comment valider que le malware ne “revient” pas depuis un backup
Valider après restauration n’est pas une formalité. L’infection peut être déclenchée:
- par cron, par une action admin, par une requête front spécifique, par un événement lié à un plugin (formulaire, import, sitemap).
Je surveille donc un petit ensemble de comportements immédiatement après remise en ligne, même si le site “semble correct”. Les vérifications pratiques dépendent du type d’attaque, mais vous pouvez généralement repérer des signaux faibles: comportement de redirection, création de fichiers en arrière-plan, modifications de plugins, ou nouveaux utilisateurs.
Un autre test utile consiste à inspecter ce qui change entre deux instants. Si, après restauration, de nouveaux fichiers apparaissent ou si des options se modifient sans action humaine, vous avez un indicateur de persistance.
Ce n’est pas sexy, mais c’est efficace, surtout quand les backups n’ont pas été pris avec une grande discipline.
Les backups “propres” existent-ils vraiment ?
La question peut sembler brutale, mais elle est réelle. Un backup “antérieur” peut être considéré propre si, dans votre fenêtre d’investigation, le site n’a pas été compromis et si vous avez des indices matériels que rien n’a été modifié après la date du backup.
Mais l’absence de preuve n’est pas une preuve d’absence. Certains malwares laissent une persistance qui n’est pas évidente au moment où vous restaurez, ou alors ils n’activent leur chargement qu’après un délai.
C’est pour cela que, dans les environnements critiques, je préfère une approche “restauration puis durcissement”. Même après un backup jugé propre, vous devez:
- remplacer les identifiants, renforcer les règles d’accès, réduire les droits, et vérifier la cohérence des plugins et thèmes installés.
On ne “fait plus confiance”, on “fait de la reprise sécurisée”.
Réduire le risque de récidive, même si vous avez un bon backup
Les backups ne corrigent pas la cause. Ils ne font que déplacer l’état.
La reprise sécurisée passe par un durcissement ciblé, pas par une purification abstraite. Quelques actions ont souvent un impact direct:
- rotation des mots de passe (utilisateurs admins et tout compte avec privilèges), vérification des rôles (un compte “éditeur” qui a des droits étendus, c’est un indicateur), suppression des comptes inconnus, mise à jour des plugins et thèmes de sources fiables, en évitant les extensions abandonnées, et contrôle des accès, par exemple limitation de tentatives de connexion et règles autour de l’administration.
Le point délicat, c’est que certains changements peuvent casser des workflows internes. Si vous utilisez des automatisations ou des comptes de service, vous devez coordonner la rotation. Je l’ai déjà vu: on supprime un compte “inutile” puis un script de déploiement ou un plugin d’intégration cesse de fonctionner, ce qui repousse la validation et prolonge la période de fragilité.
Et si vous n’avez qu’un backup et qu’il est possiblement compromis ?
Dans la vraie vie, parfois il n’y a pas de choix confortable. Vous avez un seul backup, et vous suspectez qu’il a été pris après l’intrusion. Dans ce cas, restaurer peut être utile, mais pas dans l’idée de “revenir à l’état stable”.
Je traiterais la restauration comme un point de départ pour analyse, pas comme une fin. Vous restaurez en isolement, vous repérez ce qui a été modifié, puis vous reconstruiisez un état plus propre. https://gardewp.fr/nettoyage-malware-wordpress/ Le contenu récupérable (articles, pages, médias) peut souvent être conservé, alors que les zones de configuration et les composants à risque sont remplacés par des versions réputées saines.
C’est plus long, mais vous évitez la spirale “ça marche puis ça revient”.
Les uploads: le compartiment que je n’ignore plus
Beaucoup d’incidents WordPress passent par les uploads, que ce soit via l’injection de fichiers dans des dossiers ou via des scripts déguisés. Une restauration qui ne traite que core + plugins peut échouer, et un nettoyage qui laisse des fichiers d’uploads compromis peut réintroduire le malware à la prochaine fois qu’un script est exécuté.
Dans mon processus, je contrôle au minimum:
- les fichiers ajoutés récemment (par date), les fichiers qui n’ont pas de raison d’être dans les répertoires attendus, et les modèles de comportement (redirections ou chargements depuis des fichiers non standard).
Si votre site génère beaucoup de médias, ce tri peut devenir fastidieux. Là encore, l’approche “fenêtre temporelle” aide: vous ciblez les uploads depuis la date suspecte plutôt que tout remonter.
Un dernier piège: restaurer puis “mettre à jour” sans cohérence
Après incident, on veut remettre le site en ligne, puis on met à jour. Le problème, c’est que mettre à jour un plugin ou un thème depuis un état déjà corrompu peut:
- ne pas supprimer la modification malveillante si elle est réinjectée via la base, ou faire échouer des mécanismes de réparation si la structure du code n’est pas celle attendue.
J’ai déjà vu des équipes mettre à jour un plugin “pour réparer”, alors que le vrai problème venait d’options de configuration dans la base. Le plugin mis à jour semblait correct, mais les redirections persistaient. Le correctif a finalement été trouvé dans la base, pas dans le code mis à jour.
Donc, même si vous restaurez et mettez à jour, gardez l’ordre logique: stabiliser, vérifier l’état, puis durcir. Et surtout, gardez une trace des actions. Quand tout est urgent, on perd la chronologie, et c’est la chronologie qui permet de comprendre pourquoi le backup “n’a pas tenu”.
Concrètement, à quoi ressemble un bon plan de reprise avec backups
Un bon plan n’a pas besoin d’être long. Il doit être robuste et répétable. Celui que j’adopte après un incident combine:
- une restauration isolée, un contrôle sur les comptes et les composants, et un retour en production avec durcissement immédiat.
Si vous devez choisir entre vitesse et sécurité, la sécurité gagne quand le malware est actif. La vitesse ne sert à rien si vous réinfectez le site le jour même.
Et si vous avez des backups, considérez-les comme une matière première à inspecter, pas comme une machine à remonter le temps. Le bon backup est celui qui correspond à une version cohérente et vérifiable de votre site, pas celui qui est simplement “le plus ancien”.
Si vous me posez la question la plus directe, je réponds toujours pareil: gérez vos backups comme des preuves, isolez la restauration, validez le comportement après remise en ligne, puis seulement après renforcez l’environnement pour empêcher le retour. C’est ce qui fait passer le nettoyage malware WordPress d’une réaction à un processus maîtrisé.