Comment faire une désinfection WordPress sans perdre vos contenus

Une désinfection WordPress qui se passe “sans perdre vos contenus” n’est pas une question de chance. C’est une suite de décisions, prises au bon moment, avec une méthode qui protège la base de données, les médias, et la structure du site. Quand un site est compromis, on a souvent deux urgences qui s’opposent: nettoyer vite pour stopper la compromission, et vérifier avec soin pour ne pas supprimer par erreur des pages, des images, ou des réglages qui ne sont pas la cause du problème.

Dans cet article, je déroule une approche réaliste, celle que j’ai vue fonctionner sur des cas très variés: redirections invisibles, scripts injectés dans les fichiers, thèmes ou plugins qui deviennent des portes dérobées, sites qui chargent des chargeurs depuis des domaines tiers, ou encore des tâches cron malveillantes. L’objectif est simple: désinfecter, restaurer la confiance, et garder un historique récupérable au moindre doute.

Avant de toucher à WordPress, il faut définir ce qui compte pour vous, et ce qui peut être reconstruit sans douleur.

Dans la majorité des incidents, votre contenu “métier” se trouve dans deux endroits:

Le reste est “reconfigurable” plus facilement: thèmes, plugins, fichiers du noyau, caches, certains fichiers de configuration. Cela ne veut pas dire que vous pouvez effacer sans réflexion, mais ça change l’ordre des priorités.

Quand on se précipite sur “réinstaller WordPress”, https://gardewp.fr/ on risque d’écraser accidentellement des fichiers spécifiques à votre hébergement (par exemple wp-config.php), de perdre des configurations de plugins si elles sont stockées dans des fichiers plutôt que dans la base, ou de supprimer des répertoires utilisés par un builder visuel. Et surtout, on peut désinfecter superficiellement, puis laisser en place un plugin compromis qui continue à réinjecter du code.

La règle que j’applique presque systématiquement: tant que vous n’avez pas une copie de travail fiable, vous ne “nettoyez” pas, vous “préparez” le nettoyage.

Beaucoup de gens disent “j’ai un backup”. Souvent, il s’agit d’une sauvegarde automatique que personne n’a vérifiée depuis des semaines, ou d’une archive incomplète (excluant la base de données), ou d’un point de restauration inutilisable car le fichier a été écrasé.

Votre copie de travail doit couvrir ce qui fait courir le risque. Pour rester concret, prévoyez une sauvegarde qui inclut au minimum base de données et fichiers WordPress, et idéalement un export complémentaire de vos contenus.

Voici le minimum que je conseille de cocher avant d’attaquer le nettoyage:

Le point “restaurable” paraît bureaucratique. En pratique, c’est souvent là que se fait la différence entre un incident récupéré proprement et une restauration à moitié impossible.

Si vous êtes sur un VPS ou un hébergement géré, la copie peut passer par un outil de l’hébergeur, cPanel, un snapshot, ou un plugin. Le principe reste le même: vous voulez un état que vous pouvez réinstaller rapidement, pour ne pas dépendre de votre intuition pendant une enquête.

Quand un site est compromis, la page infectée peut encore être alimentée en contenu malveillant, ou l’attaquant peut continuer à modifier des fichiers. En paralysant le site de façon contrôlée, vous gagnez du temps, vous réduisez les risques pour vos visiteurs, et vous évitez de “cacher le crime” en écrasant les traces.

Selon votre contexte, “mettre en pause” peut vouloir dire:

Évitez simplement de supprimer tout le site ou de changer brutalement la config réseau. Ce qui est utile, c’est une fenêtre d’investigation où vous conservez la possibilité d’observer les fichiers modifiés, et où les visiteurs ne reçoivent plus le code injecté.

Désinfecter sans perdre vos contenus, ça veut dire: traiter la cause, pas seulement les symptômes. La difficulté, c’est que les symptômes ressemblent parfois à des problèmes “légitimes” (thème cassé, plugin qui bug, cache qui se mélange, redirection vers une page 404, formulaire qui disparaît).

Sur WordPress, les compromissions suivent souvent des schémas. J’ai vu le plus fréquent se classer en grandes familles:

Parfois, le noyau WordPress ou des fichiers directement au-dessus (wp-config.php, fichiers root, includes) contiennent un fragment ajouté. Cela peut être très discret.

Un plugin “gratuit” ou un thème “custom” peut contenir un code qui s’exécute à chaque chargement. Dans certains cas, seul un fichier précis a été modifié, dans d’autres, toute une arborescence a été ajoutée.

Le contenu des pages est parfois modifié, ou des options WordPress sont changées. Des injections peuvent aussi être stockées dans des champs, ou dans des scripts internes.

Des cron malveillantes peuvent réécrire des fichiers ou injecter du contenu même après une reinstallation.

La bonne désinfection dépend du vecteur. Si vous réinstallez tout sans traiter le cron, le problème revient. Si vous nettoyez uniquement les fichiers visibles, mais que les options en base gardent une redirection, vous aurez une rechute.

