Quand un site WordPress “tombe en alerte”, la première tentation est de s’affoler, de tout supprimer, puis de recommencer à zéro. J’ai vu des équipes faire exactement ça, et finir par effacer des réglages légitimes, casser une intégration et, surtout, ne pas régler la cause réelle. Le point commun des cas les plus pénibles, ce sont les fausses alertes et les campagnes de spam qui s’alimentent elles-mêmes.
Nettoyer un site WordPress infecté, ce n’est pas uniquement “trouver le fichier malveillant”. C’est aussi trier le bruit, vérifier ce qui est réellement en cause, puis reprendre la maîtrise: accès, fichiers, configuration, emails, formulaires, bases de données, et réputation.
Les symptômes trompeurs: quand l’alerte crie plus fort que le problème
Les fausses alertes prennent plusieurs formes. Parfois, c’est un scanner de sécurité qui remonte des signatures obsolètes. D’autres fois, c’est un plugin “anti-malware” qui sur-interprète des comportements normaux (un thème qui charge une bibliothèque distante, un site multisite avec des composants dynamiques, un WAF qui réécrit des règles). Enfin, il y a les alertes provoquées par des événements réels mais pas ceux qu’on croit: par exemple, des emails de spam qui partent via un plugin de newsletter ou via un compte compromis, alors que le code du site semble “propre”.
Sur le terrain, j’observe souvent une chronologie:
1) Le site reçoit des dizaines de requêtes inhabituelles ou des tentatives de connexion. 2) Un plugin ou un service externe déclenche une alerte. 3) Les logs montrent des pages modifiées, des redirections, ou des appels à des URLs inconnues. 4) On supprime “ce qui ressemble à du malware”, et le site semble reprendre, mais le spam continue.
Le piège, c’est de se focaliser sur la page visible et d’oublier la mécanique: un compte admin créé par l’attaquant, un crontab mal configuré, un formulaire détourné, un serveur SMTP utilisé de façon frauduleuse, ou un script qui s’exécute rarement (toutes les 6 heures, à chaque visite d’un user-agent précis, ou seulement quand un paramètre est présent dans l’URL).
Distinguer spam, phishing et infection “de code”
Avant de toucher au système, je commence par trier les catégories. Cela évite le syndrome “on a nettoyé, mais on a aggravé”. Sur WordPress, trois réalités peuvent coexister:
- Une infection de code, souvent via des fichiers ajoutés dans des emplacements inattendus, ou via un PHP injecté dans un thème, un plugin, ou des fichiers racine. Un accès compromis, via un utilisateur admin, un token de session volé, ou un mot de passe réutilisé. Un site utilisé comme relais de spam sans qu’on voie forcément du “code sale” dans les templates. Dans ce cas, l’attaquant exploite une faille de formulaire, une configuration SMTP détournée, un plugin de newsletter, ou une API.
Dans un cas que j’ai traité, le scanner “détectait” un script dans le dossier d’un plugin. En réalité, l’extension était un composant tiers, légitime, mais la configuration avait été modifiée: les emails partaient maintenant vers une liste imposée par l’attaquant. Le code n’était pas le problème central. La campagne de spam, elle, continuait parce que la source d’expédition était compromise.
Faire une vérification de base, sans casser ce qui peut servir de preuve
Avant de nettoyer, il faut réduire le risque de destruction. Je ne parle pas de lancer des opérations complexes de forensics dès la première heure, mais au minimum de préserver ce qui peut faire gagner du temps.
Regardez ce qui est déjà disponible:
- Les logs d’accès web (au moins les 24 à 72 dernières heures). Les logs d’erreurs PHP. L’historique des modifications WordPress (si vous avez un outil comme le contrôle de versions, ou au moins les dates de fichiers sur le serveur). Les événements liés aux emails: logs SMTP, logs du plugin newsletter, traces dans votre hébergement ou votre fournisseur d’email.
Le but: repérer où se situe l’impact. Si l’URL de spam est appelée, ou si des formulaires déclenchent des soumissions, vous avez une piste. Si au contraire vous voyez uniquement des tentatives de connexion, la priorité peut être l’accès, pas les fichiers.
Les premières étapes utiles, même quand l’origine reste floue
Un nettoyage efficace se fait souvent “par couches”. Vous commencez par contenir, puis vous investiguez, puis vous corrigez.
La première contenance, c’est l’accès. Si vous continuez à laisser un ou deux comptes admin ouverts, l’attaquant peut réécrire ce que vous remplacez. Dans mes interventions, la différence entre un incident géré en une soirée et un incident qui traîne pendant des semaines se joue ici.
La deuxième contenance, c’est la capacité à exécuter du code. Sur un WordPress infecté, l’objectif est de limiter l’exécution tant que vous ne savez pas ce que vous remplacez.
Et la troisième, c’est d’endiguer le spam. Selon la manière dont il s’exprime, il faut parfois couper l’émission côté serveur, ou au moins empêcher les tentatives d’envoi depuis l’instance WordPress.
Comprendre les fausses alertes de “malware” dans WordPress
Les outils automatiques ont un avantage, ils aident à aller vite. Ils ont aussi un défaut, ils peuvent faire du bruit. Les fausses alertes les plus courantes que je vois sont:
1) Une détection basée sur une chaîne de caractères générique, qui apparaît dans un autre contexte (par exemple une bibliothèque minifiée ou une variable temporaire). 2) Une signature qui ne tient pas compte du fait que WordPress met à jour des morceaux de code dans certains dossiers (cache, optimisations, miniatures, assets). 3) Un plugin de sécurité qui modifie ou inventorie des fichiers, puis déclare un “changement”, alors que ce changement est normal après une mise à jour. 4) Un “faux positif” lié aux redirections. Certains thèmes ou plugins gèrent des redirections (URL SEO, règles de cache, redirections 301). Si une règle est mal interprétée, le scanner pense à une campagne de phishing.
Ce que je fais, c’est une vérification manuelle ciblée. Si un rapport dit “fichier modifié”, je compare la date de modification, le chemin, et je lis le contenu autour de la zone incriminée. Souvent, on repère une structure typique: fonction eval, base64 decode, création de variables obfusquées, ou appels réseau vers des domaines inhabituels. Si, au contraire, la section correspond à un chunk d’asset légitime ou à un template connu, la fausse alerte est probable.
Nettoyer un site WordPress infecté: une approche en couches, pas un grand “reset”
Quand j’aborde un incident, je traite le nettoyage comme un chantier. Si vous coupez un mur en pensant qu’il y a un incendie, mais que le problème vient des câbles électriques derrière, vous allez perdre du temps. Sur WordPress, “nettoyer” consiste généralement à remettre une version saine et à corriger ce qui permet à l’attaquant de revenir.
Côté serveur et accès: couper la boucle d’infection
Avant de remplacer des fichiers, je m’assure que l’attaquant ne peut plus:
- se reconnecter en utilisant un compte créé ou modifié, réécrire des fichiers via un accès persistant, déclencher des tâches (cron) ou des scripts planifiés.
Une vérification simple, utile et rapide: listez les comptes WordPress, puis supprimez tout utilisateur dont vous ne connaissez pas l’existence. Vérifiez aussi les rôles, surtout les comptes admin. Si vous avez un envoi de mail anormal, regardez les extensions liées à l’envoi et les paramètres de configuration.
Voici une petite checklist “contenir et documenter” qui m’a rendu service dans des situations sous pression.
- Vérifier les comptes WordPress (utilisateurs ajoutés, rôles admin inconnus) Requêter les logs d’accès et d’erreurs pour repérer les heures de pics Mettre en pause temporairement les fonctionnalités d’envoi (newsletter, formulaires vers email) si possible Contrôler les tâches planifiées côté serveur si votre hébergeur expose un gestionnaire cron Sauvegarder un instant les fichiers et bases avant toute restauration (au minimum un export base et un snapshot fichiers)
Cette phase ne demande pas forcément des heures. En revanche, elle donne un cadre et évite de nettoyer pendant que la compromission continue.
Remettre WordPress et les composants à zéro, mais intelligemment
Beaucoup de personnes remplacent “WordPress” et “thème” sans vérifier les plugins, ou l’inverse. Le résultat est souvent un retour de l’infection.
Le plus robuste, c’est de raisonner en termes d’intégrité:
- WordPress core (fichiers de base) thèmes (surtout le thème actif et les thèmes modifiés) plugins (ceux actifs et éventuellement ceux présents dans le dossier) fichiers muets mais importants (robots.txt, htaccess, fichiers racine, dossiers d’assets)
Dans la pratique, je privilégie le remplacement depuis une source saine connue (téléchargement officiel pour le core, archive contrôlée pour les thèmes, et pour les plugins uniquement si vous êtes sûr de la provenance). Ensuite, je remets en place la configuration WordPress, mais je garde un œil sur les changements survenus pendant l’incident.
Un point d’attention: si vous utilisez des thèmes enfants, remplacez avec prudence. On peut réimporter le thème enfant et conserver les personnalisations, mais seulement après avoir identifié ce qui a été modifié. Sinon, vous pouvez remettre une partie infectée dans le thème enfant, alors que https://gardewp.fr/nettoyage-malware-wordpress/ le thème parent était sain.
Vérifier les fichiers “qui ne devraient pas être là”
Sur WordPress, l’hébergement contient souvent des fichiers “basiques”. Un spammeur injecte parfois des fichiers dans des emplacements qui ne sont pas censés être utilisés pour du PHP exécutable, ou dans des dossiers d’assets avec des extensions inattendues.
Ce que je fais dans ce cas est très concret: je parcours les différences, puis je lis.
Quand un fichier suspect apparaît, je regarde:
- où il se trouve exactement (chemin complet), sa date de modification, son contenu principal (structure du code, présence d’obfuscation, fonctions d’exécution), ce qu’il déclenche (redirection, extraction de variables, appels réseau).
Si vous voyez un code qui pointe vers des domaines tiers inconnus ou qui déclenche des requêtes conditionnelles, vous avez une piste. Si, au contraire, le fichier est un duplicat d’asset ou un fichier log, ne l’effacez pas à l’aveugle, car cela peut casser un composant. L’objectif est de nettoyer sans casser.
La base de données: souvent la zone oubliée
Une infection WordPress peut vivre dans la base de données, dans des éléments comme:
- options (URLs de redirection, paramètres d’exécution), shortcodes enregistrés, contenus de pages injectés (articles ou pages créées), utilisateurs (hashs de mots de passe et métadonnées), transients, ou champs spécifiques aux plugins.
J’ai déjà vu une base de données propre côté fichiers, mais pleine de contenus injectés. À l’inverse, j’ai vu des fichiers suspects, mais une base qui n’avait rien. Les deux existent, donc vous devez vérifier les deux.
Quand la base est suspecte, il faut être méthodique. Vous pouvez restaurer une sauvegarde saine, puis réappliquer la partie légitime du site, ou effectuer un “nettoyage ciblé” si l’impact est réduit. Dans les projets avec peu de contenu, la restauration complète est souvent plus simple. Dans les projets riches, on fait un nettoyage ciblé, en supprimant les pages injectées et en remettant les options sensibles.
Les campagnes de spam: ce qui déclenche les envois et comment les stopper
Une campagne de spam ne se limite pas à un site qui affiche du texte. Elle implique souvent un mécanisme d’envoi. Le plus fréquent est l’exploitation de l’envoi d’email depuis WordPress.
Cela peut venir de:
- un plugin newsletter compromis, un formulaire de contact détourné pour envoyer des messages sortants, une configuration SMTP changée, une règle de notification modifiée, un code injecté qui déclenche des envois périodiques ou conditionnels.
La difficulté, c’est que votre site peut sembler “normal” et le spam continue ailleurs. Pour trancher, j’utilise un test simple: surveiller l’émission d’email depuis le moment où vous contactez le site, et regarder si des envois ont lieu sans action humaine. Si des emails partent alors que personne n’a soumis de formulaire, vous êtes face à une automatisation.
Sur certains hébergeurs, vous pouvez aussi consulter les logs d’email. Sinon, vous passez par le plugin et les réglages. Couper temporairement le plugin d’envoi, ou désactiver les formulaires déclencheurs, peut réduire l’impact pendant l’investigation.
Un scénario fréquent: l’attaque revient parce que le “point d’entrée” n’a pas été corrigé
Les retours d’infection sont un classique. La raison la plus courante est qu’on a supprimé le symptôme, pas le point d’entrée.
Par exemple:
- un mot de passe réutilisé, ou un compte partagé, un plugin vulnérable pas mis à jour, un thème modifié avec un bout de code injecté, une configuration de permissions trop permissive, l’absence de durcissement de base (mises à jour, limitation d’accès à /wp-admin, désactivation des comptes inutiles).
Je suis partisan d’un “post-mortem” court après nettoyage. Sans jargon, juste une liste de ce qui a permis l’intrusion.
Vérifier et neutraliser ce qui permet aux robots et attaquants de continuer
Une fois le nettoyage effectué, il faut empêcher la répétition. Ici, ce n’est pas seulement technique, c’est aussi opérationnel.
Changez les mots de passe, idéalement avec un gestionnaire. Déconnectez toutes les sessions, si l’outil le permet. Activez les mises à jour WordPress, thèmes et plugins dès que possible. Et surtout, réduisez la surface: supprimez les plugins inutiles, désactivez ceux que vous ne utilisez pas.
Il y a aussi un volet “accès”. Même si l’infection est partie, un attaquant peut conserver une entrée via une configuration modifiée, des règles htaccess, ou un fichier caché.
J’ai déjà vu des campagnes de spam se poursuivre alors que le code suspect était effacé, parce que les paramètres de redirection et de traitement formulaire avaient été modifiés. Ce type de “détournement silencieux” est difficile à repérer sans comparer avant et après.
Vérifier les fausses alertes une dernière fois: réparer la confiance
Après nettoyage, un plugin de sécurité peut continuer à afficher des alertes. C’est parfois normal: le plugin conserve un historique d’intégrité, et il faut relancer un scan complet. Mais il arrive aussi que le plugin lui-même ait été à l’origine du bruit, ou qu’il signale des fichiers qui restent différents de la référence.
Je conseille de faire cette phase en deux temps:
- D’abord, confirmer que le site n’a plus de comportements anormaux: pages injectées, redirections, appels à des domaines suspects, formulaires qui envoient sans action. Ensuite, relire les alertes du scanner, fichier par fichier, en vérifiant si la différence correspond à un artefact attendu (cache, optimisation, dossier d’assets).
Si une fausse alerte persiste mais que tout le reste est sain, vous pouvez reclasser l’alerte comme “non critique”, ou changer de méthode de scan pour obtenir un diagnostic plus fiable. Ce choix dépend du niveau de risque et de votre tolérance à la complexité.
Exemple concret: quand le site semblait compromis, mais le spam venait ailleurs
Pour illustrer le tri, je reprends un cas anonymisé. Une entreprise e-commerce recevait des plaintes pour des emails non sollicités. Le scanner WordPress indiquait un fichier modifié dans un plugin, avec une alerte “high risk”. Les équipes ont supprimé le plugin, puis ont remplacé le thème. Visuellement, rien ne semblait anormal.
Le spam a continué.
Après investigation, on a constaté que les emails étaient envoyés via un service externe configuré dans le plugin de newsletter, mais que la configuration avait été modifiée lors de l’attaque. Ce n’était pas le “code” qui posait problème, c’était la destination, les paramètres d’envoi, et une liste de destinataires injectée.
Le nettoyage a été centré sur la configuration: remise en place des paramètres légitimes, suppression des utilisateurs inconnus, rotation de clés, et validation que les formulaires ne pouvaient plus déclencher d’envoi automatique. Le scanner, lui, a continué à signaler un écart, mais la campagne de spam s’est arrêtée.
C’est un bon exemple des arbitrages: il faut traiter la chaîne causale. Les alertes “code” sont utiles, mais elles ne remplacent pas la vérification du comportement réel.
Comment savoir quand vous pouvez rouvrir le site
Il y a une tentation: “le scanner dit que c’est bon, donc on réactive”. Je recommande plutôt de se baser sur la combinaison de critères.
Vous pouvez réactiver quand:
- les pages injectées et redirections sont absentes, les comptes suspects sont supprimés, les envois d’email sortants ne se déclenchent plus sans action, le site ne fait plus d’appels réseau visibles vers des domaines inconnus, les logs montrent une réduction nette des événements anormaux.
Si vous êtes en phase de doute, réactivez avec prudence. Par exemple, limitez l’accès administrateur pendant 24 ou 48 heures, surveillez les logs, et gardez une sauvegarde prête pour une restauration rapide.
Durcir pour que ça ne recommence pas
Après nettoyage, je fais toujours une mini-configuration de durcissement. Elle n’est pas “miracle”, mais elle réduit considérablement les chances de récidive.
Vous pouvez, par exemple, limiter l’accès à l’administration, imposer des mots de passe uniques, activer une authentification forte si vous pouvez, et mettre à jour rapidement. Si votre plugin de sécurité vous fait perdre du temps, ajustez-le plutôt que de le subir. Et si votre site utilise des formulaires, validez les soumissions et contrôlez le flux d’envoi.
Une règle simple, apprise avec l’expérience: si l’incident a commencé par une faille de plugin, ne remplacez pas le plugin seulement. Identifiez pourquoi il a permis l’entrée, corrigez la politique de mise à jour, puis surveillez.
Points de vigilance lors du nettoyage des fausses alertes
Traiter les fausses alertes demande un peu de discernement. Supprimer un fichier “parce que le scanner le dit” peut casser un composant, ou pire, masquer un problème plus profond.
Quelques précautions issues de cas réels:
- Comparez toujours chemin complet et date de modification, ne vous fiez pas à la seule alerte. Vérifiez le contexte, certains fichiers sont générés automatiquement (cache, optimisations). Ne remettez pas un backup “au hasard” si vous suspectez une contamination récente, vous risquez de réintroduire le problème. Si vous restaurez, faites-le avec une sauvegarde qui date avant l’incident, et testez après restauration.
Le bon sens technique, c’est d’avoir une cible mesurable: comportement du site, comptes et envois. Les alertes sont un outil, pas la vérité.
Une procédure pratique en cinq moments pour sortir de l’incident
Si vous voulez une méthode opérable, voilà comment je structure le travail sur la journée, sans la transformer en document bureaucratique. Je garde l’ordre parce qu’il répond à un risque: stopper la récidive, puis vérifier, puis remplacer, puis valider.
- Contenir: comptes admin, accès, éventuellement envoi d’emails temporairement coupé si le spam sort. Diagnostiquer: logs, fichiers modifiés, contenu injecté, utilisateurs créés, paramètres d’envoi. Remettre en état: core, thèmes, plugins depuis sources saines, restauration ciblée de la base si nécessaire. Vérifier: comportement du site, pages, redirections, formulaires, et émission d’email. Durcir: mises à jour, rotation des accès, réduction de la surface, surveillance.
Avec cette approche, vous ne chassez pas uniquement des symptômes. Vous supprimez la cause et vous réduisez la probabilité que l’attaquant repasse par le même trou.
Surveiller après nettoyage, sans tomber dans la spirale des scans
Le post-nettoyage est aussi un moment où on peut se perdre. Les scanners peuvent continuer à donner des alertes non critiques. C’est frustrant, mais ce n’est pas forcément un échec. Ce que je recommande, c’est de revenir à des signaux observables.
Surveillez:
- les logs d’accès (volume, user-agents, tentatives d’accès à wp-login.php), les logs d’erreurs (signaux d’exécution suspecte), l’activité de création de pages et de posts, l’activité d’envoi d’emails (s’il y a un plugin qui gère l’envoi, vérifiez le volume et la cohérence).
Si vous voyez une baisse d’activité anormale et que les plaintes de spam cessent, vous êtes probablement sur la bonne trajectoire.
Ce qu’il faut faire, même si vous êtes “à peu près sûr” d’avoir nettoyé
WordPress est solide quand il est correctement maintenu, mais une compromission laisse rarement un site identique à l’avant. Même si l’attaque semble terminée, il reste des risques:
- un compte créé demeure actif, un paramètre d’envoi change la destination des messages, un plugin compromis reste installé, même s’il ne semble plus exécuter de code, un fichier secondaire a été oublié (un fichier de petite taille, un script dans un dossier atypique).
C’est pour ça que je conseille de traiter l’incident comme un cycle complet, pas un coup de gomme.
Au final, le but de “nettoyer site WordPress infecté” n’est pas seulement de retrouver un site qui s’affiche. C’est de supprimer les fausses alertes en distinguant le bruit du signal, et d’arrêter les campagnes de spam en coupant la chaîne d’envoi. Quand vous combinez vérification du comportement, remise à l’intégrité des composants, rotation des accès et durcissement, le site reprend une dynamique normale. Et, surtout, vous évitez le retour de flamme au bout de quelques jours, souvent pire parce que vous avez déjà pris du retard.