Quand un site WordPress se fait infecter, la première impression est presque toujours la même: plus rien ne “semble normal”. Une page d’accueil qui renvoie vers un domaine louche. Des redirections qui ne se déclenchent que sur mobile. Un pic de trafic inexpliqué, souvent suivi d’une chute brutale. Parfois, ce n’est pas le visiteur qui repère le problème, mais un navigateur qui bloque, la console de recherche qui s’affole, ou l’hébergeur qui signale des requêtes anormales. Le plus difficile n’est pas le diagnostic, c’est la méthode. Il faut supprimer malware WordPress sans effacer aussi les bonnes choses, et surtout sans réinfecter le site au premier retour en ligne.
Je vais détailler un chemin de travail qui tient compte des pièges courants: la restauration d’un site “propre”, le nettoyage fin quand il faut, la vérification réelle, puis le durcissement pour que l’attaque ne revienne pas par la même porte.
Comprendre ce qu’on a vraiment devant soi
WordPress est un terrain idéal pour les auteurs de scripts malveillants, non pas parce que la plateforme est “fragile”, mais parce que beaucoup de sites fonctionnent longtemps avec des habitudes risquées: plugins abandonnés, thèmes modifiés, identifiants partagés, accès administrateur trop large, hébergement mal verrouillé. Les campagnes modernes n’essaient pas toujours de détruire. Elles cherchent souvent à:
- injecter du code pour rediriger vers une autre page, créer des utilisateurs “cachés” ou ajouter des backdoors, ajouter des scripts dans des fichiers qui semblent légitimes, abuser du navigateur (drive-by) ou du SEO (pages générées automatiquement).
La première étape, avant de toucher au serveur, consiste à observer le symptôme avec méthode. Si vous pouvez encore accéder au back-office, notez ce qui a changé depuis la dernière sauvegarde: nouvelles extensions installées, fichiers modifiés, utilisateurs ajoutés, changements dans les options. Si le site est déjà en “semi panne” ou hors ligne, concentrez-vous sur les traces externes: erreurs 404 sur des chemins absurdes, requêtes répétitives vers des scripts, pages de destination inconnues, alertes de sécurité.
Une règle pratique: ne faites pas confiance à l’interface WordPress tant que vous n’avez pas vérifié les fichiers et les composants serveur. Un malware bien fait peut masquer ses traces dans l’admin, ou rendre certains écrans incohérents.
Prendre une copie avant tout, même si c’est frustrant
La tentation est forte de “nettoyer vite”. Sur le terrain, ce réflexe coûte cher quand on n’a pas de point de retour. Avant toute modification, créez une copie complète: base de données, répertoire WordPress, éventuellement les fichiers de configuration (et votre thème si vous l’avez customisé). Si vous ne pouvez pas sauvegarder tout, conservez au minimum:
- une archive du répertoire racine WordPress, un export SQL de la base (même partiel si le site est déjà instable, mais documentez la date).
J’ai vu des cas où le site semblait “à peu près correct” une heure après des suppressions manuelles, puis réapparaissait le lendemain. La cause n’était pas toujours le malware original. Parfois, c’était une étape de restauration mal identifiée, ou un fichier réinjecté pendant la récupération. Avoir une copie vous donne une stratégie de retour, pas juste une idée.
Diagnostic rapide: quelles zones vérifier en premier
Quand il s’agit de supprimer malware WordPress, les emplacements à inspecter en premier sont souvent les mêmes. Pas parce que “tout le monde attaque pareil”, mais parce que ce sont les zones qui offrent le plus de contrôle aux attaquants.
Sur la partie fichiers, cherchez les modifications dans les emplacements qui chargent du code à l’amorçage. Les injections se logent fréquemment dans des fichiers PHP utilisés tôt dans le cycle de WordPress, ou dans des fichiers “cachés” ajoutés à des répertoires inattendus. Sur la partie base de données, regardez ce qui a été ajouté en base sans raison: options modifiées, cron jobs “suspects”, utilisateurs créés récemment, entrées qui contiennent des motifs scripts ou des URLs anormales.
Le diagnostic ne vise pas à tout trouver d’un coup. Il sert à répondre à trois questions concrètes:
Le malware est-il principalement dans des fichiers, dans la base, ou dans les deux? Y a-t-il une persistance (un mécanisme qui réinjecte) ou une simple injection statique? Est-ce que le site a déjà “exporté” l’infection ailleurs (par exemple via un plugin ou un contenu généré)?Si vous détectez un utilisateur nouvellement créé avec un rôle élevé, une clé API inattendue, ou un plugin ajouté hors calendrier, ça oriente la suite. Si vous voyez des scripts dans plusieurs fichiers racine et aussi des entrées en base, la restauration complète devient plus rationnelle que le bricolage.
Choisir la stratégie: restauration complète ou nettoyage ciblé
Dans la pratique, deux stratégies dominent.
Restauration complète (souvent la plus sûre)
Si vous avez une sauvegarde fiable, et que vous pouvez revenir à un état antérieur sans “mélange”, la restauration est la voie la plus propre. Elle limite le risque de laisser un reste de code de persistance. Le revers, c’est la perte de données entre la sauvegarde et maintenant: nouveaux contenus, commentaires, commandes, réglages.
Une fois restauré, il faut ensuite vérifier que la réinfection ne survient pas au premier chargement. Si le malware revient immédiatement, c’est un signe que la compromission n’est pas seulement dans WordPress, mais aussi dans l’environnement: comptes FTP, accès shell, scripts dans le serveur, ou plugin fraîchement réinstallé via un mécanisme externe.
Nettoyage ciblé (quand la restauration est incomplète)
Le nettoyage ciblé est utile si vous n’avez pas de sauvegarde fiable, ou si vous devez minimiser la perte de contenu. Il demande en revanche une discipline stricte: comparer les fichiers avec un WordPress “connu”, vérifier l’intégrité des thèmes et plugins, inspecter la base, puis surveiller.
Sur un site de client, j’ai déjà vu un nettoyage “ciblé” échouer parce qu’un petit fichier dans un répertoire temporaire avait été oublié. Le script principal avait été supprimé, mais la persistance venait d’un endroit “secondaire”. Le site n’était pas complètement réinfecté, juste suffisamment pour que les redirections réapparaissent à des moments précis.
En clair: restauration ou nettoyage, choisissez la méthode qui réduit le risque de résidu, pas la méthode qui donne le sentiment de gagner du temps.
Étape pratique: nettoyer sans casser
Voici comment je procède quand je dois supprimer malware WordPress avec un niveau de sécurité raisonnable, tout en évitant de faire disparaître des fonctionnalités légitimes.
1) Couper l’accès et limiter l’exposition
Avant de commencer, verrouillez l’accès au site pour éviter que des visiteurs continuent à alimenter l’infection ou que les attaquants gardent un levier. Concrètement, ça peut passer par une mise en maintenance, ou des règles de filtrage sur l’accès admin tant que la vérification n’est pas terminée. L’objectif est de réduire les variables.
2) Désactiver les plugins, surtout ceux qui ont changé
Si le back-office répond encore, désactivez tous les plugins, puis réactivez progressivement ceux dont vous êtes certain. Le malware se propage parfois via un plugin compromis, et la restauration du core WordPress ne suffit pas si un plugin installé depuis l’infection reste en place.
Si vous n’avez pas accès au back-office, la logique reste identique, mais vous le faites côté fichiers: désactivez en renommant le répertoire plugin ou via les entrées en base, avec prudence.
3) Remplacer les fichiers WordPress “core”
À chaque fois que c’est possible, je recommande de restaurer le core WordPress depuis une source officielle, ou au minimum de vérifier l’intégrité des fichiers. Le point délicat, c’est de ne pas confondre core et personnalisations. Si vous avez modifié des fichiers core, il faudra reconstituer vos modifications. Mais souvent, ce sont des modifications qui auraient dû vivre dans un thème enfant ou via hooks, pas dans le core.
Dans un cas récent, le malware était dans un fichier core PHP modifié. Le core a été remplacé, le symptôme a disparu. Deux jours plus tard, le site a recommencé à rediriger. Pourquoi? Le plugin compromis, lui, “recréait” l’injection via un mécanisme en base. Cela montre que “remplacer le core” n’est pas une fin en soi, c’est une base.
4) Inspecter les thèmes et fichiers custom
Les thèmes custom et fichiers personnalisés sont un autre point d’attention. Cherchez les modifications récentes, les ajouts bizarres dans des fichiers qui ne devraient pas contenir des redirections, des appels externes ou des fonctions obscures. Les motifs typiques de malware sont parfois grossiers (concaténations d’URL, base64 de code exécuté, appels à des fichiers distants), mais pas toujours.
Important: ne supprimez pas au hasard. Avant de retirer un morceau de code, comprenez ce qu’il fait et si cela correspond à une fonctionnalité existante. Si vous avez un thème enfant, vérifiez si l’injection est dans le thème parent, dans l’enfant, ou dans un “include” chargé au démarrage.
5) Nettoyer la base de données avec méthode
La base peut contenir des éléments incriminants: options modifiées, cron jobs malicieuses, utilisateurs créés, ou contenus injectés. Pour la partie “supprimer malware WordPress”, le point le plus utile n’est pas seulement de supprimer des entrées, c’est d’identifier la source de la persistance.
Par exemple, un attaquant peut modifier une option qui déclenche un chargement de contenu sur toutes les pages, ou créer un cron https://gardewp.fr/nettoyage-malware-wordpress/ job qui réinjecte périodiquement. Si vous supprimez seulement l’effet visible, le cron peut recréer le problème.
Je garde toujours une logique simple: je fais des changements minimaux et je teste. Après chaque modification majeure, je vérifie le chargement du site et je contrôle les logs serveur si possible.
Validation: comment savoir que c’est vraiment parti
Le moment où on “croie que c’est propre” est souvent celui où on doit le plus se méfier. La validation doit être à la fois technique et observationnelle.
Techniquement, vérifiez l’intégrité des fichiers, l’absence de redirections inattendues et la cohérence des plugins et thèmes actifs. Observationnellement, testez plusieurs scénarios: navigation anonyme, navigation avec cookies, pages articles, pages statiques, mobile et desktop. Les redirections malicieuses ciblent parfois des user agents ou des conditions précises.
Sur un site infecté, j’ai déjà vu une redirection uniquement déclenchée sur des pages d’archive et uniquement après un certain temps de chargement. Si on teste une seule page et qu’on recharge une fois, on peut conclure trop tôt.
Si vous avez accès à des outils comme les historiques d’exploration, inspectez aussi les signaux externes. Un navigateur qui bloque, ou des moteurs qui signalent des pages infectées, donnent un niveau d’alerte. Attention, le signal peut mettre du temps à disparaître même après nettoyage. Ce délai dépend des systèmes de détection.
Durcir WordPress après le nettoyage: empêcher le retour
Nettoyer est nécessaire, mais ce qui protège vraiment, c’est le durcissement. Beaucoup de sites sont “réparés” une fois, puis réinfectés à la prochaine opportunité, parce que le même manque de contrôle reste en place.
Le durcissement doit agir sur trois axes: l’accès, les mises à jour, et la surface d’exécution.
Accès et identifiants
Changez tous les mots de passe liés au site après l’incident, pas seulement celui du compte administrateur. L’approche prudente consiste à:
- changer les mots de passe WordPress, changer aussi ceux des accès hébergement (FTP/SFTP, panneau de contrôle), vérifier les sessions et les jetons si votre hébergeur le permet.
Si vous travaillez en équipe, forcez une rotation des identifiants pour éviter que quelqu’un réutilise un ancien mot de passe resté en mémoire dans un gestionnaire.
Si l’accès distant est possible via shell, l’exemple le plus simple est l’authentification forte, même si elle est contraignante. Sur les incidents que j’ai vus, c’est rarement “le malware” qui revient. C’est un accès qui n’a pas été neutralisé, donc l’attaque a continué sous une autre forme.
Mises à jour et hygiène des plugins
Les plugins et thèmes abandonnés sont une source récurrente de vulnérabilités. Après un incident, je fais un audit rapide de ce qui est réellement utilisé. Les plugins inutiles deviennent des responsabilités.
La question à se poser n’est pas “est-ce que ça marchait hier”, c’est “est-ce que ça vaut le risque, maintenant qu’on a un historique d’infection?”. Désinstaller proprement les extensions qui ne servent pas, ou celles dont vous ne maîtrisez pas l’origine, est souvent le meilleur investissement.
Filtrage et limitation des vecteurs
Sans entrer dans des configurations trop spécifiques à votre hébergeur, l’idée consiste à réduire la surface:
- limiter l’accès à /wp-admin si possible, surveiller les tentatives de connexion, empêcher l’écriture de fichiers non nécessaire.
Beaucoup de malwares ont besoin de pouvoir écrire quelque part. Si votre environnement réduit drastiquement la possibilité d’écriture non autorisée, vous changez l’économie de l’attaque.
Check-list courte après un incident (pour éviter les oublis)
Cette mini check-list n’est pas un rituel, c’est une protection contre les erreurs classiques. Elle tient en peu d’éléments, mais elle couvre le cœur des “ça revient”.
- Restaurez le core WordPress et vérifiez les thèmes et plugins actifs (ou désactivez, puis réactivez progressivement). Supprimez les utilisateurs non reconnus, vérifiez les rôles et contrôlez les comptes admin. Changez les mots de passe WordPress et ceux de l’hébergement, puis révoquez les sessions si possible. Inspectez la base pour les options et éléments qui déclenchent des injections ou des cron jobs. Surveillez pendant 24 à 72 heures avec des tests sur plusieurs pages et plusieurs conditions (anonyme, mobile, cookies).
Si vous n’avez pas de sauvegarde: quoi faire en dernier recours
Il y a des situations où la sauvegarde n’existe pas ou est inutilisable, par exemple lorsque le site a été compromis avant même que vous ayez mis en place une politique de sauvegarde. Là, le nettoyage devient un travail d’enquête.
Le plus important est de ne pas partir du principe que “tout le monde est touché pareil”. En pratique, vous pouvez retrouver un noyau du malware dans quelques fichiers, mais la persistance peut être ailleurs. Sans sauvegarde, je recommande de:
- identifier toutes les modifications dans les fichiers PHP chargés au démarrage, désactiver tous les plugins sauf ceux indispensables et tester, comparer les répertoires à une installation WordPress saine (même version) pour repérer les écarts.
Le piège ici, c’est de vouloir tout supprimer pour “être sûr”. Une suppression agressive peut casser le site, masquer des erreurs, et vous faire perdre du temps sur des diagnostics qui auraient pu être évités avec une approche de comparaison.
Les erreurs fréquentes que je rencontre en intervention
Quand on me décrit le problème, il y a parfois une “histoire” qui revient souvent. Voici les plus coûteuses, celles qui font perdre des jours.
Une erreur classique consiste à supprimer seulement ce qui est visible. Par exemple, si une redirection vers une page de spam est repérée, on retire la redirection, mais le mécanisme qui injectait cette redirection reste en place, souvent sous forme de cron, de fichier secondaire ou de contenu en base.
Une autre erreur, c’est de remettre en ligne trop vite, sans surveillance. Sur certains malwares, le payload se déclenche au bout d’une période, ou seulement après un certain nombre de requêtes. Vous pouvez avoir l’impression que “c’est bon” pendant quelques heures, puis un retour du symptôme dans la nuit.
Enfin, la confusion entre “restauration” et “restauration propre” est fréquente. On restaure bien un dossier, mais on garde la base de données infectée, ou l’inverse. Résultat, le site se charge à nouveau, mais l’infection réapparaît. Le bon sens ici est simple: restaurer le couple cohérent, fichiers et base, ou bien nettoyer les deux avec la même rigueur.
Durcissement plus avancé, quand l’incident a été sérieux
Si l’infection était https://gardewp.fr/ profonde, si vous avez vu des fichiers dispersés, si le site a redirigé massivement, ou si vous suspectez une compromission plus large, un durcissement plus structuré devient utile.
Sans entrer dans une liste (pour rester concret et pratico-pratique), l’idée est d’institutionnaliser:
- un cycle de mises à jour, une validation d’intégrité des fichiers, une surveillance d’événements (changements de plugins, créations d’utilisateurs, modifications de fichiers sensibles), et un contrôle des droits, en donnant le minimum de privilèges aux comptes qui ne doivent pas écrire partout.
Sur beaucoup de sites, le problème n’est pas “WordPress est dangereux”. C’est que le site a été géré comme un projet figé, sans routine de maintenance. Un incident vous rappelle que c’est un système vivant.
Après la réouverture: surveillance et nettoyage de l’écosystème
Une fois le site remis en ligne, gardez le tempo. Les 24 à 72 heures après un incident sont souvent celles où vous voyez les “derniers signes”.
Je recommande de vérifier:
- que les pages clé n’ont pas changé de comportement, que les plugins réactivés n’ont pas réinstallé quelque chose, que de nouveaux utilisateurs n’apparaissent pas, que les redirections suspectes ne réapparaissent pas sur des pages différentes.
Si vous avez une procédure de sauvegarde, testez aussi la restauration future. Une sauvegarde qui existe mais qui ne se restaure pas correctement n’est pas une vraie assurance.
Et si un comportement étrange persiste, considérez la possibilité que le problème ne soit pas seulement dans WordPress. Un hébergeur compromis, un compte FTP ou un environnement mal sécurisé peut réécrire des fichiers. Dans ce cas, la suppression malware WordPress doit s’accompagner d’un contrôle côté hébergement, sinon vous allez courir après des symptômes.
Un mot sur la restauration “à la source” du problème
Souvent, la question implicite est: “comment éviter que ça se reproduise exactement de la même façon?”. La réponse repose sur la cause racine, pas sur la suppression du symptôme.
Si l’origine est un plugin vulnérable, la résolution passe par la désinstallation ou la mise à jour contrôlée, et par la réduction de privilèges. Si l’origine est un mot de passe compromis, la résolution passe par la rotation et une authentification forte. Si l’origine est un problème d’intégrité fichiers, la résolution passe par des remplacements contrôlés, des validations, et une surveillance.
C’est ce qui transforme une opération de suppression en démarche de sécurité. Et c’est aussi ce qui rend le site plus serein à long terme.
Si vous devez agir maintenant, sans tout relire
Si vous êtes en plein incident, vous n’avez pas le temps de tout analyser au millimètre tout de suite. Une approche pragmatique consiste à: mettre en maintenance, sauvegarder fichiers et base, restaurer le core, désactiver les plugins, inspecter thèmes custom et base, puis valider par tests multi-pages et surveillance sur une courte fenêtre. Le but est de couper les voies de persistance en premier, et de résoudre le reste ensuite.
Supprimer malware WordPress, c’est autant une affaire de méthode que de technique. La différence entre un nettoyage qui tient et un nettoyage “qui revient” se joue presque toujours dans la qualité de la restauration, la cohérence fichiers et base, et la capacité à prévenir la réinfection pendant la remise en ligne.