Restaurer un site WordPress, ça ressemble parfois à un bouton “retour à la normale”. Vous remettez une sauvegarde, la page redevient lisible, le trafic revient, vous respirez. Et puis, quelques jours plus tard, quelque chose se répète. Même symptôme, même incohérence, parfois même code injecté, mais pas exactement au même endroit.
C’est là que commence la vraie difficulté: traiter une réinfection après restauration. Pas seulement “nettoyer”, mais comprendre pourquoi la compromission revient, casser la chaîne de réinfection, et remettre en place un socle qui empêche un attaquant de réinstaller tranquillement son accès.
Je vais vous guider pas à pas, avec l’approche que j’utilise sur des cas réels: celle qui privilégie la méthode, le contrôle des points d’entrée et la validation post-restauration, plutôt que la chasse au “fichier suspect” prise au hasard.
Le piège: restaurer sans comprendre ce qui a été restauré
Quand on restaure, on remet en place https://gardewp.fr/nettoyage-malware-wordpress/ un état du site à une date donnée. Si la sauvegarde provient d’un moment où la compromission était déjà présente, vous restaurez aussi la porte d’entrée. Même si l’injection ciblait un fichier précis, l’attaquant peut s’être servi d’un mécanisme durable, par exemple un compte administrateur caché, une tâche planifiée, un fichier PHP ajouté dans un dossier inattendu, ou encore une manipulation côté base de données (options, cron WordPress, transients, meta d’articles).
Autre cas fréquent: vous restaurez un dossier “site” et oubliez un élément, typiquement la base de données ou la configuration serveur. Si le site a été compromis via un plugin, mais que votre restauration ne touche pas la version du plugin sur le serveur, l’infection peut revenir au prochain chargement. Ou bien vous restaurez “au bon moment”, mais la source initiale du problème n’a pas été corrigée: mot de passe réutilisé, plugin vulnérable, thème compromis, accès FTP mal sécurisé, jetons d’API ou variables d’environnement exposées.
Enfin, il y a un scénario que j’ai vu plusieurs fois en production: l’injection est “vivante” et se regénère. Vous nettoyez un fichier, mais l’attaquant a laissé un mécanisme qui re-crée le fichier dès que WordPress est sollicité. Dans ce cas, la réinfection arrive vite, parfois en moins de 24 heures après une restauration ou un nettoyage incomplet.
Reconnaître une réinfection, plutôt qu’une simple “rechute”
Le diagnostic est important, parce que la stratégie ne sera pas la même.
Une réinfection présente souvent des patterns clairs:
- Le même type d’injection revient, au même format, ou à quelques variantes près. Les fichiers “infectés” reviennent malgré la purge précédente. Le trafic redescend, puis remonte avec un comportement similaire (pages modifiées, redirections, scripts injectés). Vous constatez de nouveaux comptes, de nouvelles options, ou des modifications de fichiers qui semblent “venir de nulle part”.
Une “rechute” au sens strict, c’est plutôt quand le nettoyage initial n’a pas éliminé l’origine. La différence tient donc à votre preuve: si la restauration ne change pas vraiment la cause, la réinfection est presque mécanique.
Concrètement, si vous restaurez une sauvegarde “propre” mais que vous avez encore une extension compromise sur le serveur, ou que des identifiants compromis restent utilisables, vous allez observer une réinfection dès que quelqu’un (ou un script) déclenche le processus.
Avant de toucher au site: établir une preuve et un plan de travail
Quand on est dans l’urgence, on a envie de supprimer tous les fichiers suspects, de réinstaller WordPress, et de croiser les doigts. Ça peut marcher, mais sur des réinfections répétées, je conseille de ralentir un peu pour éviter de nettoyer en aveugle.
La démarche qui donne les meilleurs résultats consiste à documenter, même rapidement:
D’abord, notez la date exacte de la restauration et l’heure approximative du retour des symptômes. Ensuite, identifiez ce qui a changé entre “avant la restauration” et “après la restauration”: versions WordPress et plugins, thèmes, dépendances, configuration serveur, méthodes d’accès. Si vous avez un accès aux journaux (web server, PHP-FPM, logs d’erreurs, logs WordPress pour certains plugins), relevez au moins les événements proches du déclenchement de la réinfection.
Vous cherchez aussi un signal utile: un nouveau fichier modifié, un utilisateur créé, un plugin activé sans autorisation, un cron WordPress qui tourne sur des intervalles bizarres, ou une base de données qui a reçu des mises à jour en chaîne.
Je me suis déjà retrouvé sur un site où la réinfection ne laissait que peu de traces côté front, mais les logs montraient des appels réguliers à un endpoint caché, suivi d’une écriture de fichiers sur le serveur. Le nettoyage “manuel” a été inefficace tant qu’on n’avait pas identifié ce point de déclenchement.
Première étape: sécuriser l’accès, sinon vous êtes en train de restaurer un accès pour l’attaquant
La désinfection WordPress ne peut pas être un travail purement “filesystem”. Si l’attaquant a encore un moyen de se reconnecter, il réinstallera sa présence dès que le site redeviendra fonctionnel.
Même si vous êtes certain que la sauvegarde est bonne, commencez par bloquer les points d’entrée:
- Empêchez la création de comptes pendant l’investigation, au minimum via la fermeture temporaire du backend si c’est possible. Révoquez les sessions actives (déconnexion forcée) et changez tous les mots de passe, y compris ceux des comptes FTP/SFTP, de l’hébergement, et des interfaces comme phpMyAdmin. Vérifiez s’il existe des utilisateurs WordPress supplémentaires (parfois sans leur donner accès public, l’attaquant garde un administrateur discret).
Au passage, faites attention à un détail: si vous changez les mots de passe avant de comprendre la compromission, vous pouvez casser des traces utiles côté logs (surtout si vous utilisez des comptes temporaires). C’est un arbitrage. En pratique, si vous êtes déjà face à une réinfection, la priorité va à la coupure de l’accès.
Contrôle rapide des signaux côté WordPress
Voici les vérifications les plus rentables, que j’effectue avant même de lancer une grosse procédure de nettoyage. Pas pour “cocher des cases”, mais parce qu’elles révèlent souvent la cause en quelques minutes:
- Présence de nouveaux utilisateurs (admins, éditeurs, auteurs) et dates de création Plugins et thèmes activés récemment, notamment ceux qui ne font pas partie du cycle habituel de mise à jour Tâches planifiées (cron WordPress) qui s’exécutent alors qu’elles ne devraient pas Modifications d’options et de contenus qui reviennent à l’identique après restauration Fichiers nouvellement modifiés dans des zones sensibles (dossiers de thèmes, uploads, ou fichiers ajoutés à la volée)
Si vous découvrez un compte ou un plugin activé sans raison, vous tenez déjà un fil conducteur. La réinfection devient alors une opération de “suppression de l’agent + verrouillage des portes”.
Déterminer le vecteur: où est cachée la réinfection
Sur WordPress, les réinfections proviennent souvent d’un petit nombre de vecteurs. Les reconnaître réduit énormément le temps perdu.
1) Compromission via plugin ou thème vulnérable
Un plugin obsolète, un thème modifié, ou un plugin “nul mais efficace” installé pour une fonctionnalité spécifique. C’est un classique: la vulnérabilité permet d’écrire des fichiers, d’ajouter un webhook, ou de déposer un code dans des fichiers PHP.
Le signal: après restauration, la réinfection se produit peu après l’activation de ce plugin, ou après une visite du site. Vous pouvez observer des requêtes répétées, ou des modifications de fichiers qui pointent vers les mêmes composants.
Dans ce cas, la désinfection WordPress ne doit pas se limiter à supprimer le fichier injecté. Il faut aussi désactiver et remplacer le plugin ou le thème, et corriger la surface d’attaque.
2) Compromission par identifiants ou accès fournisseur
Parfois, le site n’est pas “piraté” via WordPress. Il est modifié depuis l’extérieur via FTP, SFTP, ou via un accès hébergement. Vous changez le mot de passe WordPress, mais quelqu’un a encore un accès système. La réinfection suit.
Dans ce scénario, vous verrez souvent que des fichiers ont des propriétaires, des timestamps, ou des modifications qui ressemblent à une intervention externe. Et parfois, vous n’avez pas de nouveau compte WordPress. La présence se fait ailleurs.
3) Injection persistante via base de données
La base de données peut stocker des contenus malveillants, parfois sous forme de scripts, de contenus dans des options, ou même de modifications dans des champs utilisés pour générer des pages.
Signal: les fichiers sur le disque ne changent pas beaucoup, mais le rendu du site se modifie, et les contenus “reviennent” après restauration. Si la restauration que vous faites n’inclut pas correctement la base de données, ou si vous restaurez partiellement, vous pouvez rester piégé.
4) Cron WordPress ou mécanisme de régénération
Le cron WordPress déclenche des tâches, et certains malwares abusent de ce système. Même si vous supprimez des fichiers, une tâche planifiée les recrée plus tard.
Signal: les symptômes réapparaissent à intervalles réguliers, parfois corrélés à une heure précise. Vous pouvez aussi voir des patterns dans les requêtes ou les logs PHP.
Procédure de traitement d’une réinfection après restauration
Passer à l’action implique une approche structurée, mais pas forcément longue. Le but, c’est de faire une restauration “propre” et de s’assurer que l’origine ne reste pas disponible.
Je vous propose une démarche en plusieurs couches, avec des choix réalistes quand on est sur des environnements de production.
1) Stopper la boucle: désactiver les déclencheurs
Quand vous suspectez une régénération, vous devez neutraliser ce qui déclenche l’infection.
Selon votre situation, cela peut vouloir dire mettre le site en maintenance, limiter l’exécution PHP sur des dossiers ciblés, ou au minimum couper l’accès au backend le temps de l’analyse. Le but est de ralentir l’attaquant, pas de “jouer au plus vite”.
Sur certains hébergements, vous pouvez aussi temporairement désactiver certains plugins ou imposer une règle de sécurité côté serveur. Mais évitez de bricoler trop longtemps, sinon vous perdez la fenêtre d’observation dans les logs.
2) Refaire une restauration maîtrisée
Si vous avez déjà restauré une fois, la tentation est de recommencer. Je recommande plutôt de vérifier la provenance et la cohérence de la sauvegarde.
Une restauration efficace doit inclure, au minimum, les éléments suivants:
- fichiers du site (thèmes, plugins, uploads si c’est pertinent) base de données configuration applicative (wp-config, réglages spécifiques)
Le piège: restaurer les fichiers sans restaurer la base, ou l’inverse, puis constater que la réinfection “recolle” au site. Dans certains cas, la base de données porte l’empreinte de la compromission, et les fichiers ne suffisent pas.
3) Appliquer une reconstruction ciblée des composants
Le point délicat de la désinfection WordPress, c’est qu’on ne veut pas remplacer “n’importe quoi” et créer d’autres problèmes. Mais sur une réinfection persistante, j’ai souvent préféré remplacer les composants critiques plutôt que de faire une chirurgie au millimètre.
En pratique, l’approche la plus fiable consiste à repartir de sources propres pour WordPress core et à ne garder que ce qui doit l’être. Les thèmes et plugins doivent être ceux que vous contrôlez. Si un composant vient d’une source non maîtrisée, ou si vous n’avez pas la certitude de son intégrité, vous le mettez de côté et vous le remplacez.
4) Vérifier l’intégrité avant remise en ligne
Avant de réactiver le site, vous devez prouver que ce qui a été restauré reste stable.
Je fais généralement une vérification avant de remettre la production en ligne, puis une vérification après une première visite de test (ou un chargement automatique, selon la configuration). Si la réinfection ne réapparaît pas immédiatement, c’est bon signe. Si elle revient en quelques minutes, vous tenez un déclencheur.
C’est aussi le moment de confirmer que les comptes WordPress n’ont pas été recréés, et que les options sensibles n’ont pas été modifiées.
Ordre conseillé (simple, mais efficace)
Voici un ordre que j’ai utilisé à plusieurs reprises quand la réinfection revenait malgré les restaurations:
Couper l’accès au backend et révoquer les sessions, changer les mots de passe (WordPress et hébergement) Analyser les logs autour de la restauration pour repérer le moment et le vecteur probable Restaurer de manière cohérente (fichiers + base), ou reconstruire core, thèmes, plugins depuis des sources propres Neutraliser les déclencheurs possibles (plugins suspects, cron anormal) Remettre en ligne en surveillance active, vérifier la stabilité après la première sollicitationL’idée n’est pas de suivre religieusement cet ordre, mais de ne pas sauter la logique: vous bloquez l’accès, vous restaurez correctement, puis vous testez la stabilité dans un contexte maîtrisé.
Comment éviter la réinfection, une fois que le site semble propre
Nettoyer une fois, c’est bien. Empêcher le retour, c’est le vrai travail. Une désinfection WordPress “sans prévention” ressemble à une réparation de toiture qui oublie la fuite à la jonction.
Voici des mesures qui font une différence tangible.
Mettre à plat les mises à jour et supprimer la dette de sécurité
Un plugin oublié, un thème pas maintenu, une version PHP qui n’est pas à jour sur le serveur. C’est souvent là que la compromission recommence. Sur des sites installés depuis des années, j’ai vu le même schéma: les correctifs avaient été repoussés pour éviter un risque “fonctionnel”, et le risque de sécurité a gagné.
Vous n’êtes pas obligé de tout mettre à jour d’un coup si vous avez une plateforme fragile. Mais il faut un plan. Le minimum: supprimer ce qui n’est pas utilisé, mettre à jour ce qui est critique, et auditer les extensions qui ont des privilèges élevés.
Durcir les comptes et limiter ce qui peut être modifié
Une fois propre, vous pouvez réduire les surfaces:
- mots de passe uniques et forts pour chaque compte authentification à deux facteurs pour les comptes à privilèges réduction des droits des utilisateurs au strict nécessaire nettoyage des comptes inconnus
Je sais que cela semble “évident”, mais sur les réinfections, c’est souvent ce qui manque: une seule personne, un seul compte, et des droits trop larges. L’attaquant n’a pas besoin de tout casser, il suffit d’un accès.
Surveiller ce qui change, au lieu de ne regarder qu’au moment du drame
Quand un site est en production, les modifications sont inévitables. La question, c’est lesquelles. Il faut que vous puissiez repérer rapidement une dérive.
Une surveillance simple et efficace consiste à vérifier régulièrement:
- fichiers récemment modifiés dans les répertoires sensibles liste des plugins et thèmes actifs utilisateurs WordPress erreurs d’accès et pics de requêtes
Si vous avez déjà vécu une réinfection, vous savez à quel point le temps compte. Un signal précoce évite de restaurer au hasard.
Cas concrets: ce qui marche quand la réinfection revient plusieurs fois
Je partage deux cas fréquents, parce qu’ils illustrent un point: l’infection ne “revient” pas par magie, elle revient parce qu’un mécanisme est resté en place.
Cas 1: les fichiers sont propres, mais le contenu injecté revient
Dans ce scénario, on retrouve des thèmes et plugins “rendus” propres, mais le site affiche des redirections ou des blocs de script injectés après quelques visites. Le disque ne montre pas forcément beaucoup de modifications.
Ce que ça suggère, souvent, c’est une partie persistée dans la base de données. La correction consiste à restaurer la base de données depuis une source saine, puis à vérifier les tables et options impactées, avant de remettre en ligne.
Le compromis: analyser une base de données en profondeur peut prendre du temps. Je privilégie une approche pragmatique: restauration cohérente et vérification ciblée, plutôt que d’explorer toutes les tables sans hypothèse.
Cas 2: WordPress est propre, mais un cron régénère l’infection
Ici, après restauration et nettoyage, le site semble stable au début, puis la réinfection réapparaît à intervalle régulier. Parfois autour d’une heure. Les logs et le comportement sont “mécaniques”.
La correction consiste à identifier la tâche planifiée ou le mécanisme qui déclenche la régénération, puis à éliminer le code associé. Dans ce cas, remplacer WordPress core est utile, mais pas suffisant si le déclencheur est dans un plugin ou un fichier additionnel.
Le signal le plus frustrant est celui-ci: vous nettoyez, puis vous regardez le site, tout a l’air normal. Et quelques heures après, retour à la case départ. C’est typiquement une régénération.
Quand il faut envisager une reconstruction plus radicale
Il existe un moment où on doit se demander si la désinfection “au fil de l’eau” devient trop coûteuse, et si une reconstruction complète est plus rapide.
Je pense à cette situation quand:
- la réinfection revient après plusieurs cycles de restauration les logs indiquent une activité persistante qui ne correspond pas à vos changements vous n’avez plus confiance dans l’intégrité de l’environnement, par exemple accès hébergement compromis ou sauvegardes douteuses
Dans ces cas, je recommande une reconstruction depuis zéro, en repartant d’une base saine, en réinstallant proprement, puis en réimportant uniquement le contenu nécessaire. C’est plus lourd au début, mais souvent moins frustrant au final.
Dernières vérifications avant de déclarer le site “réparé”
Avant de relancer pleinement le site, faites une série de contrôles qui valident la stabilité. Pas besoin de tout automatiser, l’essentiel est de vérifier les points qui déclenchent la réinfection.
Je conseille au minimum de contrôler:
- la liste des plugins et thèmes actifs, sans surprise les utilisateurs à rôles élevés la cohérence versions WordPress et PHP, et l’absence d’erreurs inhabituelles la stabilité après une visite de test et quelques actions simulées (connexion, page dynamique, chargement des ressources)
Si vous constatez un changement après test, n’interprétez pas cela comme “un détail”. Dans un contexte de réinfection, chaque changement est une information.
Point final: la désinfection WordPress n’est pas seulement un nettoyage
Une réinfection après restauration, c’est un message clair: le site n’a pas retrouvé un état isolé et contrôlé. Il a retrouvé un état fonctionnel, mais pas nécessairement un état sécurisé.
La clé, c’est de traiter la cause, pas uniquement les symptômes. Vous coupez l’accès, vous restaurez de manière cohérente, vous éliminez les mécanismes de régénération, puis vous vérifiez la stabilité. Et surtout, vous corrigez ce qui a permis à l’incident de se reproduire, plugin vulnérable, identifiants, droits trop larges, ou environnement serveur.
Si vous voulez, décrivez-moi les symptômes que vous observez après restauration (type de pages modifiées, présence de redirections, comptes qui apparaissent, délai de retour), ainsi que votre méthode de sauvegarde. Je peux vous aider à identifier le vecteur le plus probable et à adapter la procédure à votre cas, étape par étape.