L’approche la plus sûre que j’ai utilisée consiste à comparer, avant modification. L’idée n’est pas de “tout lire”, mais de repérer ce qui a changé par rapport à un état attendu.

Si vous avez accès à un historique via votre hébergeur, un snapshot, ou au moins à une copie propre des fichiers (par exemple un WordPress standard du même version), vous pouvez:

La plupart du temps, la compromission laisse des signatures. Elles peuvent être codées, compressées, encodées en base64, ou masquées dans des conditions. Vous n’avez pas besoin de comprendre chaque caractère, vous avez besoin de reconnaître un comportement non attendu, puis d’éliminer la source.

Un point important: ne supprimez pas d’un coup les fichiers “qui vous https://gardewp.fr/nettoyage-malware-wordpress/ semblent bizarres” si vous n’êtes pas certain qu’ils ne contiennent pas votre contenu. Par exemple, certains builders ou plugins de mise en page stockent des données dans des fichiers spécifiques ou appellent des templates. C’est là que la sauvegarde et la restauration testée prennent tout leur sens.

Une méthode qui limite le risque de perdre les contenus consiste à distinguer code et contenus.

Votre plan général, sans inventer d’étapes inutiles, peut ressembler à ceci dans l’esprit:

Le piège, c’est de faire “remplacement du code” en écrasant tout wp-content, puis de découvrir que vos images ont disparu, ou que votre thème custom n’était pas dans la copie que vous avez remplacée.

Le bon compromis: remplacer ce qui est “standard et remplaçable”, protéger ce qui est “contenu et configuration”.

En pratique, si vous n’avez pas la certitude que vos thèmes et plugins sont sains, les retirer et les réinstaller depuis des sources officielles est souvent plus sûr que de “patcher” à l’aveugle.

Le noyau WordPress: oui, réinstallez-le. C’est un composant que vous pouvez récupérer proprement. Il contient peu de contenu métier.

Wp-config.php: ne le réécrivez pas sans vérifier. C’est lui qui relie WordPress à la base et définit des clés. Une erreur ici, et vous pouvez casser le site plus que le malware ne l’a fait.

Uploads: gardez-les. Sauf cas où un fichier téléchargé est lui-même la source de l’infection. Dans ces cas, la désinfection peut nécessiter de nettoyer des médias ou de bloquer l’exécution de certains types. Mais dans l’immense majorité des compromissions, les images et documents ne sont pas la cause principale. C’est souvent du code PHP injecté.

Thèmes: si vous avez un thème custom, la question se complique. Si c’est un thème de tiers, vous pouvez le remplacer par une version propre. Pour un thème custom, vous pouvez reconstruire en repartant d’une version saine, ou restaurer depuis git si vous l’avez suivi. Sinon, vous pouvez faire un examen ciblé des fichiers modifiés. Ce choix dépend du niveau de confiance dans votre thème.

Plugins: si un plugin est suspect ou inconnu, le supprimer et réinstaller proprement est le chemin le plus sûr. Quand on garde un plugin compromis “juste au cas où” et qu’il continue à s’exécuter, on se retrouve à désinfecter en boucle.

C’est souvent là que les gens perdent du temps ou du contenu. Ils se disent “la base est compromise” et tentent une suppression brute de tables ou d’entrées. Selon le scénario, ça peut casser des relations ou supprimer des contenus réels.

Une approche pragmatique consiste à cibler ce qui a été modifié, ou ce qui stocke du code exécutable.

Sans prétendre à une liste universelle de tables à effacer, j’observe généralement des altérations dans:

Ce que je recommande, c’est de travailler avec un dump de la base, et de faire des modifications en local si vous avez la capacité. Si vous devez agir en production, faites-le sur une copie restaurée, puis testez.

Pour préserver vos contenus, le principe reste: ne supprimez jamais des pages ou des articles parce qu’ils “contiennent quelque chose” sans comprendre où et pourquoi. Parfois, le code malveillant est injecté dans un champ texte d’un plugin ou dans un bloc. Le supprimer peut être trivial, alors que supprimer tout l’article serait disproportionné.

Un site WordPress compromis, c’est souvent aussi un accès. Même si le code malveillant est supprimé, l’attaquant peut conserver un compte administrateur, ou un compte avec des droits élevés.

C’est pour cela que la désinfection WordPress ne se limite pas à “nettoyer les fichiers”. Vous devez aussi:

Il y a un détail que je prends toujours le temps de vérifier: les comptes “fantômes” peuvent avoir été créés avec un rôle particulier, et la personne légitime n’a même pas connaissance de leur existence tant que le site ne se comporte pas anormalement.

Les tâches planifiées sont un grand classique. Elles peuvent, par exemple, recompiler du code, importer un contenu, ou modifier des fichiers à chaque exécution.

Le piège, c’est la fausse sensation de victoire: vous remplacez des fichiers, tout semble propre pendant quelques heures, puis le site réinfectionne.

Si vous avez accès au système, vérifiez:

Là encore, la bonne méthode est d’observer d’abord, corriger ensuite, et tester avant de repasser en mode “normal”.

