Quand un site WordPress commence à faire n’importe quoi, la tentation est grande de “scanner et attendre”. Parfois ça marche. Souvent, ça donne un faux sentiment de sécurité, parce que le malware a déjà eu le temps d’installer une porte dérobée, de modifier la base de données ou de persister via des mécanismes moins visibles qu’un simple fichier louche.
J’ai déjà vu des cas où un site “semblait propre” après un scan, puis, deux heures plus tard, des requêtes vers des domaines inconnus réapparaissaient. Dans d’autres, le code malveillant était parti, mais la configuration restait compromise, ce qui faisait que les mêmes symptômes revenaient au prochain scan, comme une maladie en rémission qui n’est pas guérie. L’approche qui tient dans le temps, c’est une combinaison, pas un outil magique.
Ce guide parle de suppression de malware WordPress, avec des outils et scanners recommandés, mais surtout avec la logique derrière leur utilisation. L’objectif n’est pas seulement de trouver, mais de confirmer, d’assainir, puis de vérifier.
Comprendre ce que vous cherchez vraiment
“Supprimer malware WordPress” recouvre plusieurs réalités. Un script de redirection injecté dans un thème ou un plugin est différent d’un code qui s’exécute au chargement d’une page spécifique. Un fichier PHP ajouté dans un dossier inattendu n’a pas le même impact qu’une modification d’options en base de données, par exemple un changement de paramètres d’affichage, ou la création d’un compte admin caché.
Les malwares WordPress tombent souvent dans des schémas connus :
- infection de fichiers (thèmes, plugins, uploads, fichiers PHP “de trop”) compromission de la base (options, tables modifiées, contenu injecté) mécanismes de persistance (cron, webhooks, tâches planifiées, scripts qui reviennent) exfiltration (tentatives d’appels vers des serveurs externes, chargement de ressources distantes) altération du navigateur ou de la publication (scripts injectés dans le HTML, changements dans les pages, aggrégations de spam)
La conséquence pratique, c’est que vous ne cherchez pas “un virus”, vous cherchez une chaîne. Si vous supprimez le dernier maillon visible sans traiter la cause, la chaîne repart.
Avant de scanner : sécuriser pour éviter d’aggraver
Scanner un site déjà compromis n’est pas forcément dangereux, mais il faut éviter deux pièges classiques : déclencher encore plus de trafic vers les serveurs de commande et contrôler les comptes.
Avant toute action, je recommande systématiquement de travailler dans un cadre maîtrisé.
D’abord, sauvegarde. Pas “un copier-coller rapide”, une sauvegarde exploitable, idéalement avec les fichiers et la base. L’idée n’est pas de tout reconstruire, c’est d’avoir une issue de secours si vous devez revenir en arrière.
Ensuite, vérifiez l’accès. Si un compte admin a été créé ou si un utilisateur a des droits anormaux, vous voulez limiter les dégâts avant de jouer au dentiste sur le code. Changez les mots de passe des comptes à privilèges, déconnectez les sessions si votre hébergeur le permet, et passez en MFA (authentification à deux facteurs) si vous pouvez le faire rapidement.
Enfin, coupez le bruit. Si vous voyez une hausse brutale de requêtes, ou si le site est utilisé comme pivot pour attaquer ailleurs, la priorité devient de stabiliser. Parfois, mettre le site en maintenance et restreindre temporairement l’accès pendant les vérifications fait gagner des heures.
Les meilleurs scanners ne remplacent pas une méthode
Il existe plusieurs catégories d’outils. Certains sont des plugins WordPress, d’autres des scanners côté serveur, d’autres encore des services externes. Chacun a ses limites.
Un scanner “sympa” peut détecter des signatures connues dans des fichiers, ou des patterns d’injection dans le HTML, mais il peut rater une modification en base, ou ne pas voir un code empaqueté, obfusqué, ou généré dynamiquement.
À l’inverse, un diagnostic basé sur les comportements (connexion sortante, logs, anomalies de requêtes) peut repérer un malware qui ne correspond pas à une signature connue. Mais il ne suffit pas toujours pour supprimer proprement.
La bonne approche consiste souvent à croiser au moins deux angles : intégrité des fichiers et analyse applicative.
Outils et scanners recommandés pour WordPress
Plugins de sécurité et scanners intégrés
Les plugins de type “sécurité” peuvent être utiles pour obtenir une première cartographie. Beaucoup proposent des scans de fichiers, des vérifications de réputation, et parfois un nettoyage assisté.
Dans la pratique, je les considère comme un point de départ, pas comme une preuve de guérison. Un plugin peut signaler des changements, mais le “nettoyage” peut être partiel. Et surtout, si le malware a modifié la base, il faut souvent aller plus loin.
Parmi les options courantes que les administrateurs utilisent pour scanner, on retrouve des solutions populaires orientées :
- analyse de fichiers WordPress et comparaison à l’état attendu recherche de code suspect dans les thèmes et plugins surveillance de l’intégrité et nettoyage guidé logs d’activité et détection d’accès
Je ne vais pas vous vendre une marque unique, parce que l’outil pertinent dépend de votre contexte : taille du site, thème et plugins installés, niveau de personnalisation, et contraintes d’hébergement.
Ce que vous devez retenir, c’est d’exiger des résultats actionnables. Un bon rapport de scan vous montre au minimum où regarder, quel fichier est suspect, et ce qui a été modifié.
Scanners côté serveur et vérification de l’intégrité
Quand vous voulez une vraie solidité, le côté serveur et l’intégrité des fichiers comptent énormément. La raison est simple : un plugin qui scanne depuis WordPress peut être aveugle si le malware intercepte ou modifie ce qui est renvoyé.
Sur un hébergement classique, vous pouvez comparer vos fichiers à des distributions officielles pour détecter des modifications. Si votre hébergeur offre un outil d’intégrité ou des snapshots, c’est encore mieux.
Même sans outil “officiel”, un principe fonctionne : identifier quels fichiers doivent absolument exister (WordPress core, thèmes, plugins que vous utilisez) et repérer les écarts. Les dossiers inattendus dans wp-content, des fichiers PHP dans wp-content/uploads, ou des scripts à l’apparence triviale sont souvent des signaux.
Là encore, ce n’est pas seulement “trouver”, c’est comprendre. Par exemple, un plugin légitime peut modifier un fichier pour générer des caches, mais le motif d’un ajout est différent d’une signature d’injection.
Analyse des événements web et logs
Les logs ne sont pas un scanner au sens strict, mais ils sont souvent l’outil le plus rentable quand le malware est actif.
Ce que je cherche typiquement dans les logs, ce sont :
- tentatives de requêtes vers des URLs suspectes (php exécutés dans des chemins anormaux) pics de 404 ou de 403 sur des routes qui n’existent pas accès répétés à wp-login.php ou à des endpoints d’API erreurs PHP inhabituelles, qui peuvent révéler du code en échec d’exécution domaines externes contactés, via votre serveur, au moment où les pages se chargent
Selon votre configuration, vous pouvez utiliser les logs d’accès Nginx/Apache, les logs PHP-FPM, et parfois des traces applicatives. L’analyse “corrélée” est essentielle. Un scan de fichiers peut montrer un fichier suspect, mais les logs vous disent quand il est déclenché, et donc si votre nettoyage a réellement coupé la persistance.
Vérification avec des outils réputation et anti-malware
Les services externes peuvent vous alerter si le site est identifié comme malveillant, ou s’il y a des comportements détectés côté navigateur.
Ils sont particulièrement utiles pour la validation, car ils donnent un signal indépendant du serveur. Cela dit, ils ne vous disent pas toujours où regarder exactement. Ils indiquent plutôt “il y a un problème” et parfois la nature générale du problème.
Je les utilise comme un garde-fou, pas comme un microscope.
Deux niveaux de réponse : suppression immédiate et assainissement durable
Quand vous trouvez du code malveillant, vous avez deux tâches à gérer en parallèle : stopper ce qui exécute maintenant, puis garantir que la réinfection ne se remet pas en place.
Supprimer l’élément infectieux
Le “comment supprimer” dépend de la nature de l’infection.
- Si le malware est dans un fichier de thème ou de plugin, la suppression consiste souvent à remplacer ce fichier par une version propre, plutôt que de bricoler le code. Si vous ne pouvez pas, parce que le thème est très modifié, vous devez au minimum supprimer le bloc malveillant et vérifier l’intégrité. Si le malware est dans une archive ou un fichier dans wp-content/uploads, il faut comprendre si c’est un fichier PHP exécuté par une mauvaise configuration, ou si c’est une ressource importée à la volée. Dans le premier cas, supprimer et corriger la configuration est indispensable. Si c’est en base, il faut identifier les entrées modifiées. Le nettoyage peut être plus risqué si vous ne savez pas ce que vous supprimez, surtout sur des sites qui utilisent des champs complexes (champs custom, builders, caches).
Dans tous les cas, une règle que j’applique presque toujours : quand c’est un fichier de plugin ou de thème, je privilégie le remplacement complet par la version officielle, puis je réapplique mes personnalisations contrôlées. Ça évite les “patchs fantômes” où une petite ligne mal supprimée suffit à relancer le malware.
Neutraliser la persistance
Les malwares sérieux laissent souvent une porte ouverte. J’ai vu des cas où le script injecté avait été supprimé, mais une tâche cron cachée continuait d’ajouter le fichier à nouveau.
Les points de persistance fréquents incluent :
- tâches planifiées (WordPress cron ou cron serveur) modifications dans des hooks spécifiques, souvent liés à l’initialisation comptes utilisateurs ajoutés discrètement liens masqués dans des champs qui alimentent le frontend scripts qui chargent du contenu distant selon une condition (user-agent, pays, heure)
Si vous ne tenez pas compte de la persistance, le scan suivant vous donne la même mauvaise nouvelle.
Cas fréquents et indices concrets
Sans transformer ça en liste exhaustive, je peux vous donner des repères qui reviennent souvent sur des sites WordPress compromis.
Un signal classique, c’est un fichier PHP qui n’a pas de raison d’être dans wp-content/uploads ou dans un dossier qui n’est pas un dossier de code. Un autre, c’est un thème qui commence à injecter du HTML dans le footer de pages qui n’ont pas été touchées depuis des mois. Parfois, l’injection est conditionnelle, donc elle n’apparaît pas partout.
Un exemple vécu : un site multilingue avait été “nettoyé”, mais les utilisateurs français voyaient des redirections bizarres. Les fichiers suspects n’étaient plus visibles au premier regard. En réalité, l’injection se déclenchait seulement pour certains paramètres, ce qui rendait les tests manuels incomplets. En recoupant les logs, on a vu des appels vers des domaines externes au moment précis où la page chargeait son contenu. Une fois le mécanisme trouvé, le nettoyage a été plus propre, sans erreur de suppression partielle.
Autre cas : modifications en base. Les scans de fichiers pouvaient dire “rien de suspect”, parce que le code malveillant n’était pas dans un fichier, mais dans des options ou des champs. Dans ces situations, l’outil de scan doit être capable d’analyser la base, ou vous devez effectuer une comparaison et un audit ciblé.
Une méthode pratique en quatre temps (sans se perdre)
Je vous propose une démarche réaliste, inspirée de ce que j’ai appliqué sur plusieurs incidents, avec l’idée de limiter les dégâts et de gagner du temps. C’est aussi une manière d’éviter le piège du “je scanne, puis je supprime, puis je scanne encore”, qui peut tourner en rond.
D’abord, vérifiez rapidement l’ampleur. Est-ce un incident qui touche tout le site, ou seulement certaines pages ? Les symptômes orientent vers des fichiers spécifiques ou vers une injection en sortie HTML.
Ensuite, faites un scan de fichiers, puis un scan de cohérence des thèmes et plugins. Le but est de repérer l’écart entre ce qui devrait être là et ce qui est réellement présent.
Troisième étape, attaquez la persistance. Vous cherchez les points d’exécution récurrents, ceux qui relancent le malware. Les logs ici sont précieux.
Enfin, confirmez la propreté avec des tests externes et internes. Externe pour vérifier la réputation et la détection côté navigateur. Interne pour vérifier que les endpoints sensibles et les comportements anormaux ont disparu.
Checklist courte avant de “déclarer le site sain”
Voici une mini checklists, parce qu’au moment où tout semble propre, on a tendance à relâcher la vigilance.
- Téléchargez une sauvegarde complète (fichiers et base), puis changez les mots de passe des comptes à privilèges, activez la MFA si possible Remplacez les thèmes et plugins compromis par des versions propres, plutôt que de corriger au hasard des blocs de code Vérifiez dans les logs l’absence de requêtes répétées vers des chemins suspects et l’absence d’appels externes inattendus Contrôlez les tâches planifiées et les comptes utilisateurs, pour détecter toute persistance Lancez un second scan après nettoyage, puis testez des pages clés dans plusieurs navigateurs et, si possible, depuis des réseaux différents
Cette checklist n’est pas “la vérité absolue”, mais elle couvre les angles où les réinfections reviennent le plus souvent.
Choisir les bons scanners selon votre situation
Tous les sites ne sont pas identiques, et c’est normal. Un site vitrine très simple ne se gère pas comme une boutique WooCommerce très personnalisée. Un site qui a beaucoup de plugins et de code custom a plus de surface de modification, donc certains scanners peuvent déclencher des faux positifs.
Voici comment je raisonne, en pratique :
- si le scan de fichiers remonte des alertes sur des thèmes ou plugins, je privilégie une approche “remplacement” pour tout ce qui est concerné si le site redirige ou injecte du contenu, je crois davantage aux analyses du rendu HTML et aux tests en navigation, puis je recoupe avec les fichiers et la base si tout semble normal au niveau fichiers, je suspecte l’entrée en base ou une persistance indirecte, et je passe en mode audit plus fin si je vois une instabilité (le site se déforme à certaines heures, ou selon le trafic), je m’appuie sur les logs pour comprendre le déclencheur
Dans certains cas, vous aurez besoin de plus que des scanners automatisés. Par exemple, quand le malware est obfusqué, vous devez parfois analyser le code à la main, en particulier les petites fonctions qui décodent ou construisent dynamiquement une charge.
Pièges qui font perdre du temps (ou aggraver)
Le premier piège, c’est de nettoyer uniquement le fichier identifié comme “infecté”, sans vérifier si d’autres composants sont touchés. Sur WordPress, un seul plugin compromis peut modifier plusieurs points via des hooks.
Le second piège, c’est de réinstaller des plugins ou thèmes compromis à partir de copies non vérifiées. J’ai vu des scénarios où l’équipe a “restauré” le dossier depuis une sauvegarde déjà contaminée.
Le troisième piège, c’est de garder les mêmes identifiants et la même configuration de sécurité. Si un attaquant a déjà obtenu l’accès, il peut réinjecter un payload dès que vous ouvrez la porte, surtout si la faille initiale n’a pas été corrigée (mauvaise mise à jour, thème non maintenu, plugin vulnérable, mot de passe trop faible, absence de MFA).
Enfin, certains scanners peuvent donner une impression de finalité. Or un site WordPress peut rester “stable” pendant un temps, puis rechuter quand une tâche planifiée tourne à nouveau. C’est pour ça que la validation doit inclure le comportement dans le temps, pas uniquement un scan à un instant t.
Ce que vous pouvez faire pour réduire le risque après la suppression
Supprimer le malware, c’est une étape. Réduire le risque, c’est l’étape qui évite de revivre le même cauchemar.
Je conseille de traiter votre WordPress comme un environnement vivant :
- maintenir core, thèmes et plugins à jour, surtout ceux qui ont des autorisations élevées limiter le nombre de plugins, et supprimer ce qui n’est pas utilisé protéger l’accès à wp-login.php et activer la MFA surveiller les logs d’accès et les erreurs PHP mettre en place des sauvegardes régulières, et tester la restauration avant d’en avoir vraiment besoin
Dans les organisations, le point le plus efficace n’est pas toujours technique. C’est la discipline de suivi des changements. Un site compromis ressemble souvent à une série de “petites surprises” qui s’accumulent. Si vous avez un historique des déploiements, vous pouvez retrouver plus vite le moment où quelque chose a basculé.
Questions fréquentes avant d’attaquer
“Si un scanner ne trouve rien, je suis forcément sain ?”
Non. Un malware peut être caché dans la base, obfusqué, ou déclenché dans des conditions particulières. Un scanner rassurant est utile, mais il faut aussi vérifier le comportement, les logs, et l’intégrité des fichiers majeurs.“Faut-il restaurer tout WordPress ?”
Souvent, oui, pour ce qui concerne le core et les thèmes ou plugins compromettus. Restaurer “tout WordPress” peut être prudent, mais il faut faire attention à la sauvegarde utilisée. Si la sauvegarde est infectée, vous réintroduisez le problème. La bonne stratégie dépend de la date https://gardewp.fr/nettoyage-malware-wordpress/ et de la qualité de la sauvegarde, et du degré de personnalisation.“Quels scanners sont les plus recommandés ?”
Le meilleur choix dépend de votre situation. Les outils intégrés WordPress sont pratiques, les scanners côté serveur et les comparaisons d’intégrité sont solides, et les analyses via logs font gagner du temps quand le malware est actif. Dans une logique d’intervention, le plus fiable est rarement un seul outil, mais un couple ou un trio qui se complètent.Remettre le site sur de bons rails
Une fois le nettoyage effectué, je conseille de considérer la phase de validation comme une mini mission. Vous ne cherchez pas une perfection théorique, vous cherchez une absence de signaux : pas de nouvelles modifications, pas d’injections dans les pages clés, pas de persistance dans les hooks ou les tâches planifiées, pas d’accès anormaux.
Quand tout retombe à zéro, le site doit se comporter comme avant. Et surtout, il doit rester stable après quelques heures, puis après une journée. Ce décalage temporel est souvent la différence entre “nettoyé sur le moment” et “vraiment supprimé”.
Si vous êtes en train d’analyser un incident et que vous hésitez entre plusieurs outils de scan, gardez ce principe en tête : un scanner vous aide à localiser, mais la suppression durable vient de la combinaison avec l’intégrité, la persistance, et la validation via logs et navigation. C’est cette méthode qui transforme supprimer malware WordPress d’un acte ponctuel en processus maîtrisé.