Un site WordPress propre peut basculer très vite. Tout commence souvent par un détail banal: un visitor qui tombe sur une redirection étrange, un pic de trafic inexpliqué sur une URL précise, ou un navigateur qui affiche un avertissement de sécurité. Puis viennent les signaux plus discrets: des fichiers nouveaux apparus dans le répertoire racine, un thème “qui n’est plus tout à fait le même”, ou un footer qui contient un bout de JavaScript illisible.
Quand on parle de désinfection WordPress, le plus dur n’est pas d’effacer un fichier. Le plus dur est de comprendre ce qui a été modifié, ce qui persiste, et ce qui risque de revenir dès que vous relancez le site. Dans les cas réels, les “scripts malveillants” ne sont pas toujours un gros fichier exécutant tout. Très souvent, c’est un mélange: un script dans un dossier inattendu, une entrée dans le tableau de bord via un plugin compromis, une charge utile injectée dans le thème, et une technique de dissimulation pour que l’attaque reste au calme.
Je vous propose une méthode pratique, pas un discours théorique. Elle s’appuie sur le tri, l’isolement, et des décisions prudentes. Vous allez aussi voir les compromis, parce que dans la désinfection, on choisit parfois entre la vitesse et la certitude.
Les formes courantes des infections sur WordPress
Les campagnes actuelles visent surtout trois choses: l’exécution de code côté navigateur (JavaScript), l’installation de charge côté serveur (PHP), et la persistance via la base de données. Selon la façon dont le site a été compromis, l’attaque peut laisser des traces très différentes.
Parmi les scénarios que j’ai rencontrés en intervention, les plus fréquents ressemblent à ceci:
- un script PHP placé dans un dossier “camouflé” (par exemple un répertoire qui ressemble à un dossier de cache ou à une structure interne), une injection dans le thème (footer, header, fonctions de thème, fichiers partagés), des modifications dans la base de données (options WordPress, hooks, contenu de pages, compte administrateur ajouté).
Dans certains incidents, le script n’est pas directement visible dans l’interface. Il est discret dans un fichier minifié, ou il se déclenche uniquement quand une condition est vraie, comme l’agent utilisateur, l’IP, ou une chaîne présente dans l’URL.
Un point important: si vous ne regardez que les fichiers “changés”, vous pouvez rater une infection logée dans la base, ou l’inverse. L’attaque est parfois fractionnée.
Avant de nettoyer: arrêter l’hémorragie sans aggraver
Quand vous découvrez un script malveillant, la tentation est d’agir vite. Vous avez raison d’être pressé, mais vous devez éviter de “casser” la trace. La désinfection se fait plus efficacement si vous capturez l’état.
Dès que possible, passez dans une logique d’isolement. Si votre hébergeur le permet, activez un mode maintenance ou mettez le site derrière un verrou temporaire le temps de l’analyse. L’idée n’est pas d’empêcher votre propre accès, mais d’éviter que le code malveillant continue à servir ses charges à des visiteurs.
Côté pratique, je recommande de:
- sauvegarder immédiatement fichiers et base (même si vous finissez par tout réinstaller), copier en local les fichiers potentiellement modifiés, noter l’heure et les symptômes (redirections, avertissements navigateur, pages touchées).
Ce petit travail de discipline vous évite deux erreurs classiques. Première erreur: nettoyer “à l’aveugle”, puis découvrir ensuite que la base contenait aussi des modifications qui déclenchent toujours la charge. Deuxième erreur: supprimer sans preuve, puis ne plus pouvoir reconstruire ce qui a été touché.
Indices qui doivent vous faire suspecter une infection active
Voici les signaux qui m’ont aidé à prioriser l’analyse. Si vous en voyez plusieurs, considérez le site compromis jusqu’à preuve du contraire.
Apparition de redirections vers des domaines inconnus, surtout depuis des pages internes Création de nouveaux fichiers au niveau racine ou dans des dossiers non utilisés par WordPress Appels réseau étranges depuis le navigateur (scripts externes inattendus, téléchargements bloqués) Plugins ou comptes récents, dont vous ne reconnaissez ni l’origine ni la date Changement du contenu visible sans modification éditoriale côté interfaceSi ces éléments sont présents, ne perdez pas de temps sur des hypothèses “ça vient du thème” ou “c’est juste un plugin”. L’infection peut être un enchaînement.
Rechercher la persistance: fichiers, base, et points d’exécution
Pour supprimer efficacement les scripts malveillants, vous devez viser les mécanismes de persistance. WordPress est robuste, mais il offre aussi des points d’entrée. Une attaque réussie cherche un endroit où elle peut s’accrocher: un fichier PHP appelé à chaque requête, un filtre ou un hook ajouté en base, ou une modification de fonction dans un thème.
En pratique, je travaille en trois axes, sans les traiter comme des étapes rigides.
1) Fichiers: ce que WordPress charge réellement
Les scripts malveillants sont souvent exécutés via un chemin qui reçoit une requête. Cela peut être:
- un fichier inclus directement par WordPress, un fichier appelé indirectement via un hook, ou un “dropper” qui vérifie une condition avant d’exécuter une charge.
La stratégie consiste à comparer l’état attendu à l’état observé. Vous n’avez pas besoin de “tout comprendre” au début, mais vous devez identifier ce qui a été modifié.
Concrètement, cherchez les choses qui ne ressemblent pas à du WordPress normal:
- des fichiers PHP dans des répertoires qui ne devraient contenir que du statique (ou l’inverse), des tailles de fichier incohérentes, par exemple un fichier de thème de quelques lignes devenu une page longue et opaque, du code obfusqué (caractères inutiles, concaténations répétées, fonctions bizarres).
Quand vous trouvez un fichier suspect, ne vous contentez pas de le supprimer. D’abord, vérifiez qui l’a créé ou au moins son contexte. Si c’est un thème, pensez à l’attaque qui s’est servie du thème pour injecter du code dans footer.php ou functions.php. Si c’est un plugin, vérifiez les fichiers chargés et la base associée.
2) Base de données: options, hooks, et contenu piégé
Beaucoup d’attaques “survivent” même si vous remettez les fichiers corrects. Pourquoi? Parce qu’elles ont modifié des valeurs dans la base, parfois dans des champs qui ne font pas de bruit.
Selon le type d’infection, vous pouvez voir:
- des valeurs d’options modifiées (par exemple des variables censées être statiques), des insertions dans des champs utilisés par des hooks, des contenus de pages modifiés, même s’ils ont l’air “normaux”.
La difficulté, c’est que la base WordPress peut contenir du contenu légitime qui ressemble à du code, si vous utilisez certains plugins ou éditeurs. Donc, vous ne cherchez pas “n’importe quel mot”. Vous cherchez des modèles d’infection.
Un exemple fréquent: des chaînes qui ressemblent à des identifiants de scripts injectés, des URL externes inattendues, ou des fragments PHP stockés dans des zones qui ne devraient pas contenir du PHP. WordPress stocke du contenu, mais le PHP ne devrait pas se promener dans n’importe quel endroit.
Si vous avez accès à un outil d’administration SQL ou à phpMyAdmin, cherchez les occurrences et validez ensuite. Ne modifiez pas au hasard, même si la pression est forte.
3) Les points d’exécution côté WordPress
L’autre axe, c’est “comment le code malveillant se déclenche”. Même si vous effacez un fichier, un hook ou un filtre peut continuer à injecter du code. L’attaque peut aussi s’appuyer sur des actions comme:
- l’enqueue de scripts, des filtres sur le contenu (the_content), une modification de la logique d’inclusion de templates.
C’est là que l’approche “je supprime le fichier suspect” peut échouer si le vrai déclencheur est ailleurs. Le bon réflexe est de remonter du déclencheur vers la source.
Méthode de désinfection: ordre de travail qui évite les retours
Il y a une différence entre nettoyer et éliminer la cause. La désinfection efficace ressemble plus à une enquête qu’à un effacement.
Voici l’ordre que j’ai utilisé quand l’objectif était de réduire les risques de “recontamination” sans perdre une semaine.
Étape 1: mettre le site en mode lecture contrôlée ou maintenance
Un site infecté peut continuer à servir des charges pendant que vous travaillez. Le risque n’est pas seulement la sécurité des visiteurs. Le risque, c’est que votre analyse soit polluée par un trafic qui déclenche des comportements conditionnels.
Je bloque l’accès au public si possible. Si vous devez garder le site partiellement accessible, filtrez au minimum les endpoints critiques et inspectez le comportement des pages qui redirigent.
Étape 2: isoler le périmètre des modifications
Avant de supprimer, je collecte. Je veux savoir ce qui a changé entre une version connue “probablement saine” et maintenant. Idéalement, vous avez des backups datés. Si vous n’en avez pas, partez du principe que vous devrez peut-être tout réinstaller, mais commencez quand même par un tri.
L’objectif est d’identifier:
- les fichiers ajoutés récemment, les fichiers modifiés récemment, les plugins ou thèmes ajoutés, les changements dans la base autour des dates proches de l’incident.
Un bon signal, c’est la cohérence. Si un plugin a été mis à jour la veille et que, le lendemain, les redirections apparaissent, vous avez un suspect fort.
Étape 3: désactiver l’exécution suspecte sans casser votre lecture
Si vous pouvez vous connecter au tableau de bord, désactivez en priorité les plugins récemment ajoutés ou mis à jour. Par prudence, j’évite de “toucher” aux fichiers tant que je n’ai pas sécurisé les backups.
Ensuite, je teste le site en environnement contrôlé (au moins via un navigateur “propre” ou une fenêtre privée). Si la charge disparaît, vous avez déjà un indice. Si elle persiste, vous devez élargir.
Étape 4: remplacer le noyau et vérifier thèmes/plugins
Même si vous trouvez le script malveillant dans un fichier, je recommande souvent une approche de remplacement du noyau et, selon les cas, des éléments de thème et de plugin.
Le noyau WordPress peut être nettoyé en réinstallant les fichiers officiels, mais sans écraser vos contenus. Pour les thèmes et plugins, vous choisissez selon leur source:
- si c’est un thème custom, vous devrez comparer avec la version d’origine, si c’est un thème téléchargé ou un plugin officiel, un remplacement propre est généralement plus rapide que de “débroussailler” des modifications invisibles.
Le compromis est clair: remplacer peut supprimer des personnalisations. Mais en incident de sécurité, vous récupérez ensuite via votre système de version ou vos sauvegardes.
Étape 5: nettoyer la base de manière ciblée
Une fois les points d’exécution côté fichiers neutralisés, vous attaquez la base. Là, vous cherchez les traces qui déclenchent encore l’injection.
Si vous détectez des entrées suspectes (par exemple une option contenant un fragment de script, ou une Super article à lire valeur d’URL externe ajoutée), supprimez ou rétablissez à une valeur cohérente. Si vous n’êtes pas sûr, repliez plutôt sur un restore partiel ou un restore complet vers un backup antérieur, puis recommencez le tri.
C’est plus long, mais souvent moins risqué.
Petit checklist avant de relancer en production
Tout plugin et thème inutiles sont désactivés, et seules les versions attendues restent actives Les fichiers modifiés récemment ont été remplacés ou validés manuellement La base a été inspectée pour les options et contenus suspects liés à la période d’incident Vous testez au moins une page exposée + une page “qui déclenche” historiquement l’attaque, depuis une session neutreIdentifier le script malveillant: quoi chercher dans le code sans s’y perdre
Je vois beaucoup de gens ouvrir un fichier suspect, tomber sur un bloc obfusqué, puis le supprimer immédiatement. Parfois ça marche. Parfois vous supprimez la partie visible, mais la vraie charge est ailleurs.
Quelques patterns qui reviennent souvent:
- la présence de fonctions d’évaluation dynamique (dans certains cas, des constructions qui peuvent exécuter du code à partir d’une chaîne), des URL écrites en dur, surtout vers des domaines non liés à votre activité, des conditions basées sur des en-têtes ou des variables d’environnement, des noms de fichiers qui ressemblent à des scripts “techniques” mais sans cohérence.
Un réflexe utile: vous cherchez le “point d’entrée”, pas seulement la payload. Si le fichier est inclus depuis un hook ou depuis un include global, il est probable que l’attaque soit là. Si le fichier n’est jamais appelé, il peut être un dépôt inactif, utile pour une autre étape.
Dans certains cas, le code malveillant ne fait rien tant qu’il ne trouve pas une condition. C’est pour ça que des tests “vite fait” peuvent échouer. Il faut tester sur les pages qui étaient touchées, et sur une navigation complète, pas uniquement l’accueil.
Le moment délicat: thème custom, builders et personnalisations
WordPress, c’est rarement uniquement du standard. Entre les builders visuels, les shortcodes, les scripts ajoutés via le thème, et les hooks pour la performance, un site a souvent des couches.
Le piège pendant la désinfection, c’est de supprimer ce qui est “bizarre” mais légitime. Par exemple, une insertion JavaScript faite par un plugin de tracking peut ressembler à une injection si elle est mal indentée ou si elle inclut une URL externe. Pourtant, elle n’est pas forcément malveillante.
Ma règle est simple: je traite comme suspect tout ce qui a été modifié autour de la période d’incident, ou tout ce qui est exécuté mais ne correspond à aucune intention connue. Si vous ne savez pas à quoi sert un morceau de code, vous le neutralisez et vous cherchez la source ailleurs.
Ensuite, seulement après stabilisation, vous restaurez proprement. Cela peut passer par:
- un retour à une version saine du thème, un diff de fichiers (entre votre version et une version attendue), ou un remplacement complet du thème par une version de base, puis réapplication des personnalisations.
Sécuriser après la désinfection: empêcher la récidive
La désinfection est un moment, la sécurité est un processus. Beaucoup d’incidents reviennent parce que la porte d’entrée initiale reste ouverte. Et sur WordPress, la porte d’entrée est rarement “le script malveillant” en lui-même. C’est le moyen utilisé pour le déposer.
Les causes fréquentes, sur le terrain:
- mots de passe faibles, réutilisés, ou compromis via phishing, absence d’authentification forte lorsque des comptes admin sont exposés, plugins obsolètes ou mal configurés, fichiers uploadés ou permissions trop larges, configuration serveur permissive, notamment côté écritures sur des chemins sensibles.
Je ne vous propose pas une liste de “recette miracle”. Mais je vous donne des décisions concrètes qui ont un vrai effet:
- changez tous les mots de passe des comptes WordPress et associez un second facteur si possible, supprimez les comptes inutiles, surtout ceux que vous ne reconnaissez pas, mettez à jour les plugins et thèmes, puis conservez uniquement l’essentiel, vérifiez les rôles: un compte éditeur ou auteur qui peut faire trop de choses est une faille organisationnelle, surveillez les événements d’administration et les modifications de plugins.
Enfin, gardez un œil sur les indices d’exécution après la désinfection. Si vous observez des requêtes sortantes vers des domaines inconnus, ou si les pages injectent à nouveau des scripts, vous n’êtes pas au bout du travail.
Cas pratiques: trois scénarios et la bonne attitude
Scénario 1: injection dans le footer du thème
Le symptôme est souvent immédiat. Vous voyez des redirections ou des scripts externes chargés à chaque page. Quand on inspecte le thème, on trouve un morceau de code dans footer.php ou un fichier inclus.
La correction la plus rapide, en général, c’est de remplacer le thème par une version propre, puis de réintégrer uniquement les personnalisations nécessaires. Si vous essayez de “corriger” le code à la main dans le fichier infecté, vous risquez de rater une autre partie.
Scénario 2: plugin compromis qui reconfigure la base
Ici, après remplacement des fichiers, le site “semble” propre mais se réinfecte au bout d’un moment. La base contient des options ou des valeurs qui re-déclenchent l’injection.
Dans ce cas, il faut traiter le plugin et les entrées base. La question n’est pas “quel fichier a un script”, mais “quel mécanisme ré-applique la charge”. Une fois que vous neutralisez le mécanisme dans la base, même si le plugin reste présent, il cesse d’être actif.
Scénario 3: plusieurs points d’entrée, donc désinfection partielle
Quand l’attaque est sophistiquée, il y a parfois un mélange de fichiers et de base. Si vous nettoyez seulement les fichiers, vous perdez du temps. Si vous nettoyez seulement la base, la page peut réinjecter via un fichier modifié.
La bonne attitude, c’est la vérification croisée. Neutralisez, testez, puis élargissez. Vous évitez l’erreur de croire que “c’est fini” parce qu’une page semble revenue.
Mesurez votre succès: tests simples, mais honnêtes
Pour savoir si la désinfection WordPress a réellement fonctionné, je teste toujours avec trois angles:
- navigation utilisateur réelle sur les pages touchées, contrôle de la console et du chargement de scripts côté navigateur, observation côté serveur, au moins de manière indirecte (pics, logs, erreurs).
Si le script malveillant est conditionnel, vous aurez parfois l’impression d’avoir nettoyé alors que la charge revient quand un agent utilisateur spécifique visite. C’est pour ça que je teste au moins depuis deux profils de navigation différents, et sur une navigation complète, pas juste un chargement unique.
Quand il vaut mieux repartir de zéro
Il y a un moment où “réparer” devient plus risqué que reconstruire. Je pense notamment aux cas où:
- vous n’avez pas de backup fiable avant l’incident, vous voyez des modifications à grande échelle (multiples fichiers, multiples plugins, base modifiée de façon inattendue), le site a plusieurs thèmes, des plugins nombreux, et vous ne pouvez pas valider la provenance exacte de chaque modification, les traces d’infection restent actives malgré le remplacement ciblé.
Dans ces situations, une reconstruction propre, avec restauration de contenu uniquement, peut être la voie la plus rapide au final. Oui, c’est plus “lourd”. Mais si vous devez passer des jours à traquer une persistance indétectable, vous finissez au même point, sauf que le stress et le risque de récidive sont plus élevés.
Pour finir, retenez la logique
La désinfection efficace, ce n’est pas “supprimer le fichier suspect”. C’est:
Sécuriser l’environnement pour arrêter la propagation, Collecter l’état avant de toucher trop vite, Neutraliser les points d’exécution dans les fichiers et dans la base, Remplacer ou valider ce qui a été modifié, Enfin, fermer la porte d’entrée pour empêcher le retour.
Quand on applique cette logique avec calme, même un incident lourd devient gérable. Et surtout, votre site ne retrouve pas seulement un aspect normal, il retrouve un comportement normal, ce qui est la vraie preuve qu’on a éliminé la cause.