Quand un site WordPress est infecté, on croit souvent que la difficulté principale est de “nettoyer”. Dans la vraie vie, le problème le plus dur commence après le nettoyage: pourquoi ça revient ? Et surtout, où se cache le mécanisme qui relance l’infection à chaque visite, à chaque mise à jour ou après chaque purge du serveur.
J’ai vu des cas où tout semblait propre, fichier par fichier, avec un scan “vert” côté outil. Quelques heures ou quelques jours plus tard, le site affichait à nouveau des scripts douteux, des redirections, des pages siphon, ou des tentatives d’accès qui faisaient planter la page d’accueil. Ce n’était pas juste un malware “collant”. C’était un système qui revenait parce que quelque chose, quelque part, gardait l’empreinte. Soit une porte d’entrée réactivée, soit une tâche programmée, soit une base de données qui réinjecte, soit un compte qui n’a jamais été réellement verrouillé.
Traiter un malware qui revient sans cesse demande une méthode, mais aussi du jugement. Le but n’est pas seulement de supprimer malware WordPress. Le but est de supprimer le mécanisme, rendre la restauration durable, et empêcher la réinfection.
Reconnaître le symptôme, puis chercher la cause
Avant de toucher aux fichiers, je commence presque toujours par cadrer ce qui revient.
- Est-ce que le site redirige vers une URL externe quand on visite une page précise, ou c’est global ? Est-ce que le comportement change selon le type d’utilisateur, par exemple uniquement en front-end mais jamais dans l’espace admin ? Les “signaux” sont-ils dans le thème, dans un plugin, dans le dossier uploads, dans la base de données, ou dans les logs serveur ? Est-ce que le site est infecté par un code PHP malveillant, ou plutôt par du contenu injecté (iframe, script, iframes invisibles, faux formulaires) ?
Cette première étape a un mérite: elle oriente la recherche. Un malware qui repointe vers d’autres domaines, souvent via du PHP, a des chances d’être logé dans un fichier. Un malware qui ajoute du contenu sur certaines pages ou qui modifie la structure WordPress peut aussi provenir de la base de données, et plus particulièrement d’entrées dans des options, des meta, ou des contenus de pages.
Quand le malware “revient”, j’ai remarqué qu’il y a deux familles de scénarios.
Le premier, c’est la réinfection “externe”: un accès compromis (mot de passe faible, admin créé par l’attaquant, plugin obsolète, vulnérabilité exploitée) qui permet au même acteur ou à un script automatique de réinstaller son code.
Le second, c’est la persistance “interne”: quelque chose reste sur le serveur malgré le nettoyage, par exemple une tâche planifiée, une modification de la configuration, un fichier dans un endroit inattendu, ou une mise en cache qui réintroduit des morceaux.
Si on ne différencie pas ces deux familles, on peut nettoyer dix fois et courir sans jamais stopper la source.
Ce qui rend les retours de malware fréquents
WordPress est flexible. Cette flexibilité aide l’écosystème, mais elle offre aussi des surfaces d’attaque.
Les causes classiques que je rencontre quand un site redevient infecté après coup:
D’abord, les identifiants. Parfois, le mot de passe d’un utilisateur administrateur a été modifié, ou un compte a été créé avec un rôle élevé. Même si vous supprimez un fichier malveillant, l’attaquant peut simplement réinjecter le code à la prochaine occasion.
Ensuite, les plugins. Un plugin qui a été nettoyé une fois peut être réactivé. Certains malwares copient une portion de code dans un autre fichier puis s’effacent, pour compliquer la détection. Au premier scan, on ne voit plus rien, puis lors d’un renouvellement de cache ou d’un appel spécifique, le code réapparait.
Autre point: les fichiers dans les uploads. WordPress sert énormément de médias via wp-content/uploads. Un attaquant peut y déposer des fichiers PHP déguisés, ou des fichiers qui sont ensuite appelés via des URL trompeuses.
Enfin, les tâches planifiées. Les “cron jobs” de WordPress ne sont pas toujours surveillés. Un malware peut programmer une action qui reconstruit le code malveillant, ou réécrit un fichier au bon moment. Et si vous restaurez seulement ce que vous voyez, vous perdez la course.
La question clé: où se trouve l’élément qui persiste ?
Pour stopper un malware qui revient, il faut localiser le mécanisme de persistance. Je privilégie une séquence pragmatique, avec l’idée d’éviter les actions “au hasard” qui peuvent masquer l’origine.
Je regarde d’abord les fichiers, puis la base de données, puis la logique côté WordPress (utilisateurs, cron, options). Et je vérifie toujours les chemins “hors des habitudes”. Les malwares ont tendance à se cacher là où on ne pense pas.
Quelques zones qui surprennent souvent:
- wp-content/uploads, avec des fichiers qui n’ont rien à faire là, ou des noms très proches de fichiers légitimes le thème, mais surtout les fichiers qui ne changent jamais sauf lors d’une mise à jour (si vous n’avez pas mis à jour, pourquoi un fichier du thème a-t-il une date récente ?) des fichiers à la racine (ou des dossiers anonymes) qui ajoutent une condition d’exécution basée sur des paramètres d’URL des caches, notamment si votre hébergement a mis en place des accélérateurs au niveau serveur, car ils peuvent rejouer du contenu
C’est là que l’idée de “supprimer malware WordPress” doit évoluer vers “identifier et couper la chaîne de réinfection”. Si la chaîne reste, vous aurez toujours un retour.
Mettre le site en sécurité avant de nettoyer
Avant toute manipulation lourde, j’isole le risque. Sur un site infecté qui revient, chaque heure compte, parce que l’attaquant peut aussi:
- collecter des informations via des pages injectées préparer une persistance plus stable exploiter des failles en parallèle
Sur le plan opérationnel, je fais en général deux choses en amont:
Premièrement, je mets le site en mode “réparation” ou j’en limite l’accès, le temps de passer à l’inspection. Selon votre hébergeur, cela peut se faire via une page temporaire, un filtre IP, ou une redirection propre vers une page maintenance.
Deuxièmement, je bloque ou j’encadre l’accès à l’espace d’administration. Si le site est actuellement accessible depuis Internet, je privilégie une action rapide pour réduire le nombre de tentatives externes pendant l’analyse.
Ce n’est pas du confort. C’est de l’hygiène technique. Quand on a déjà un malware, le laisser “vivre” pendant qu’on nettoie, c’est accepter de mélanger les symptômes avec les actions de l’attaquant.
Nettoyer, oui, mais comment nettoyer sans réamorcer
Une erreur fréquente est de remplacer “le dossier wp-content” ou de réinstaller WordPress en copiant-collant, sans examiner ce qui a été modifié dans l’intervalle. Si votre site a une base de données infectée, ou si un mécanisme dans les options réinjecte du code à la prochaine visite, vous pouvez restaurer les fichiers core, mais garder la source côté base.
Inversement, si la persistance est dans un plugin spécifique, remplacer tous les fichiers “au feeling” peut vous faire perdre l’emplacement exact du problème, et compliquer la preuve pour l’expert ou le support d’hébergement.
Une approche propre consiste à:
- faire un inventaire rapide avant modifications: ce qui a changé (dates de fichiers, nouveaux fichiers, plugins ajoutés, comptes créés) supprimer ce qui est malveillant avec une logique de suppression traçable ne pas seulement “remplacer”, mais aussi “contrôler” après restauration
Quand le malware revient, on ne repart pas d’une installation “propre” en espérant que cette fois ce sera différent. On reconstruit la stabilité.
Vérifier les traces dans la configuration et les options
WordPress a plusieurs endroits où une injection peut prendre forme. La configuration de l’application, par exemple, peut être modifiée. Et côté base de données, les options sont souvent la zone la plus discrète.
Je cherche notamment les éléments typiques de persistance, sans m’enfermer dans un seul pattern. Un malware peut:
- ajouter des hooks à des endroits inattendus stocker des chaînes de code ou des URL dans des options modifier des shortcodes ou des contenus enregistrer des événements cron
Selon les configurations, ces changements peuvent se manifester par une variation soudaine de la taille de certaines tables, ou par des entrées nouvelles.
Si vous utilisez un accès de base de données (via phpMyAdmin, ou un outil équivalent), l’objectif n’est pas de “tout vider”. L’objectif est d’identifier ce qui n’a pas sa place. Une suppresion brute peut casser le site, mais pire, elle peut laisser le mécanisme intact dans un autre emplacement.
Contrôler les utilisateurs, c’est souvent le vrai tournant
Quand un malware revient sans cesse, j’ai appris à considérer la gestion des utilisateurs comme un point non négociable.
Même si vous supprimez les fichiers malveillants, un utilisateur compromis peut remettre le code. Parfois il ne le remet pas en direct, il déclenche un script qui réinstalle. Dans tous les cas, tant que l’accès initial n’est pas coupé, vous aurez des retours.
Je vérifie donc:
- comptes administrateurs: date de création, rôle, activité utilisateurs récemment créés ou dont l’activité est incohérente adresses e-mail et noms d’affichage qui ne correspondent pas à votre organisation toute procédure d’accès qui semble avoir été ajoutée sans raison
Quand je tombe sur un compte créé “hier”, avec un mot de passe inconnu, la décision est simple: suppression après confirmation, puis réinitialisation de tous les mots de passe des comptes restants et nettoyage des sessions.
Si vous avez un système d’authentification externe (SSO, Google, etc.), je vérifie aussi les sessions côté fournisseur, car un attaquant peut garder un accès même après nettoyage côté WordPress.
Les plugins et thèmes: remplacer, mais aussi comprendre pourquoi ça revient
Beaucoup d’équipes font la réparation suivante: suppression du plugin suspect, réinstallation du thème, et update du reste. C’est un bon réflexe, mais le risque est que vous répariez la surface sans enlever la cause.
Je me pose toujours deux questions:
1) Est-ce que le plugin ou le thème incriminé a été modifié, même si vous avez “désinstallé” ? 2) Quel composant déclenche la réinfection, manuellement ou via cron ?
Quand j’inspecte, je regarde aussi des choses “humaines” dans le code: condition d’exécution basée sur un paramètre d’URL, fonction inconnue, concaténations qui construisent une charge utile, appels à des endpoints, ou base64 compressée. Le but n’est pas de devenir expert en chaque malware. Le but est de repérer la logique d’exécution.
Un plugin infecté peut aussi être “nettoyé” par un outil, puis rechargé à la prochaine mise à jour automatique ou à la réinstallation. Si le même binaire continue de venir d’une source compromise, vous retrouvez la même infection.
C’est pour cela que je privilégie les téléchargements depuis des sources fiables, et la validation de l’intégrité quand votre processus d’hébergement le permet.
Une méthode en pratique pour stopper un retour en boucle
Je vous propose une séquence opérationnelle, utilisée quand le malware revient, avec des décisions pragmatiques. Ce n’est pas une théorie. C’est ce que j’applique quand j’ai besoin de résultat.
1) Isoler et figer l’environnement. Je mets le site en maintenance, je sauvegarde, puis je coupe l’accès pendant l’inspection.
2) Inventorier avant modification. Je repère les nouveaux fichiers, les dates, les plugins ajoutés, et les comptes créés. 3) Supprimer les vecteurs, pas seulement le symptôme. Je traite le plugin, les fichiers cachés, et la base si des options ou des contenus ont été altérés.4) Contrôler les mécanismes de persistance. Je vérifie les cron, les hooks, et les recharges éventuelles via options ou contenus. 5) Valider pendant une période. Je contrôle les URL sensibles et les pages où l’injection apparaissait, sur plusieurs navigateurs et avec et sans session admin.
C’est une liste courte, mais elle correspond à la réalité: stopper la boucle est un travail de verrouillage progressif. Supprimer malware WordPress n’est pas “une action”. C’est un cycle complet.
Le cas des redirections: attention aux caches et aux injections conditionnelles
Quand le malware revient, le symptôme peut être une redirection vers une page de phishing, ou une landing page qui ressemble à votre site. Dans ces cas, l’attaquant adore mettre des conditions: rediriger uniquement si l’utilisateur vient d’un certain pays, uniquement si la requête contient un paramètre, uniquement si le user agent ressemble à un navigateur.
Résultat: vous nettoyez, puis vous testez avec votre navigateur habituel. Tout semble normal. Jusqu’au moment où le site est testé depuis un autre chemin, ou quand un autre utilisateur tombe sur l’injection.
J’ai déjà vu des sites “propres” quand on testait en local, mais infectés en production car la redirection dépendait d’en-têtes HTTP. Les redirections conditionnelles sont rarement visibles au premier scan.
Pour éviter ce piège, je teste de manière plus variée:
- une session admin et une session visiteur des URL qui déclenchaient le problème initial des requêtes sans cookies si possible et parfois via un outil externe d’inspection de contenu
Ce n’est pas agréable, mais ça évite de croire que tout est résolu alors que la persistance se déclenche ailleurs.
Les logs et l’hébergement: le narrateur discret de l’incident
Beaucoup de propriétaires de sites pensent que le malware “vit dans WordPress”. Parfois, oui. Souvent, le malware commence ailleurs, et WordPress n’est que le terrain d’expression.
Les logs serveur sont une mine. Ils peuvent révéler des tentatives répétées vers des endpoints, des erreurs PHP, des accès anormaux à des fichiers particuliers, ou des pics d’activité juste au moment où vous avez “fini le nettoyage”.
Quand le malware revient sans cesse, je veux savoir si:
- des requêtes continuent à frapper des URL spécifiques des tentatives de connexion échouent mais finissent par réussir des fichiers suspects sont re-créés après votre nettoyage des événements cron semblent se relancer
Selon votre hébergement, l’accès aux logs est plus ou moins simple. Mais même une simple extraction sur quelques jours suffit souvent à comprendre le rythme de l’attaque.
Côté pare-feu applicatif, si vous avez un WAF ou des règles de base, je renforce ce qui peut filtrer les patterns évidents. L’objectif n’est pas de “faire joli”. L’objectif est d’ajouter une couche pendant que vous sécurisez.
Sécuriser après nettoyage: empêcher la prochaine boucle
Une fois que vous avez supprimé le code et coupé les accès compromis, vous êtes tenté de relaxer. C’est là que l’incident se répète le mois suivant.
La sécurisation durable repose sur des basiques solides. Et surtout, sur la continuité: mises à jour, surveillance, durcissement des accès, et sauvegardes fiables.
Voici les actions que je privilégie, sans les transformer en rituel. Une fois que j’ai stoppé le retour du malware, je m’assure que les mêmes failles ne se reconstituent pas.
- Mettre à jour le cœur WordPress et les thèmes, puis les plugins, en commençant par ceux exposés au risque. Désactiver et supprimer les plugins inutiles, surtout ceux que personne ne maîtrise. Appliquer un verrouillage des mots de passe et des sessions, et vérifier l’absence de comptes douteux. Renforcer la gestion admin: limiter les tentatives de connexion, et si possible ajouter une couche d’authentification forte. Mettre en place une sauvegarde restaurable et testée, pas une sauvegarde “théorique”.
Ce sont des mesures simples, mais elles changent la donne. Un malware peut revenir une fois. Revenir deux fois, c’est que la porte d’entrée n’a pas été fermée correctement.
Sauvegarde et restauration: le piège de la “bonne” copie
Dans une situation de malware persistant, la sauvegarde est votre filet. Pourtant, elle peut être un piège si elle date de la période où l’infection était déjà active.
J’ai déjà vu des restaurations qui semblaient réussies pendant une journée, puis l’infection réapparaissait. La sauvegarde contenait en réalité la persistance: soit des options déjà infectées, soit un utilisateur compromis déjà présent.
Pour éviter ça, je vérifie la sauvegarde elle-même quand c’est possible, et je m’assure que la période de sauvegarde est cohérente avec le moment où vous avez identifié l’infection.
Parfois, la meilleure décision est de sauvegarder de toute façon avant modification, puis de reconstruire à partir d’un core propre et d’une base filtrée. C’est plus long, mais c’est plus fiable si vous suspectez une persistance complexe.
Quand il faut faire appel à un spécialiste (et comment choisir)
Supprimer malware WordPress est faisable dans beaucoup de cas, surtout si l’infection est récente et bien localisée. Mais quand le malware revient sans cesse, il y a une frontière.
Je pense qu’il faut envisager un spécialiste quand:
- le site se réinfecte avant que vous ayez le temps de finir l’analyse vous voyez des signes dans plusieurs zones à la fois, fichiers, base, cron, et accès vous manquez d’indices dans les logs et que l’attaque semble automatisée et récurrente le niveau de code et de structure rend la restauration “à la main” trop risquée
Le critère que je privilégie est simple: la personne doit expliquer une démarche de diagnostic, pas seulement proposer un “nettoyage”. Si on vous promet un résultat en ignorant la cause, c’est un pari.
Je demande toujours, avant engagement: comment vous vérifiez la persistance ? Sur quoi vous basez-vous pour conclure que c’est terminé ? Quelles vérifications post-nettoyage sont faites et sur quelle période ?
Une mini check de bon sens pour éviter de tourner en rond
Quand vous êtes en plein nettoyage, le cerveau sature vite. On veut aller vite. Le risque est de refaire la même chose que la dernière fois.
Voici une courte check mentale, que j’utilise pour ne pas me tromper d’étape.
- Le malware revient-il après une restauration depuis une sauvegarde, ou uniquement après des actions spécifiques (updates, vidage cache, certaines pages) ? Est-ce que des fichiers suspects sont recréés après coup, et si oui lesquels ? Est-ce que de nouveaux comptes admin apparaissent ? Est-ce que des cron events se relancent ? Est-ce que la base de données contient encore des options ou du contenu injecté au moment où le problème revient ?
Si vous répondez à ces questions, vous avez déjà une grande partie du diagnostic. Sans ces repères, on finit souvent par “nettoyer” sans compréhension, et le retour arrive exactement comme la première fois.
Ce que vous pouvez faire dès maintenant si vous êtes bloqué
Si vous êtes dans une situation où le malware revient sans cesse, ne vous lancez pas immédiatement dans une réinstallation intégrale en espérant que “ça ira”. Faites plutôt une analyse orientée sur la persistance. Commencez par isoler le site, puis identifiez les modifications récentes, contrôlez les utilisateurs, et inspectez les cron et la https://gardewp.fr/nettoyage-malware-wordpress/ base.
Et surtout, documentez. Notez ce que vous avez supprimé, à quel moment, et quand le problème revient. Sans chronologie, vous perdez la capacité de confirmer ce qui a réellement été corrigé.
WordPress peut être reconstruit proprement, mais la tranquillité vient de la méthode, pas du “coup de propre”. Un malware qui revient est un signal. Il vous dit que la source est toujours là, parfois ailleurs que là où vous regardez.
Si vous voulez un objectif concret, il se résume à ceci: une fois le nettoyage terminé, vous ne devez plus voir de modification des fichiers sensibles, vous ne devez plus constater de nouvelles entrées dans les comptes admin, et le comportement malveillant ne doit plus se déclencher, même dans les scénarios qui déclenchaient l’infection.
C’est long parfois. Mais quand vous stabilisez le site, vous n’avez plus besoin de répéter le nettoyage. Vous avez enfin supprimé la boucle.