Quand un site WordPress commence à “agir bizarrement”, la tentation est grande de tout nettoyer à la hâte, puis de remettre en ligne. Sauf que l’urgence est souvent le pire moment pour improviser. Une suppression maladroite de fichiers, une restauration partielle, ou une réinstallation trop tôt peuvent rendre des contenus inaccessibles, casser une mise en cache, ou pire, laisser la cause en place.
Le bon objectif, c’est simple à formuler et délicat à exécuter: enlever le virus WordPress sans perdre vos données, donc sans effacer vos publications, vos pages, vos médias, vos réglages, et sans vous retrouver avec un site “propre” qui ne fonctionne plus. Dans cet article, je vous propose une méthode réaliste, celle qu’on suit en intervention quand le temps compte, mais que l’on garde le contrôle sur ce qui change.
Comprendre ce que vous appelez “virus” sur WordPress
Sur WordPress, le terme “virus” recouvre des réalités très différentes. Parfois, c’est du code malveillant dans un fichier PHP, souvent déguisé dans un répertoire d’extensions ou de thèmes. Parfois, ce sont des comptes https://gardewp.fr/ administrateurs ajoutés, des mots de passe changés, ou des réglages modifiés de manière silencieuse. D’autres fois, l’attaque ne touche pas vos fichiers principaux, elle exploite plutôt la base de données: redirections, injecteurs de contenu, liens cachés, ou scripts stockés qui s’exécutent au rendu.
Le point important: ces formes d’attaque se traitent différemment. Réinstaller WordPress à l’identique, ce qui est parfois recommandé, n’efface pas forcément une porte dérobée dans un plugin compromis, ni une tâche planifiée injectée, ni un fichier ajouté dans un répertoire qui n’appartient pas à l’installation WordPress “standard”.
Donc avant de supprimer, il faut d’abord protéger et diagnostiquer, même brièvement. Cela évite de faire disparaître des éléments utiles, ou de “nettoyer” en réalité sans éradiquer.
Les premiers gestes pour ne pas aggraver la situation
La phase initiale est celle où l’on gagne du temps. Elle consiste à stopper l’hémorragie, puis à figer l’état du site pour pouvoir revenir en arrière.
La plupart des incidents que j’ai vus suivent le même scénario: le site tombe partiellement en panne, puis des utilisateurs ou des robots arrivent, pendant que le contenu https://gardewp.fr/nettoyage-malware-wordpress/ est altéré. Si vous continuez à laisser tout fonctionner sans surveillance, vous risquez d’augmenter le volume de contenus injectés, et vous multipliez le nombre de traces à analyser.
Voici ce que je fais en priorité, avant toute suppression:
- Désactiver temporairement les accès publics (maintenance ou restriction IP) pour limiter les modifications et les exécutions automatiques. Faire une sauvegarde complète des fichiers et de la base de données, idéalement avec un export SQL et une archive des répertoires concernés. Vérifier les logs (accès web, erreurs, et éventuellement logs d’authentification) pour repérer comment l’accès a été obtenu. Créer un “plan de restauration” avant de commencer: savoir exactement d’où vous pourrez repartir si quelque chose casse.
Même si vous pensez que vous avez déjà une sauvegarde, prenez le réflexe de refaire un snapshot juste avant d’agir. Une sauvegarde ancienne, ou une sauvegarde “partielle” (fichiers sans base, ou base sans médias) est une cause fréquente de perte de données.
Ce que vous devez préserver avant de “nettoyer”
Votre promesse implicite est: ne pas perdre vos données. Sur WordPress, vos données se trouvent dans deux endroits principaux:
Les fichiers: thèmes, plugins, médias (selon configuration), et certains fichiers de configuration. La base de données: articles, pages, médias (en métadonnées), utilisateurs, options, et parfois du code injecté stocké.Si vous voulez vraiment enlever un virus WordPress sans perdre vos données, la restauration doit pouvoir se faire sur la base de vos contenus, pas uniquement sur les fichiers “propres”.
Concrètement, avant toute opération risquée, je vous recommande de conserver au moins:
- un export SQL complet, une archive des répertoires WordPress (ou, au minimum, wp-content et les fichiers de configuration), et une copie des fichiers médias si vous utilisez un stockage local.
Si vos médias sont sur un service externe (S3, autre), vous devez vous assurer que l’option est bien la même au moment de la restauration. Un changement de configuration peut rendre les images “introuvables” même si elles existent toujours.
Diagnostiquer sans tout détruire
Une fois la sauvegarde faite, vous pouvez passer au diagnostic. Sur un site compromis, vous ne cherchez pas seulement “le fichier infecté”. Vous cherchez surtout à comprendre l’entrée et la persistance.
Le diagnostic le plus utile, c’est l’enchaînement logique suivant: qui a modifié quoi, et depuis quel point d’entrée.
Les signaux fréquents d’une compromission
Dans la pratique, voici les indices qui reviennent souvent quand on parle d’enlever virus WordPress:
- des redirections en page d’accueil ou sur des pages précises, parfois invisibles dans le back-office, des comptes administrateurs ajoutés sans votre action, des fichiers PHP inconnus dans wp-content, ou des “extensions” qui n’ont pas été installées par vous, des tâches planifiées (cron) qui tournent alors que vous n’avez rien configuré, des changements sur wp-config.php, .htaccess, ou des répertoires qui deviennent accessibles d’une manière inhabituelle.
Ce n’est pas une liste “universelle”, mais elle aide à orienter vos vérifications sans perdre des heures.
Où regarder en premier (sans jouer au hasard)
Si vous avez des logs, commencez par l’authentification. Recherchez des connexions dont l’IP ou l’heure ne correspond pas à votre usage. Regardez aussi les modifications de plugin ou de thème côté WordPress si votre back-office n’est pas totalement compromis.
Ensuite, examinez:
- les fichiers modifiés récemment dans wp-content (plugins et thèmes), la présence de fichiers “bizarres” dans des emplacements non attendus, la base de données pour repérer des injections de chaînes inhabituelles dans wp options ou wpposts.
Même sans outil avancé, un contrôle manuel ciblé peut vous faire gagner beaucoup de temps.
Le vrai choix: restaurer, nettoyer, ou combiner
Il existe trois approches. Elles ont toutes leurs pièges.
Option 1: restauration depuis une sauvegarde “sûre”
C’est la méthode la plus fiable quand vous avez une sauvegarde antérieure à l’incident. Vous restaurez, puis vous sécurisez pour empêcher une récidive.
Le risque, ce n’est pas la restauration en soi, c’est la “fausse bonne sauvegarde”. Si la sauvegarde a été prise pendant que la compromission existait déjà, vous réinjectez le problème. C’est pour cela qu’une vérification rapide avant restauration est utile.
Je vous conseille, si possible, de valider au minimum que la sauvegarde date d’avant les premiers symptômes. Si le journal de votre plugin de sauvegarde montre une anomalie, ou si vous constatez la même signature d’injection dans un export SQL, ne restaurez pas.
Option 2: nettoyage en supprimant les fichiers malveillants
Cette option peut suffire si le malware est simple, localisé, et que vous avez un bon inventaire de vos plugins et thèmes. Elle devient risquée si vous n’êtes pas certain de l’emplacement exact de la persistance, ou si le code a modifié des éléments dans la base.
Le piège courant, c’est de supprimer un script dans un dossier, puis de constater deux jours plus tard que la redirection revient, parce que la véritable source était ailleurs, par exemple dans une option WordPress, un champ stocké, ou un plugin légitime mais compromis.
Option 3: combiner restauration et nettoyage
Dans les interventions sérieuses, on combine souvent les deux. Par exemple, on restaure la partie “cœur” (fichiers WordPress) depuis une version propre, tout en analysant wp-content et la base de données. On garde l’accès à vos contenus, mais on remplace ce qui doit l’être.
C’est souvent la meilleure voie quand vous voulez enlever un virus WordPress sans perdre vos données, tout en gardant la main sur ce qui a été modifié.
Remplacer “le cœur” WordPress sans toucher à vos contenus
Une stratégie prudente consiste à réinstaller le cœur WordPress en conservant vos données. L’idée est de remplacer ce que WordPress fournit par défaut, tout en traitant séparément wp-content et la base.
Typiquement, cela veut dire:
- remplacer les fichiers WordPress “distribués” par une version identique (même numéro de version), conserver wp-content (mais l’inspecter, donc ne pas juste “laisser tel quel”), conserver wp-config.php avec attention, puis revalider ses valeurs, et travailler sur la base avec un export et une restauration si nécessaire.
Important: la base de données contient aussi des modifications potentiellement liées au malware. Un simple remplacement des fichiers ne suffit pas si l’attaque a persisté via des options, des tables custom, ou des injections stockées.
Nettoyer wp-content sans effacer vos médias
Sur WordPress, vos médias résident dans wp-content/uploads la plupart du temps. Les supprimer “par peur” est rarement une bonne idée. Les médias ne sont pas seulement des images, ce sont aussi des références, des tailles générées, et parfois des pièces jointes associées à vos posts.
Si vous supprimez wp-content/uploads, vous risquez d’obtenir un site qui s’affiche, mais avec des images cassées, des pièces jointes orphelines, et un historique perdu.
Une approche plus sûre:
- identifier le plugin ou le thème suspect, le mettre temporairement en pause, et remplacer uniquement ce qui est compromis.
Si vous suspectez un plugin, ne contentez pas de le désactiver. Désinstallez seulement après vérification, et gardez les fichiers pour analyse. Un plugin compromis peut avoir ajouté des fichiers cachés, pas seulement du code dans son dossier principal.
Désactiver les plugins sans perdre le site
Quand le front est compromis mais que le back-office répond, vous pouvez désactiver. Mais si vous n’avez plus accès au back-office, la méthode passe par FTP ou le gestionnaire de fichiers.
Dans la pratique, je commence par:
- mettre en désactivant tout sauf les plugins nécessaires, repérer le dernier plugin ajouté ou mis à jour avant l’incident, puis revenir plugin par plugin, en surveillant.
Cela demande du temps, mais c’est une manière de réduire la surface de dégâts. La récupération est plus simple si vous pouvez isoler un coupable.
Vérifier wp-config.php et la configuration de persistance
Wp-config.php ne devrait pas être une zone “créative”. Pourtant, sur des sites compromis, on voit:
- des champs modifiés, des constantes changées, des inclusions inattendues, ou des chemins ajoutés pour charger du code externe.
Si vous remarquez une modification sans explication, ne la “réparez” pas à l’aveugle. Comparez avec une version de sauvegarde antérieure, ou avec un modèle de votre installation saine.
Et attention au détail: parfois le malware ne modifie pas wp-config.php, il exploite une configuration d’hébergement, comme une règle .htaccess, une configuration Nginx, ou des paramètres de sécurité modifiés.
Pensez donc aussi à:
- .htaccess (si Apache), la configuration serveur (à vérifier via le panneau d’hébergement), et les réglages de “rewrite” ou de “redirect” ajoutés.
S’attaquer au malware dans la base de données (sans effacer vos contenus)
C’est souvent l’étape qui fait peur, parce qu’on a l’impression d’“ouvrir le corps” du site. Pourtant, elle est gérable si vous travaillez proprement.
L’objectif n’est pas de nettoyer la base au hasard. L’objectif est de localiser des modifications typiques. Sur WordPress, beaucoup d’attaques stockent du code ou des redirections dans des options et des contenus.
Approche prudente
Exportez votre base avant toute modification. Recherchez des chaînes suspectes dans l’export: noms de domaines, fragments de scripts, balises PHP inhabituelles, chemins de fichiers, ou mots clés dont vous ne connaissez pas l’origine. N’éditez pas en masse. Identifiez précisément les lignes qui ont changé.Si vous êtes à l’aise avec phpMyAdmin, vous pouvez naviguer. Si vous ne l’êtes pas, l’erreur classique est de courir un SQL “de nettoyage” sans comprendre ce qu’il supprime. Mieux vaut cibler.
Cas fréquent: une redirection injectée
Un cas très courant, c’est une redirection vers un domaine malveillant, déclenchée par une option ou par un contenu injecté au rendu. Vous pouvez voir le domaine dans le HTML généré, mais la source se trouve dans wp options ou dans un champ stocké dans wpposts.
Si vous supprimez les pages compromises sans restaurer les versions saines, vous perdez des contenus. Si vous remplacez uniquement les fichiers, vous ne corrigez pas la cause. Le bon compromis consiste à restaurer ce qui a été injecté, ou à supprimer uniquement les entrées malveillantes.
Contrôler les utilisateurs et verrouiller l’accès
Après un incident, ce n’est pas suffisant de “nettoyer les fichiers”. Il faut aussi empêcher la persistance via les comptes.
Je fais toujours:
- vérifier la liste des utilisateurs, en repérant ceux ajoutés récemment, changer les mots de passe (au minimum pour les comptes admin et éditeur), vérifier les rôles et capacités, et forcer une purge des sessions si l’interface vous le permet.
Si vous avez un doute sur un compte, vous pouvez le supprimer, mais seulement après avoir validé que le compte n’est pas votre seul accès légitime. Là encore, la sauvegarde SQL est votre filet.
Edge case important: certains sites ont des comptes “techniques” utilisés par des intégrations. Si vous supprimez un compte qui sert à un webhook ou à un export, vous allez casser une partie de votre chaîne, et vous risquez de confondre les symptômes. Une fois le site propre, vous pourrez réordonner les comptes.
Surveiller l’exécution, cron et tâches planifiées
WordPress utilise cron pour planifier des événements. Un malware peut y insérer des appels. Même si vous supprimez le code visible, une tâche peut recharger à nouveau des fichiers.
Si vous avez accès au back-office, regardez les tâches. Sinon, vous vérifiez côté serveur, selon votre environnement d’hébergement.
La question à vous poser: “Qu’est-ce qui tourne tout seul sur mon site?” Si vous n’avez pas programmé un déclenchement qui modifie des contenus, mais que vous constatez des changements récurrents, le cron ou une automatisation externe est une piste solide.
Quand l’attaque vient de l’hébergement (et pas de WordPress)
Parfois, ce que vous attribuez au “virus WordPress” est en fait un problème côté serveur. C’est plus fréquent qu’on ne le croit, notamment quand:
- un répertoire est mal configuré, des uploads peuvent déposer des scripts exécutable, des règles de sécurité ont été désactivées, ou des comptes shell ont été compromis.
Si vous voyez des fichiers qui réapparaissent après suppression, c’est le signe classique d’une source externe. Dans ce cas, il faut parler au support d’hébergement et demander une vérification globale, pas seulement WordPress.
Cette décision est un compromis: ça prend du temps, mais ça évite de passer des heures à “nettoyer WordPress” pendant que le vrai problème se trouve ailleurs.
Mettre en place une réinstallation propre sans perte de contenus
Si vous devez aller plus loin, vous pouvez combiner reinstallation de base et conservation des données.
Voici une approche pragmatique:
- réinstaller WordPress depuis une source officielle, copier par-dessus les fichiers du cœur, conserver wp-content/uploads et vos thèmes/plugins “propres” (après validation), restaurer la base à partir d’un export sain si nécessaire.
Ce qui change l’enjeu ici, c’est la base. Si la base contient du contenu injecté, vous devez choisir entre:
- restaurer la base à une version antérieure, ou corriger les entrées corrompues.
La décision se prend selon votre disponibilité d’historiques. Si vous avez des sauvegardes fréquentes, la restauration est souvent la voie la plus sûre. Si vous n’avez que peu d’historique, vous devrez nettoyer plus finement.
Sécuriser après l’assainissement (pour éviter la récidive)
Une fois le site propre, la sécurité doit devenir une habitude, sinon l’infection revient. Ce volet est aussi important que le “nettoyage” lui-même.
Les mesures les plus rentables, celles qui réduisent réellement la surface d’attaque, incluent:
- maintenir plugins et thèmes à jour (en surveillant les plugins abandonnés), supprimer les thèmes et plugins inutiles, appliquer une politique de mots de passe solides et uniques, limiter les accès admin et renforcer la connexion (authentification forte si possible), mettre en place une sauvegarde automatisée testée.
Le détail qui fait la différence, c’est “testée”. Une sauvegarde qui existe, mais que vous n’avez jamais restaurée dans un scénario réel, ne vous protège pas au moment critique.
Exemple concret de déroulé (sans magie, avec des arbitrages)
Je vous donne un scénario typique basé sur des situations réelles que j’ai rencontrées.
Un site vitrine affichait une page d’accueil normale pendant la journée, puis en soirée des redirections apparaissaient vers une page de spam. Le back-office n’affichait rien de suspect, mais les fichiers dans wp-content/plugins étaient modifiés. Les sauvegardes de la veille existaient, mais celle du matin semblait déjà contaminée, parce qu’un export SQL contenait des chaînes similaires.
Le plan a été le suivant:
- arrêt de l’accès public pour stabiliser, export SQL complet et archive fichiers, remplacement du cœur WordPress, inspection des plugins, et remplacement du dossier du plugin suspect par une version propre, nettoyage ciblé des entrées injectées dans la base, puis validation du front, verrouillage des comptes admin, changement des mots de passe, suppression d’un compte ajouté.
Résultat: pas de perte de contenus, parce que la correction a été ciblée et qu’on a conservé la base saine avant injection massive. Le délai a été plus long que “désactiver un plugin”, mais le site n’a pas rechuté après réouverture.
C’est ce que vous cherchez: un nettoyage qui résiste au temps, pas une réparation provisoire.
Questions qui changent tout (et réponses utiles)
“Je dois réinstaller WordPress. Est-ce que je perds mes articles?”
Si vous remplacez uniquement les fichiers du cœur et que vous conservez la base intacte, en général non. Mais si vous supprimez ou réinitialisez la base, là vous perdez du contenu. Donc, la règle pratique est simple: ne touchez pas à la base tant que vous n’êtes pas sûr de ce que vous faites, et sauvegardez-la avant.
“Mon site est en partie cassé, mais je ne vois pas le malware.”
Un site “semi-cassé” peut être la conséquence de modifications dans les thèmes, ou de versions incompatibles de plugins. Un malware peut aussi casser le front en masquant des fichiers ou en surchargeant des templates. Dans ce cas, la restauration partielle (cœur) et la désactivation progressive des plugins sont des leviers plus rationnels que des suppressions massives.
“J’ai supprimé des fichiers suspectés, mais ça revient.”
C’est presque toujours un signe de persistance ailleurs: tâche planifiée, fichier réinjecté, règle serveur, ou encore plugin réellement compromis. Ne relancez pas sans vérifier la source. Recherchez la modification “qui revient” et tracez d’où elle est alimentée.
Deux mini-checklists utiles avant réouverture
Avant de remettre le site en ligne, je vérifie deux choses, et je préfère le faire calmement, plutôt que de subir une nouvelle infection quelques heures plus tard.
Checklist de validation technique (courte):
- Le front ne redirige plus vers des domaines inconnus. Les pages clés s’affichent sans éléments injectés. Les plugins et thèmes suspects ont été remplacés ou confirmés propres. Les comptes admin sont conformes, mots de passe changés, aucun utilisateur inattendu.
Checklist de validation “données”:
- Les articles, pages et médias sont présents et cliquables. Les images s’affichent (ou au moins les URL pointent vers le bon stockage). Les formulaires et intégrations essentielles fonctionnent. Si vous avez des contenus personnalisés, ils sont visibles sans comportement étrange.
Si un seul point échoue, c’est souvent là que la cause persiste.
En pratique: le bon ordre d’action pour enlever un virus WordPress sans perdre vos données
Je résume la logique sans la transformer en procédure automatique. L’ordre change parfois selon votre accès, mais la priorité reste la même: protéger, isoler, diagnostiquer, puis réparer avec méthode.
L’ordre typique que vous voulez viser ressemble à ça: stabiliser le site, sauvegarder, isoler la source, remplacer le cœur, traiter wp-content, corriger la base si nécessaire, puis verrouiller l’accès.
Le “sans perdre vos données” tient surtout à une discipline: ne supprimez rien à grande échelle sans savoir ce qui est stocké ailleurs, et ne restaurez pas une copie dont vous n’êtes pas sûr qu’elle est saine.
Ce qu’il faut retenir
Enlever un virus WordPress n’est pas seulement un travail de suppression. C’est un travail de contrôle, de restauration cohérente, et de verrouillage. Si vous partez de la sauvegarde, que vous traitez wp-content et la base de manière ciblée, et que vous validez la persistance (comptes, cron, configuration serveur), vous réduisez fortement le risque de perdre des contenus.
La nuance la plus importante, celle que je répète depuis des années, c’est que WordPress ne “guérit” pas tout seul. Il faut une action consciente, parfois combinée: remplacer le cœur, traiter les plugins et thèmes, corriger les entrées injectées, et ensuite seulement réouvrir au public.
Si vous me décrivez votre situation, par exemple ce que vous observez (redirection, popups, compte administrateur ajouté, erreurs 500, etc.), le type de sauvegardes disponibles, et votre accès au back-office, je peux vous proposer un plan adapté, avec le niveau de risque attendu et les options pour limiter au maximum toute perte de données.