Quand un site WordPress “tombe” après un incident, la première émotion est souvent la même: panique. Ensuite vient la vraie question, celle qui change tout: est-ce que je vais pouvoir nettoyer l’infection et revenir en ligne sans perdre les contenus, les réglages et le travail accumulé depuis des mois ou des années ? Le nettoyage fichiers infectés WordPress peut se faire proprement, mais seulement si on garde en tête un principe simple: on ne repart pas de zéro, on reconstruit à partir d’un état sain, tout en préservant les données utiles.
Dans les incidents réels, on confond souvent trois niveaux de problème. Il y a l’infection de fichiers (souvent dans wp-content, parfois dans le thème ou un plugin), la compromission de la base (utilisateurs créés, droits modifiés, options changées), et la modification silencieuse (redirections, injections dans le thème, scripts qui ne se déclenchent qu’à certaines conditions). Si vous ne distinguez pas ces niveaux, vous risquez de “restaurer” dans le mauvais sens et de supprimer ce qui comptait vraiment: articles, pages, médias, formulaires, réglages SEO, et parfois même des widgets déjà configurés.
Je vous propose une approche pragmatique, pensée pour restaurer WordPress sans perdre vos contenus. Elle s’appuie sur des actions concrètes, des vérifications simples et des arbitrages assumés.
Comprendre ce que vous devez préserver avant de nettoyer
Avant de toucher quoi que ce soit, prenez cinq minutes pour lister ce qui est précieux pour vous. Sur un site WordPress, ce n’est pas seulement “les articles”. Les contenus incluent aussi les médias (images, PDF), les éléments de design (thèmes, fichiers du thème enfant, custom CSS), et les dépendances (polices, scripts chargés, shortcodes).
Ensuite, distinguez ce qui doit rester intact de ce qui doit être éliminé.
- Les contenus vivent principalement dans la base de données: articles, pages, catégories, tags, auteurs, commentaires, menus, réglages d’extensions. Les médias vivent dans wp-content/uploads, mais leur présence dépend aussi des enregistrements en base. Supprimer des fichiers sans cohérence avec la base, c’est le meilleur moyen de provoquer des images manquantes. Les infections, elles, vivent souvent dans des fichiers qui n’ont rien à faire là: nouveaux fichiers .php inconnus, scripts minifiés dans des dossiers atypiques, fichiers ajoutés dans wp-content/plugins ou wp-content/themes, ou modifications de quelques lignes dans des fichiers existants.
Ce cadrage change l’ordre des priorités. Si vous restaurez uniquement les fichiers WordPress “de base” sans regarder la base, vous pouvez conserver des utilisateurs indésirables ou des options injectées. À l’inverse, si vous réimportez seulement la base sans reposer une base saine pour les fichiers, vous pouvez réactiver l’infection au prochain chargement.
Mon point de vigilance principal, c’est l’alignement fichiers - base. Pour restaurer sans perdre les contenus, vous devez revenir sur un état cohérent: fichiers propres, base cohérente, et médias conservés.
Les signes qui orientent le diagnostic
Il y a des incidents très bruyants, et d’autres qui se voient à peine. Une redirection vers une page de spam est un signal évident. Une amélioration “bizarre” du site, des formulaires qui répondent en 200 mais en réalité déposent autre chose, ou des articles qui se mettent à afficher du contenu étrange à des endroits précis, sont plus trompeurs.
Quand vous regardez l’accès et les logs, vous cherchez des patterns. Un déclencheur temporel est fréquent: certaines charges malveillantes ne se produisent qu’à des heures précises, ou seulement pour certains agents utilisateurs. Dans ces cas, une simple inspection manuelle du code ne suffit pas toujours, et une restauration trop rapide sans vérification produit un faux sentiment de sécurité.
Un autre indice très utile est la présence de fichiers récents. Dans wp-content/uploads, une explosion de nouveaux fichiers peu cohérents (noms aléatoires, images qui ne “sont pas des images”, ou dossiers créés à la hâte) peut signaler un mécanisme de vol de ressources. Dans les plugins et thèmes, cherchez des fichiers modifiés alors que personne n’a mis à jour depuis longtemps.
Même sans outil de sécurité avancé, vous pouvez déjà gagner beaucoup de temps en comparant les dates de modification et en repérant les ajouts.
Préparer une restauration “sans perte” (et sans nouvelle contamination)
Le piège le plus classique est de nettoyer “en production” sous pression, pendant que l’attaque continue. Votre serveur ne se comporte pas comme un laboratoire. Les accès malveillants continuent, les robots inspectent, parfois une seconde charge malveillante s’ajoute pendant que vous travaillez.
La stratégie la plus sûre consiste à travailler hors du site en ligne, puis à valider avant de remettre en production. Selon votre hébergement, vous avez plusieurs options: mode maintenance, clonage de l’instance sur un sous-domaine, ou récupération sur un dossier de staging.
Avant toute action, créez des sauvegardes qui ont du sens. Une sauvegarde “à l’aveugle” est moins utile qu’une sauvegarde utilisable pour reconstituer l’état. Ici, la base de données et les fichiers doivent être pris en compte.
- Export base de données (au minimum via une export SQL). Copie complète des fichiers du répertoire WordPress, au minimum wp-content et tous les fichiers susceptibles d’être compromis, plus wp-config.php pour comprendre la configuration. Vérification que les sauvegardes sont lisibles et exportées correctement.
Je sais que tout le monde n’a pas cette discipline au quotidien, mais après un incident, c’est le moment où c’est le plus rentable. J’ai déjà vu des restaurations “cassées” parce que le fichier SQL était incomplet, ou parce qu’on avait copié wp-content en oubliant un sous-dossier crucial.
Méthode de restauration en gardant vos contenus: l’approche fichiers propres + base cohérente
L’objectif est double: éliminer l’infection, puis retrouver un site fonctionnel avec vos contenus. Le “nettoyage fichiers infectés WordPress” devient alors moins une chasse au hasard qu’une reconstruction contrôlée.
Le principe opérationnel que j’utilise souvent est celui-ci: 1) figer l’accès au site pour stopper la propagation, 2) remettre les fichiers à une version saine, 3) réimporter la base la plus proche de l’état sain, 4) valider, puis restaurer uniquement les parties utiles (médias, réglages, thèmes personnalisés).
Dans la pratique, il y a plusieurs variantes selon votre situation. Mais l’idée reste la même, et le diable se cache dans les détails de cohérence.
Étape par étape (version actionnable)
Mettez le site en maintenance et limitez l’accès si possible (au moins aux administrateurs) pour éviter que des sessions et des modifications continuent pendant que vous travaillez. Faites une sauvegarde complète et vérifiez qu’elle est exploitable (export SQL + copie des fichiers). Remplacez les fichiers WordPress non custom par une version saine (par exemple via une source WordPress officielle), puis ne remettez que ce qui est légitimement votre: thème enfant, thèmes custom, plugin custom, éventuellement wp-content/uploads. Réimportez la base de données depuis un point antérieur à l’infection, puis ajustez si nécessaire les tables liées aux plugins ou aux réglages. Ensuite, validez la cohérence (médias présents, menus, utilisateurs, formulaires).Cette méthode évite le scénario où vous “nettoyez” en supprimant des fichiers, puis vous perdez des médias parce que la base pointe vers des images qui n’existent plus, ou l’inverse, vous gardez des fichiers injectés parce que vous avez conservé wp-content tel quel.
Le nerf de la guerre: choisir le bon moment pour la base
La base est souvent le point le plus dangereux et le plus difficile. Sur un site infecté, la base peut contenir:
- des comptes administrateur ajoutés, des options modifiées (redirections, scripts injectés), du contenu ou des pages ajoutés, parfois masqués, des entrées de plugins modifiées.
Si votre sauvegarde de base date de la veille, c’est probablement le meilleur choix. Si elle date de plusieurs semaines, vous récupérez les contenus, mais vous risquez de perdre des modifications récentes. C’est un compromis, et il faut le faire en connaissance de cause.
Une règle qui m’a bien servi: privilégier la sauvegarde la plus proche du moment avant l’incident, même si vous perdez un peu d’activité récente, plutôt que de restaurer un état infecté “moins ancien”. On peut souvent récupérer des contenus récents manuellement, mais on ne récupère pas facilement une infection persistante sans recommencer.
Remplacer “proprement” les fichiers sans casser votre design
Remplacer les fichiers WordPress “standard” n’est généralement pas risqué, mais il faut distinguer le cœur de WordPress des éléments personnalisés.
Dans un incident, j’ai tendance à considérer ce qui suit comme candidat à la suppression ou au remplacement systématique:
- fichiers modifiés dans des dossiers où ils ne devraient pas l’être, fichiers ajoutés sans raison dans wp-content/plugins ou wp-content/themes, fichiers php inconnus à la racine ou dans des sous-dossiers inattendus.
En revanche, ce qui doit être préservé dépend de votre setup. Un thème enfant est presque toujours vital. Un thème custom peut inclure des templates, des hooks, parfois des assets (JS, CSS). Les uploads, eux, sont des médias qui doivent survivre.
Une approche raisonnable consiste à repartir d’une structure saine, puis à réinjecter:
- wp-content/uploads si vous avez de bonnes raisons de croire qu’il n’est pas la source principale de l’infection, votre thème enfant ou thème custom, vos plugins custom, si vous savez lesquels étaient installés avant l’incident.
Si vous n’êtes pas sûr, vous pouvez aussi garder wp-content/uploads mais filtrer soigneusement les fichiers suspects. Le filtrage peut être délicat, car il y a des cas légitimes (uploads de fichiers PHP chez certains utilisateurs, ou scripts PDF qui ressemblent à des noms étranges). Je préfère souvent adopter un principe: si un fichier dans uploads n’a pas un format attendu (images, documents) ou si son contenu ne correspond pas, je le mets à l’écart. Mais je ne le fais pas à la chaîne sans validation, car vous pourriez casser un workflow réel.
Et les plugins, on fait quoi quand ils sont la cause ?
Souvent, l’infection “vient” d’un plugin compromis. Parfois c’est un plugin obsolète, parfois un plugin téléchargé hors des canaux habituels, parfois un plugin légitime mais modifié à la main sans que l’équipe s’en rende compte.
L’erreur que je vois régulièrement est de restaurer la base et les fichiers, puis de réactiver tous les plugins d’un coup. Si un plugin est la porte d’entrée, l’infection revient pendant que vous observez encore.
Une gestion propre passe par une séquence de retour graduelle:
- réactiver uniquement les plugins indispensables, vérifier les pages les plus critiques, surveiller les logs et les requêtes, puis réintroduire le reste.
Cela ne garantit pas à 100% l’absence de résidu, mais ça réduit fortement la probabilité d’un retour immédiat.
Sur le plan pratique, si vous n’avez pas la certitude qu’un plugin n’a pas été altéré, il vaut mieux le réinstaller à partir d’une source sûre, ou le remplacer par une version saine, plutôt que de “nettoyer à la main” des fichiers dans wp-content/plugins.
Contrôler sans perdre: vérifications concrètes après restauration
Une restauration n’est pas “terminée” parce que le site s’affiche. Vous voulez vérifier trois choses: cohérence des contenus, absence de traces actives, et sécurité des points d’entrée.
Voici les vérifications que je fais presque systématiquement, parce qu’elles révèlent des problèmes que l’œil ne voit pas immédiatement.
1) Validation front et https://gardewp.fr/nettoyage-malware-wordpress/ contenu
Vérifiez des pages publiques qui utilisent:
- le contenu typique (article avec images, galerie si vous en avez), les menus et catégories, les formulaires (si vous avez des formulaires embarqués), les pages qui chargent le thème (templates différents).
2) Validation base côté données
Dans l’admin, regardez la liste des utilisateurs. Cherchez ceux qui ne devraient pas être là. Regardez aussi si des rôles “élevés” ont changé. Si vous repérez un utilisateur étrange, ce n’est pas juste un nettoyage, c’est un signal que la base n’est peut-être pas la bonne version ou qu’un mécanisme de persistance existe.3) Validation des fichiers sensibles
Portez une attention spéciale à wp-config.php, aux fichiers modifiés récemment, et aux endroits où le thème injecte du code (par exemple functions.php dans un thème enfant ou des templates). Une injection peut être minuscule: une fonction qui inclut un fichier externe, un base64 stocké quelque part, une condition sur l’agent utilisateur.4) Surveillance serveur
En quelques heures, les logs vous disent si l’attaque continue. Si vous observez toujours des requêtes vers des chemins bizarres, vous devez prolonger la chasse avant de déclarer l’incident “terminé”.La raison pour laquelle je détaille ce point, c’est que beaucoup de restaurations “réussies” échouent après coup. L’infection n’est pas toujours supprimée, elle peut rester sous forme de tâche ou d’appel récurrent.
Cas limites qui posent problème (et comment choisir)
Il y a des situations où “restaurer sans perdre” devient une expression compliquée. Pas parce que c’est impossible, mais parce que les données ont été touchées au même niveau que l’infection.
1) La base de données semble saine, mais les pages s’affichent mal
Dans ce cas, l’infection est souvent dans les fichiers du thème ou dans un plugin. Vous pouvez avoir du contenu correct en base, mais le rendu public est modifié.
La solution logique: revenir à un thème sain. Si vous avez des modifications custom, récupérez seulement celles qui sont légitimes (par exemple votre thème enfant), puis comparez les fichiers à la version saine du thème parent si nécessaire.
Trade-off: vous pouvez perdre un peu de custom si vous ne savez pas reconstruire exactement le fichier. C’est pour ça que je recommande, quand c’est possible, de garder une trace des modifications (ou au minimum un historique des versions). Un incident révèle vite ce qui était “dans la tête” plutôt que dans le code documenté.
2) La base est probablement infectée, et vous n’avez qu’une sauvegarde vieille
Si votre seule sauvegarde remonte à plusieurs semaines, vous êtes face à un choix: reconstruire l’état sain en acceptant la perte des modifications récentes, ou tenter un “nettoyage ciblé” de la base actuelle.
Nettoyage ciblé: il faut être très rigoureux. Sans automatisation ni analyse, on peut rater une option ou un champ. Et comme l’infection peut être persistante, l’erreur revient souvent sous forme de “ça marche un jour puis ça casse”.
Dans ces cas, je préfère la restauration propre depuis la sauvegarde la plus proche de l’état pré-incident, même si ça implique de refaire quelques mises à jour manuelles (articles écrits récemment, pages modifiées, import de médias). Oui, c’est du temps. Mais au moins vous repartez avec une base de travail fiable.
3) Les médias “disparaissent” après restauration
C’est un classique quand uploads ou des droits ont été modifiés, ou quand on a restauré une base qui pointe vers des médias qui ne sont pas présents.
Le correctif dépend de la divergence. Si la restauration de base est correcte mais que les fichiers médias ne suivent pas, vous devez ré-aligner. Souvent, c’est une question de cohérence entre:
- les fichiers réellement présents dans wp-content/uploads, les entrées dans la base qui décrivent ces médias.
Trade-off: vous pouvez récupérer des médias à partir de l’ancienne copie des fichiers, mais il faut éviter de réintroduire des fichiers infectés. Là aussi, la validation par inspection des fichiers suspects et la vérification visuelle des médias (au moins échantillonnage) comptent.
Un plan simple pour éviter que ça recommence
Le nettoyage est indispensable, mais l’attaque future est la vraie dépense si vous ne sécurisez pas ensuite. Le but n’est pas de transformer WordPress en forteresse, mais d’éliminer les points d’entrée les plus courants.
Dans la majorité des cas, la persistance vient d’une combinaison de facteurs: mots de passe faibles, plugins obsolètes, mises à jour différées, et absence de contrôle d’intégrité des fichiers.
Voici ce que je garde comme ligne directrice, avec des choix pragmatiques:
1) Mettez à jour et supprimez
2) Contrôlez les accès
Renforcez les mots de passe, surtout ceux des comptes admin. Si votre hébergement le permet, activez l’authentification à deux facteurs pour les comptes à privilèges.3) Surveillez les fichiers modifiés
Après une restauration, identifiez les fichiers qui changent. Si vous voyez des modifications inattendues dans des fichiers sensibles, vous ne devez pas seulement “nettoyer”, vous devez comprendre la cause.4) Limitez les droits d’écriture
Assurez-vous que le site et les plugins n’ont pas des permissions trop larges. Sur certains hébergeurs, des droits mal réglés facilitent la compromission.5) Prenez des sauvegardes testées
Une sauvegarde qui ne se restaure pas au test est une sauvegarde fictive. Après un incident, j’insiste toujours pour faire un test de restauration sur un environnement de staging, même si c’est léger.C’est rarement spectaculaire, mais c’est efficace, surtout sur la durée.
Mettre en place une “restauration sans perte” crédible dès la première heure
Si vous êtes en plein incident, vous n’avez pas le luxe d’attendre. Ce que vous voulez, c’est un fil conducteur qui évite les erreurs coûteuses. Le fil conducteur ressemble plus à une méthode qu’à une liste de “clics”.
Le point clé, c’est que “sans perdre les contenus” dépend de la discipline au moment où l’on fige l’état et où l’on choisit la source des contenus. Si vous travaillez sur un état instable, vous risquez de restaurer un mix entre base saine et fichiers infectés, ou base infectée et fichiers propres. Dans les deux cas, vous perdez du temps, et parfois des contenus.
Pour vous aider à prendre une décision rapide, voici une mini-lecture de situation, sans promesse magique, mais avec un cadre.
Si vous avez une sauvegarde de base récente avant l’incident, c’est votre meilleure boussole. Si les fichiers du thème et des plugins ont des modifications douteuses, reconstruisez à partir de versions saines. Si vous gardez uploads, filtrez l’évidence des fichiers suspects et validez au moins visuellement un échantillon. Si les pages publiques changent malgré une base saine, cherchez dans le thème et la logique de rendu. Si vous observez des requêtes bizarres dans les logs après restauration, l’infection n’est pas finie.Cette logique n’élimine pas toutes les surprises, mais elle réduit énormément les “mauvaises restaurations” qui finissent par vous obliger à recommencer.
Ce que j’aimerais savoir avant de restaurer (quelques retours terrain)
Une fois que l’incident est passé, on a souvent un regret: “j’aurais dû…”. Les regrets qui reviennent le plus dans les équipes WordPress sont rarement techniques en soi. Ils portent plutôt sur la préparation.
Le premier regret concerne l’absence de documentation simple. Quand tout s’est passé vite, personne ne sait quels plugins sont custom, quels thèmes sont modifiés manuellement, ou où se trouvent les fichiers essentiels (par exemple un thème enfant qui n’est pas dans un dépôt). Résultat, la restauration devient une exploration.
Le second regret porte sur les sauvegardes non testées. On a une archive, mais au moment de restaurer, on découvre qu’elle ne correspond pas à la version PHP, ou qu’elle est incomplète, ou qu’elle ne s’importe pas correctement. Tester une restauration en amont coûte moins cher que revivre la même panne.
Le troisième regret est la tentation de “nettoyer en supprimant”. Supprimer un dossier parce qu’il “a l’air suspect”, puis découvrir que des médias utilisés dans les articles ont été embarqués dans ce dossier, c’est le genre de perte qui fait mal. Restaurer sans perdre implique de préserver ce qui compte, et d’éliminer ce qui est prouvé.
Ces retours ne remplacent pas une analyse approfondie quand elle est nécessaire, mais ils rendent la méthode plus solide.
Réussir le nettoyage sans perdre les contenus, en pratique
Si je devais résumer l’esprit de la démarche, ce serait: restaurer par cohérence, pas par instinct. Le nettoyage fichiers infectés WordPress n’est pas seulement une opération “anti-fichier”. C’est un travail de reconstitution d’un état sain, en respectant la relation entre les fichiers et la base.
Quand vous gardez votre base cohérente, vos médias alignés, et vos fichiers essentiels replacés avec des versions propres, vous avez de bonnes chances de récupérer le site sans amputations. Et quand vous surveillez les logs après coup, vous évitez le piège du “ça a l’air bon” qui finit en rechute.
Si vous vous retrouvez dans cette situation, dites-vous simplement une chose: votre objectif n’est pas de retrouver un site qui s’affiche. Votre objectif est de retrouver un site qui reste fiable, et qui ne réactive pas l’infection dès la première journée. C’est ce qui transforme un nettoyage sous stress en restauration maîtrisée.