Une fois le site nettoyé, vous ne voulez pas juste “tenir la semaine”. Les compromissions se répètent souvent quand le point d’entrée n’a pas été corrigé: mot de passe faible, plugin obsolète, thème abandonné, absence de limitation sur les tentatives de connexion, ou configuration serveur trop permissive.

Il est tentant d’activer des protections lourdes d’un coup. En production, cela peut créer des faux positifs, bloquer votre formulaire, casser un flux, ou empêcher des tâches légitimes.

Le mieux est de durcir progressivement, en gardant un œil sur vos plugins et sur votre espace de travail.

Voici un exemple de mesures généralement pertinentes, à adapter à votre environnement, sans entrer dans un guide “tout ou rien”:

Je précise ce point car j’ai déjà vu des WAF trop stricts bloquer des endpoints d’un plugin d’abonnement, ou casser une intégration de paiement. La désinfection réussie n’est pas seulement “plus propre”, c’est “plus stable”.

Quand le site est “restauré”, ce n’est pas fini. Vous devez vérifier que:

Sur un site WordPress, les tests les plus rentables sont ceux qui confrontent votre site aux usages réels: navigation, pages critiques, formulaires, recherche, et accès admin.

Avant de repasser en ligne, je fais aussi un contrôle des fichiers modifiés et des permissions. Ça peut sembler répétitif, mais c’est la différence entre “ça marche” et “ça va tenir”.

Voici une petite séquence de vérification utile, simple, sans transformer l’intervention en marathon:

Cette liste ne remplace pas une analyse complète, mais elle évite l’erreur la plus courante: remettre en ligne alors qu’un composant encore infecté n’a pas encore eu l’occasion de se manifester.

Ça se transforme souvent en chantier. Sans dire que c’est impossible, ça augmente le risque de perdre la correspondance entre anciennes URL, nouvelles structures, et tailles de vignettes. Les permaliens, les liens internes, et les caches peuvent aussi diverger.

Si vous gardez uploads et que vous remplacez seulement ce qui doit l’être, vous réduisez drastiquement le risque.

Certains plugins stockent des blocs, des shortcodes, ou des métadonnées interprétées dans vos pages. Supprimer un plugin peut ne pas supprimer vos pages, mais peut rendre certains contenus invisibles ou cassés.

Le bon réflexe est de tester après chaque retrait, et si possible de remplacer le plugin par une version saine avant de déclarer victoire.

Si vous regardez un champ et qu’il contient du code inattendu, il peut sembler logique de supprimer toute la ligne. Mais si cette ligne contient aussi des paramètres utiles, vous perdez potentiellement des options, ou pire des blocs de contenu.

La désinfection doit être ciblée. Quand vous doutez, faites une restauration à partir de la sauvegarde de travail, modifiez sur une copie, puis comparez.

Un détail qui paraît “organisationnel”, mais qui évite des pertes de contenu: notez ce que vous faites, même brièvement. Date, étape, fichiers touchés, plugins désactivés, options modifiées.

Quand un incident se poursuit sur plusieurs jours, ou quand vous devez repasser en arrière, ce journal devient une boussole. Il vous empêche d’oublier une action qui explique pourquoi un comportement revient.

C’est particulièrement vrai si vous travaillez en équipe, ou si vous devez confier une partie à quelqu’un d’autre. Sans traces, vous finissez par refaire deux fois la même désinfection.

Une désinfection WordPress réussie n’est pas uniquement “un site qui ne renvoie plus de spam”. Elle se mesure aussi à la stabilité:

Le signe que vous avez bien protégé le contenu, c’est que vous pouvez naviguer dans vos pages comme d’habitude, vérifier vos images, vos médias, vos blocs, et vos formulaires, sans découvrir que la structure de votre site a été “nettoyée” trop agressivement.

Parfois, l’analyse montre trop d’éléments suspects, trop de fichiers modifiés, et une base difficile à sécuriser proprement. Dans ce cas, restaurer depuis une sauvegarde antérieure peut être plus efficace que de patcher au cas par cas.

La décision dépend de deux facteurs:

Si vous restaurez, vous devez aussi traiter ce qui a permis l’accès. Sinon, vous avez juste remis à plat, puis re-déclenché le même incident.

C’est le fil rouge de la méthode pour “ne pas perdre vos contenus”. Une désinfection WordPress solide se fait avec une copie de travail, des tests, et des retours en arrière possibles.

Quand vous n’avez pas de copie, vous jouez aux devinettes. Quand vous avez une copie, vous pouvez observer, modifier, valider, puis seulement ensuite revenir en production.

Vous économisez du temps. Vous perdez moins de contenu. Et surtout, vous reprenez le contrôle de votre site avec un minimum de stress et une méthode défendable.

Si vous me décrivez votre situation (type d’incident, plugins installés, si vous avez une sauvegarde récente, et ce que vous observez côté redirections ou code source), je peux vous proposer une démarche plus ciblée, avec les points à vérifier en priorité pour préserver vos contenus.