Un site WordPress peut basculer du “tout va bien” au “vérifiez votre connexion” en quelques heures. Le moment le plus stressant n’est pas toujours l’infection en elle même, c’est l’alerte qui apparaît dans Google, ou pire, le changement de comportement côté visiteurs. Pages qui ne chargent plus, redirections vers des domaines sans rapport, formulaires qui se comportent bizarrement, ou un message de type “Site dangereux” dans les résultats.
Quand Google affiche une alerte, vous n’avez pas le droit à l’improvisation. Vous devez à la fois contenir le risque, comprendre ce qui s’est passé, puis nettoyer proprement, sinon vous risquez de “supprimer malware WordPress” en surface tout en laissant assez de résidus pour que ça revienne.
Je vous propose une démarche réaliste, celle que j’ai vue fonctionner quand on doit arrêter un incident, même avec un hébergement mutualisé, même quand on n’a pas une sauvegarde parfaite, et même quand le code a déjà été modifié.
D’abord, respirer et comprendre ce que Google vous dit
Les alertes Google ne sont pas identiques selon le type de problème. Parfois c’est un blocage lié à des pages compromises qui distribuent des logiciels malveillants. Parfois, c’est de la redirection ou de l’injection de scripts qui dégradent l’expérience, ou déclenchent des signaux côté sécurité.
Le point commun, c’est que Google ne “punit” pas un site parce qu’il est moins sécurisé. Il signale un comportement observé ou des indicateurs qui collent à une compromission. Cela signifie aussi que le nettoyage doit être plus solide qu’un simple “désinstaller le plugin suspect du moment”.
Je garde une règle simple quand je traite ce genre d’incident: tant que je ne sais pas exactement ce qui a été modifié, je considère que le site distribue du contenu malveillant ou qu’il a été utilisé comme plateforme d’attaque. Donc je limite l’exposition, puis je fais un tri méthodique.
Contenir tout de suite: éviter que l’infection continue de servir
Avant de toucher au code, l’objectif est de réduire l’impact. Si l’attaquant continue à injecter, vos visiteurs restent exposés et Google peut continuer à nourrir l’alerte.
Selon la configuration de votre site, vous avez plusieurs options. La plus “propre” consiste à isoler le site de façon à empêcher l’accès public, tout en gardant la possibilité d’analyser et de corriger.
Dans la pratique, j’ai souvent vu ces scénarios:
- Le site est accessible, mais les pages sont compromises. Dans ce cas, isoler le site est généralement préférable à “nettoyer vite et espérer”. Le site n’est accessible qu’avec une partie des visiteurs (par exemple selon l’IP ou via du contenu chargé côté navigateur). Ici, il est encore plus important de couper la source, parce que vous ne verrez pas toujours le problème de votre poste. Le site n’affiche plus rien, ou affiche une page d’alerte, mais des traces existent encore côté serveur. Même si ça semble “calmé”, ça ne veut pas dire que le malware WordPress a disparu.
Une action fréquente et efficace consiste à activer un mode maintenance temporaire et strict. L’idée n’est pas d’en faire un “masque” cosmétique, mais de stopper le flux public pendant que vous travaillez, idéalement sur une copie analysable.
Une courte checklist de contrôle (avant toute suppression)
Pour éviter de “casser” une preuve ou d’aggraver l’infection, je commence presque toujours par vérifier quelques points. C’est rapide, et ça évite des erreurs bêtes.
Désactivez temporairement le trafic public en mode maintenance ou sur un domaine miroir, pour limiter l’exposition. Notez la date et l’heure approximative de l’alerte Google, puis les symptômes observés (redirection, scripts, erreurs). Vérifiez si le serveur a d’autres domaines sur le même hébergement, pour comprendre si vous êtes isolé ou non. Copiez une sauvegarde complète du dossier WordPress et des fichiers de configuration concernés avant toute modification. Collectez les logs disponibles (accès web, erreurs, tâches planifiées, tentatives de connexion).Cette étape semble “administrative”, mais elle change tout: vous gagnez du temps après, parce que vous pouvez comparer avant et après, et vous évitez le scénario où quelqu’un efface des traces juste pour “aller plus vite”.
Ne pas confondre “plugin supprimé” et “infection éradiquée”
Quand on lit des tutoriels rapides, on voit souvent une injonction qui paraît logique: “désinstallez le plugin compromis”, “changez le mot de passe”, “réinstallez WordPress”. Sur le papier, ça marche parfois.
Dans la vraie vie, supprimer un plugin ne suffit pas toujours pour deux raisons.
D’abord, le malware WordPress peut être dans les fichiers du thème, dans le fichier d’un mu-plugin, dans des fichiers inclus via un include discret, ou dans une modification de la base de données. Un plugin peut être juste le vecteur initial, pas la source finale.
Ensuite, beaucoup d’incidents laissent derrière eux des mécanismes de persistance. L’exemple le plus courant, c’est un script qui s’exécute à chaque chargement, et qui se sert d’un petit crochet pour injecter un code malveillant. Tant que ce crochet reste, vous pouvez désinstaller “tout ce qui semble suspect” et retrouver le même comportement une semaine plus tard.
Mon approche est simple: je traite l’infection comme un ensemble de modifications. Je cherche ce qui a été modifié, puis je supprime ce qui ne doit pas être là. La suppression se fait après compréhension, pas uniquement sur intuition.
Ouvrir le boîtier: ce que j’inspecte sur un WordPress compromis
Sans sortir dans des cours théoriques, voici les zones où j’ai le plus souvent trouvé des altérations lors de compromis WordPress.
Fichiers “basiques” qui ne devraient jamais changer sans raison
Je commence par regarder les fichiers qui ont un impact immédiat sur l’exécution.
- Les fichiers au niveau racine de WordPress, notamment ceux liés au démarrage (et les fichiers d’initialisation). Le contenu du thème actif et des thèmes enfants, surtout les templates et les fichiers de fonctions. Les fichiers “cachés” ou inhabituels, y compris ceux avec des noms qui ne ressemblent pas à des composants WordPress standard. Les mu-plugins et les dossiers de plugins qui contiennent autre chose que du code de plugin normal.
Si vous avez accès au serveur, repérer des fichiers nouveaux ou modifiés récemment est souvent plus efficace que de relire tout le site à la main. Une différence entre “date de modification” avant incident et après incident donne des pistes concrètes.
La base de données: injections, options et utilisateurs
Quand l’attaque est plus élaborée, le site devient une cible dynamique. La base de données peut contenir:
- des options WordPress modifiées, des scripts injectés via des champs stockés, des utilisateurs ajoutés ou des rôles élargis, des changements dans des tables qui servent à l’affichage.
Dans les cas où Google affiche une alerte sévère, je m’attends souvent à trouver au moins une trace dans la base, même si une partie du code est aussi présente dans les fichiers.
Le piège ici, c’est la “nettoyage partiel”: restaurer certains fichiers mais laisser une option qui injecte encore du contenu. Le site peut alors sembler “revenir” pendant quelques minutes, puis rebasculer selon une logique d’exécution.
Les chemins d’accès et le comportement client
Parfois le code injecté n’altère pas une page visible, il charge un script côté navigateur, ou redirige uniquement dans certains contextes. C’est pour ça que je recommande souvent de tester plusieurs URLs, avec et sans paramètres, et idéalement depuis un navigateur “propre” (sans extension, ou en navigation privée).
Si vous voyez des redirections vers des domaines non liés, notez les cibles. Cette information peut vous aider à identifier quel morceau de code déclenche le comportement.
Nettoyer: la stratégie qui évite les retours d’infection
Quand il faut “supprimer malware WordPress” sans repasser dessus une seconde fois, je privilégie une méthode en deux temps: restauration fiable, puis vérifications de cohérence.
Restaurer proprement plutôt que “réparer au stylo”
Si vous avez des sauvegardes antérieures fiables, la restauration est souvent le chemin le plus court vers la stabilité. L’objectif n’est pas de “récupérer le site en état de marche”, mais de le remettre à un état connu et sain.
La restauration totale (fichiers et base) est la plus robuste, mais elle dépend de votre capacité à revenir à un instant avant l’infection. Si vos sauvegardes sont trop vieilles, vous risquez de réintroduire le problème ou de perdre des données.
Quand vous restaurez, je vous conseille de:
- valider l’intégrité avant de remettre en production, tester les pages critiques, vérifier les comptes utilisateurs et les rôles, contrôler les fichiers récemment modifiés.
Dans certains environnements, vous pouvez aussi restaurer seulement les fichiers du WordPress “core” et les thèmes depuis une version connue. Mais si la base a été touchée, le simple remplacement des fichiers ne suffit pas.
Rechercher l’inconnu: les fichiers et injections “non WordPress”
Après restauration ou correction, je fais un balayage de ce qui ne ressemble pas au contenu normal d’un site WordPress.
Le point important, c’est de ne pas se contenter d’un “scan antivirus” général. Les malwares WordPress sont souvent des altérations ciblées, pas un virus qui se voit au premier coup d’œil.
Je cherche notamment:
- des lignes de code ajoutées dans des fichiers qui ne contiennent pas habituellement ce type de logique, des includes ou des require inhabituels, des chargements de script depuis des domaines externes qui n’ont aucune raison d’être là, des fonctions qui modifient le comportement de WordPress à l’exécution.
Le jugement compte. Par exemple, un thème peut contenir du code d’optimisation ou un gestionnaire de cookies qui charge des scripts externes. La différence se fait souvent sur le contexte: pourquoi ce script est appelé, comment il est déclenché, et s’il correspond à votre configuration légitime.
Sécuriser immédiatement ce que l’attaque a probablement utilisé
Nettoyer le site sans renforcer l’accès, c’est comme remplacer une serrure sans changer la porte. L’attaquant revient dès qu’il a une faille.
Dans WordPress, les points d’accès classiques ne manquent pas. Les attaques récentes s’appuient très souvent sur un compromis de compte (mot de passe faible, réutilisation, brute force), sur une faille de plugin ou de thème, ou sur une mauvaise configuration des fichiers.
Je recommande de traiter dans l’ordre: comptes, plugins et mises à jour, puis serveur.
Les actions qui ont du sens, sans se perdre
Changer tous les mots de passe est utile, mais faites-le avec méthode. Si votre hébergeur permet un accès administrateur, vous devez aussi penser aux accès au serveur et à la base de données.
Ensuite, côté WordPress:
- mettez à jour le core si ce n’est pas fait, supprimez les plugins et thèmes inutiles, vérifiez que les plugins restants ont des sources fiables et sont maintenus.
Si vous trouvez un plugin ou un thème “installé juste avant l’incident”, il mérite une attention immédiate, même s’il semble inactif. Certains malwares modifient une fonctionnalité à bas bruit, puis se servent de la logique d’un hook.
Quand la purge est faite: que vérifier avant de réactiver l’accès public
Réactiver le site “trop tôt” est un classique. Le nettoyage peut être complet, mais vous pouvez avoir raté un point d’injection, ou l’incident peut s’être propagé via d’autres composants.
Je procède avec des tests concrets. Pas besoin d’être parfait, mais il faut être cohérent.
Voici les vérifications que je fais en priorité:
- test sur plusieurs pages publiques, y compris les pages qui chargent des scripts (accueil, articles, pages avec formulaires), test de navigation dans une fenêtre privée, vérification des redirections éventuelles, contrôle des URLs et des ressources externes qui se chargent, vérification des comptes WordPress (utilisateurs, rôles, dernière connexion).
Pour les sites qui dépendent fortement du SEO, testez aussi des pages qui reçoivent historiquement du trafic. Certains malwares n’attaquent pas toutes les pages, ils ciblent un type de template.
Faire évoluer la relation avec Google: soumission, patience et preuves
Une fois que vous avez effectué le nettoyage, l’étape suivante consiste à communiquer avec Google pour qu’il reanalyse et lève l’alerte si tout est redevenu normal. En général, cela passe par les outils Google Search Console, là où vous avez vu l’alerte.
Le point que j’ai constaté dans les incidents réels, c’est que vous pouvez avoir tout nettoyé et pourtant attendre. Les délais varient selon la fréquence de crawl et la sévérité du signal. Si Google a identifié une injection persistante, il peut falloir plusieurs cycles.
Je conseille de garder des traces internes: date de restauration, liste des éléments supprimés ou remplacés, et, si possible, une note de ce que vous avez observé. Ce n’est pas seulement pour vous rassurer. Si vous devez rouvrir un dossier, vous gagnerez du temps.
Petite check-list de fin de cycle (avant “retour à la normale”)
Confirmer que les fichiers et dossiers suspects ont été supprimés ou remplacés par des versions saines. Contrôler la base de données pour les comptes, rôles, options et champs modifiés. Vérifier que le site ne déclenche plus de redirections ni de scripts non attendus. Réactiver l’accès public seulement après tests en navigation privée. Soumettre une demande de réexamen dans Search Console après stabilisation.Cette liste reste volontairement courte, parce que votre vraie preuve se trouve dans le comportement du site et dans l’absence de signaux anormaux.
Les cas fréquents qui compliquent la vie (et comment les gérer)
1) Pas de sauvegarde utilisable
Quand il n’y a pas de sauvegarde récente, vous devez reconstruire de manière prudente. Vous pouvez repartir d’une installation propre de WordPress, replacer thèmes et plugins connus depuis des sources fiables, puis réimporter uniquement les contenus nécessaires.
Ce travail prend du temps, et il faut arbitrer. Je le dis sans dramatiser, mais avec honnêteté: refaire “proprement” un site sans point de retour fiable est souvent plus long que restaurer. En échange, c’est ce qui réduit le risque d’un retour de l’infection.
2) Plusieurs sites sur le même hébergement
Si vous hébergez plusieurs WordPress sur un même serveur, l’incident peut être contagieux. L’attaquant peut viser un seul site mais utiliser des méthodes qui laissent des traces ailleurs. Même si votre site “principal” est nettoyé, un autre pourrait reposer une porte.
Ici, la prudence consiste à vérifier aussi les autres installations, ou au moins les dossiers et comptes dont l’activité est liée au même utilisateur système.
3) L’alerte Google a l’air ancienne ou “floue”
Parfois, l’alerte remonte à une date, mais vous observez une autre anomalie. Dans ces situations, je traite l’infection comme un probable cumul. Vous pouvez avoir un malware partiellement neutralisé, mais pas totalement, ou un nouvel incident après un premier nettoyage.
Le bon réflexe est de comparer l’état actuel avec ce qui était en place avant l’incident, via sauvegardes, logs, et historique de déploiement.
4) Plugin “légitime” mais détourné
Le cas qui piège le plus, c’est quand vous trouvez un plugin connu, parfois même installé par votre agence, mais qui a été modifié ou remplacé par une version modifiée.
Les signes sont parfois discrets: signature différente, taille de fichiers inhabituelle, absence de fichiers attendus. Si vous n’êtes pas sûr, comparez avec une version officielle obtenue depuis la source de confiance, et regardez les différences.
Pourquoi l’infection revient (et comment l’empêcher vraiment)
Après un nettoyage, le retour n’est pas rare si les causes racines ne sont pas éliminées. Dans ce type d’incident, les causes racines se résument souvent à trois catégories: accès, composants, et environnement.
Accès: des mots de passe trop faibles, ou des comptes qui restent actifs alors qu’ils auraient dû être renforcés ou supprimés.
Composants: un plugin non maintenu, ou une mise à jour repoussée “parce que ça ne pose pas de problème”.
Environnement: une mauvaise configuration serveur, des droits d’écriture trop larges, ou des outils d’upload mal sécurisés.
Je ne cherche pas à empiler des sécurités au hasard. Je préfère des mesures qui réduisent la surface d’attaque sans rendre la gestion du site ingérable. Par exemple, la combinaison d’un renouvellement d’accès, de mises à jour régulières, et d’une supervision minimale des changements de fichiers fait déjà une grosse différence.
Un exemple concret: quand on a cru que c’était fini
Je repense à un cas où l’équipe avait désinstallé un plugin “suspect” après une alerte, puis avait remis le site en ligne. Le trafic est revenu vite. Trop vite.
Les symptômes n’étaient pas constants. Un visiteur sur deux voyait un comportement normal, l’autre voyait une redirection après chargement de scripts. De plus, les tests en navigation privée n’étaient pas systématiques, et une partie des pages ne provoquait pas l’effet.
Le vrai problème a été trouvé après comparaison des fichiers, et non https://gardewp.fr/nettoyage-malware-wordpress/ après “suppression du plugin du moment”. Il y avait un fragment injecté dans un fichier de thème, déclenché par un motif précis. Une fois le bon point retiré, l’alerte a commencé à retomber, mais uniquement après plusieurs jours de crawl.
Ce genre d’histoire explique pourquoi je recommande des tests réalistes et une vérification de l’ensemble, pas juste un coup de gomme sur un composant.
Conclusion implicite: l’objectif est un site stable, pas juste “une alerte levée”
Quand Google affiche une alerte, la tentation est de courir vers un bouton “réparer” et de réactiver au plus vite. Pourtant, l’objectif n’est pas uniquement d’effacer un message. L’objectif est de rendre votre WordPress à nouveau sûr, stable, et cohérent avec ce que vous déployez réellement.
Si vous devez retenir une idée, ce serait celle-ci: supprimer malware WordPress, ce n’est pas “effacer ce que vous voyez”, c’est éliminer les modifications qui permettent à l’attaque de recommencer.
Si vous êtes en train de traverser ce genre d’épisode, je peux aussi vous aider à cadrer un plan d’action selon votre situation. Dites-moi simplement ce que vous avez comme accès (FTP ou console, Search Console, sauvegardes disponibles, date d’installation de plugins récents), et si l’alerte mentionne clairement un type de menace ou un symptôme (redirection, contenu malveillant, logiciel malveillant, etc.).