Quand un site WordPress commence à “agir bizarrement”, on a souvent tendance à vouloir tout nettoyer à la hâte. Copier-coller des fichiers depuis une sauvegarde, relancer des mises à jour, changer quelques mots de passe… et espérer que ça suffise. Le problème, c’est qu’une infection WordPress ne se résume presque jamais à “un fichier malade”. Elle ressemble davantage à une chaîne, où une porte a été ouverte, puis une autre a été utilisée pour persister, et enfin du code malveillant se déclenche parfois à un moment précis ou sur certains visiteurs.
Le vrai travail, celui qui évite de retomber dans le même piège, consiste à identifier la cause, couper la persistance, puis corriger proprement le mécanisme qui a permis l’intrusion. Dans ce guide, je vais te donner une méthode réaliste, basée sur ce qu’on rencontre sur le terrain, pour faire un nettoyage fichiers infectés WordPress sans te contenter d’un “reset” superficiel.
Les symptômes qui orientent le diagnostic
Avant de toucher aux fichiers, j’essaie toujours de classer le problème. Pas pour faire de la théorie, mais pour gagner des heures. Une infection se manifeste rarement de façon totalement aléatoire. Elle laisse souvent des signatures.
Sur des sites déjà bien “habitués” aux mises à jour, les signaux typiques ressemblent à ceci :
- Pages qui redirigent vers un autre site, parfois en ne touchant que certains pays ou certains navigateurs. Ajout de JavaScript dans le thème ou dans le footer, surtout du code obfusqué (longues chaînes sans espace, variables “bizarres”, fonctions lambda). Un trafic SEO qui dérape, des pages supplémentaires indexées, ou des intitulés qui apparaissent comme des “portes” sans logique métier. Un administrateur qui n’a pas changé ses réglages, mais qui se retrouve avec des nouveaux comptes, ou des rôles modifiés. Un serveur qui montre une hausse de requêtes vers des endpoints étranges, ou une consommation CPU inhabituelle.
Il y a aussi des cas plus subtils. Un site peut sembler “normal” au premier coup d’œil, mais des fichiers ont été altérés et la charge est déclenchée seulement à la visite (ou seulement après un certain délai). Dans ces situations, tu peux faire une fausse “réparation” en remettant des fichiers identiques, alors que la persistance se trouve ailleurs (base de données, cron WordPress, plugin improbable, fichier indexé mais non exécuté).
Pourquoi une simple restauration ne suffit pas toujours
Restaurer depuis une sauvegarde “d’avant” l’infection est une bonne option, mais elle échoue quand la sauvegarde elle-même est contaminée, ou quand l’attaque a déjà laissé des traces dans la base de données.
J’ai vu des équipes restaurer le dossier wp-content et croire le problème réglé, alors que la base de données contenait encore des options injectées, des utilisateurs créés, ou des schedules WordPress (via WP-Cron) qui rappellent du code malveillant. Résultat : au bout de quelques heures, les symptômes reviennent.
Il faut donc raisonner en couches :
Le code de WordPress et des plugins peut être altéré. Le thème peut être trafiqué, ou des fichiers “assets” peuvent servir de vecteur. La base peut contenir du code, des paramètres, des URL de redirection. Le serveur (ou le compte FTP / SSH) peut être compromis, ce qui veut dire qu’un attaquant réinjecte après coup. Les identifiants peuvent être exposés (ou réutilisés), et l’infection revient par re-login.La bonne stratégie consiste à vérifier ces couches dans un ordre logique, sans partir dans tous les sens.
Identifier la cause : l’entrée, la persistance, l’activation
Je préfère découper l’enquête en trois questions simples, parce que ça évite la confusion.
Par où l’attaquant est entré ?
Les causes les plus fréquentes ne sont pas “magiques” :
- Un compte admin dont le mot de passe était faible, réutilisé, ou protégé par une seule couche d’authentification sans limitation de tentatives. Un plugin ou un thème obsolète avec une faille connue. Une mauvaise hygiène de mise à jour (thèmes “premium” piratés, plugins abandonnés). Une compromission du serveur (accès FTP/SSH avec identifiants volés). Une page d’upload mal configurée, ou un thème/plugin permettant une importation de contenu non filtrée.
Le détail qui change tout, c’est la chronologie : est-ce que le site a été compromis avant une mise à jour, après une installation récente, ou lors d’un incident serveur chez l’hébergeur ? Si tu as un historique d’événements (emails d’alertes, logs, changements), tu peux relier la date.
Comment l’attaquant reste présent ?
L’infection “qui revient” signale presque toujours de la persistance. WordPress est très flexible, donc les attaquants exploitent des points d’ancrage variés :
- Fichiers PHP ajoutés ou modifiés dans wp-content (thème, plugin, parfois des fichiers dans des dossiers inattendus). Modifications dans wp-config.php ou des ajouts indirects qui exécutent du code au chargement. Entrées en base de données qui injectent du code, modifient des options, ou programment des actions via cron. Des comptes admin créés ou des mots de passe modifiés.
Souvent, quand tu regardes l’arborescence, tu vois un fichier qui n’a aucune raison d’être là, ou une modification sur une ligne qui n’a rien à faire dans un fichier de thème.
Quel déclencheur active le code ?
Parfois le code malveillant ne s’exécute que dans des conditions précises :
- Un user agent spécifique. Une plage d’IP. Une langue du navigateur. La présence d’un cookie. Un appel à une page particulière.
Ça explique pourquoi un scan “à froid” ne révèle rien, alors que le site redirige bien en production. Dans l’enquête, je garde toujours une question en tête : le déclencheur est-il lié à une page, une requête, ou un chargement de ressources ?
Préparer l’intervention sans aggraver les choses
Avant de “nettoyer”, je conseille de stabiliser le contexte. C’est là que beaucoup d’interventions échouent, pas sur la technique, mais sur la méthode.
Sur un site en production, je coupe d’abord la propagation et je limite les risques :
- Passe le site en maintenance si possible, ou applique une règle de blocage temporaire au niveau hébergement (si ton plan le permet). Travail sur une copie, idéalement via clonage ou restauration de sauvegarde en environnement de test. Préserve les preuves : captures des pages anormales, relevé des dates, exports de logs si possible. Documente chaque changement, même si ça te paraît “petit”. Quand tu reviens en arrière, tu remercies ton futur toi.
Et surtout, évite de supprimer au hasard des fichiers. Sur un WordPress infecté, supprimer une partie peut casser des mécanismes ou masquer le vecteur. Tu veux diagnostiquer, puis retirer.
Triage rapide : ce que je vérifie dans les premières heures
Si tu veux un repère concret, voici comment je démarre, sans prétendre que c’est “la vérité universelle”. Mais c’est un ordre qui évite généralement les fausses pistes.
- Vérifie les accès récents dans le compte hébergement (FTP/SSH, date de connexion, IP). Liste les plugins et thèmes installés ou mis à jour récemment, et compare la date à celle des symptômes. Contrôle l’intégrité de wp-config.php, des fichiers du thème actif et des éventuels fichiers PHP ajoutés dans wp-content. Consulte les erreurs et logs du serveur (si dispo) pour repérer des requêtes répétitives ou des chemins inhabituels. Réinitialise temporairement la surface d’exposition : mots de passe, et si possible coupe certains utilisateurs ou désactive l’exécution non indispensable.
Cette phase doit te donner un “hypothèse principale”. Ensuite seulement, tu plonges dans les détails.
Repérer le code modifié : où regarder en priorité
La zone la plus fertile dépend du type d’infection, mais dans la pratique, je commence par wp-content et je remonte.
Thème et fichiers PHP
Les injections dans un thème sont fréquentes, parce que le thème s’exécute à chaque chargement. Le plus souvent, tu verras une altération dans un fichier du thème actif, parfois dans functions.php, parfois dans un fichier inclus indirectement.
Le piège classique consiste à lire le fichier rapidement et à ne pas voir la logique. Le code malveillant est parfois “déguisé” en commentaire, ou mélangé à du code légitime. Il peut aussi être compressé ou obfusqué. Ce que je cherche en priorité :
- Une fonction qui fait du base64_decode, des appels à eval, ou une construction dynamique de requêtes. Des file_get_contents, curl, ou des appels réseau vers des domaines non liés au site. Des conditions sur $_SERVER qui déclenchent seulement dans certains cas. Des inclusions (require, include) vers des chemins nouveaux ou bizarres.
Si tu compares avec une version propre du thème, tu gagnes énormément. Même sans avoir le thème d’origine sous la main, tu peux souvent récupérer le thème depuis le dépôt ou le package du vendeur, puis comparer le contenu.
Plugins et fichiers ajoutés
Les plugins sont un autre point de chute. Même si tu supprimes “le plugin” après coup, il peut avoir créé des éléments ailleurs (fichiers dans d’autres dossiers, entrées en base, comptes).
Je regarde aussi les dossiers “inattendus” : un attaquant aime déposer un fichier PHP dans un endroit qui n’est pas censé être exécutable, ou dans un dossier déjà présent pour ne pas attirer l’œil.
wp-config.php et persistance bas niveau
Modifier wp-config.php est plus rare, parce que c’est plus visible. Mais quand ça arrive, le site devient instable ou l’exécution se fait avec un comportement contrôlé par des variables ajoutées.
Même si tu n’y vois pas d’anomalie, vérifie aussi si les secrets de connexion à la base (mot de passe, clés) n’ont pas été touchés. Si l’attaquant a accès à la base, il peut reprogrammer le système.
Détecter l’infection dans la base de données
La base de données est le “cerveau” de WordPress. Un nettoyage de fichiers sans nettoyage SQL est parfois un pansement.
Sans te faire entrer dans des manipulations risquées, je te donne des pistes de contrôle qui se font avec bon sens :
- Options qui stockent du HTML ou du code injection dans la sortie, par exemple via des champs qui influencent le thème. Entrées liées à des redirecteurs, des shortcodes, ou des réglages de plugin. Utilisateurs créés ou rôles modifiés. Planifications cron qui déclenchent des actions périodiques.
Dans l’expérience, quand un site redirige, on retrouve fréquemment des valeurs modifiées dans des options, des champs de plugin, ou des contenus ajoutés dans une page existante. Le code n’est pas toujours dans un fichier PHP.
Un autre signe : tu vois du contenu nouveau dans la médiathèque, dans des pages ou des articles qui ne viennent pas de ta production. Là, il faut corréler avec les créneaux de publication.
Réparer proprement : de la coupure à la reconstruction
Une fois la cause probable identifiée, l’objectif est double : éliminer le code malveillant, et empêcher la réinfection.
La “propreté” dans ce contexte, c’est le fait de revenir à un état connu, cohérent, et de couper les chemins de persistance. Souvent, cela implique plus qu’une suppression. Cela implique une reconstruction raisonnée.
Désactiver et isoler ce qui est suspect
Je commence par désactiver le thème et plugins suspects, mais je le fais intelligemment :
- Désactive uniquement après avoir sauvegardé l’état ou le code suspect, pour conserver la trace. Si un plugin ou le thème est le déclencheur, la désactivation doit faire disparaître la symptomatique. Si la symptomatique persiste, la persistance est probablement ailleurs, base de données ou niveau serveur.
Sur un site où tu ne sais pas ce qui est “normal”, l’isolement évite de détruire l’unique indice.
Remplacer par des versions propres
Quand j’ai une infection avérée, je préfère remplacer les fichiers suspects par une version connue propre, plutôt que de “corriger à la main” des fragments. https://gardewp.fr/nettoyage-malware-wordpress/ Oui, c’est plus long. Mais c’est plus fiable.
Pour le noyau WordPress, la règle est simple : réinstalle les fichiers WordPress “stock” et vérifie que les versions correspondent. Pour les thèmes et plugins : récupère des versions propres depuis leurs sources.
Attention aux thèmes et plugins “custom” : si tu as des modifications légitimes, tu dois faire une comparaison et réappliquer seulement ce qui appartient réellement à ton développement. Sinon, tu perds du travail et tu peux réintroduire une zone infectée.
Nettoyage ciblé des éléments modifiés
Après le remplacement, tu reviens sur ce qui a été réellement altéré. C’est à ce moment que tu supprimes les fichiers ajoutés, nettoies les options injectées et supprimes les comptes créés.
Voici l’ordre de priorité que j’applique en général, parce qu’il limite le risque de réactivation :
- Couper tout compte à risque, puis changer les mots de passe (comptes WordPress et identifiants hébergement si exposés). Remplacer le thème et les plugins suspects par des versions propres, et désactiver ce qui n’est pas indispensable. Corriger la base de données pour retirer code et paramètres malveillants (options, contenus, shortcodes, cron). Vérifier les règles et configurations serveur qui peuvent réinjecter (accès, scripts, tâches planifiées système). Surveiller l’apparition des symptômes après retour en ligne, avant de rouvrir toutes les fonctionnalités.
Les points où on se trompe le plus souvent
Il y a des erreurs récurrentes. Je les mentionne parce qu’elles expliquent pourquoi certaines “réparations” semblent réussir, puis replongent.
1) Remettre les fichiers mais garder la base infectée
Le site peut redevenir “vivant” rapidement, mais les injections peuvent revenir lors d’un événement (publication, cron, ou simple chargement).2) Mettre à jour WordPress sans enlever la persistance
Une mise à jour corrige des failles, mais si l’attaquant a encore un moyen de déposer du code, il peut continuer à s’injecter.3) Changer des mots de passe sans revoir les accès côté hébergeur
Si l’attaquant a gardé un accès FTP ou SSH, il peut réinjecter. Le nettoyage devient alors inutile à court terme.
4) Ignorer un plugin juste “parce qu’il semble ancien mais jamais mis à jour”
Les vieilles installations sont parfois les plus dangereuses. Un plugin oublié qui n’est pas maintenu peut rester exploitable.5) Remplacer un thème custom à l’aveugle
C’est un cas fréquent chez les sites avec un design spécifique. Le bon réflexe est de distinguer l’élément custom de la partie infectée, puis de reconstruire la partie “stock”.Cas typiques et décisions pratiques
Je te donne deux scénarios réels, parce que la décision dépend souvent des symptômes.
Scénario A : redirection et injection de script, côté front
Quand tu vois une page qui charge du JavaScript obfusqué et redirige, j’inspecte d’abord le thème actif, puis les fichiers PHP inclus, puis les options en base liées au thème.
Si la désactivation du thème résout le problème, tu as un indice fort. Si le problème persiste même avec un thème par défaut, alors on bascule vers plugins, base et éventuellement serveur.
Dans ce scénario, j’ai déjà vu des “petits” fichiers PHP ajoutés dans wp-content qui ne font rien au niveau des URLs, mais qui s’exécutent via inclusion depuis le thème. Donc supprimer “le fichier inconnu” ne suffit pas si l’inclusion reste.
Scénario B : comptes utilisateurs créés et réapparition
Si tu te connectes et que tu vois de nouveaux comptes, tu ne fais pas que nettoyer. Tu considères que la surface d’authentification est compromise.
Avant tout, je change les mots de passe, puis je vérifie les journaux d’accès côté hébergement. Ensuite seulement, je reviens sur le code. Sinon, tu nettoies, et l’attaquant recharge, recrée, ou re-modifie.
Dans les incidents de ce type, le vrai indicateur est la rapidité avec laquelle les comptes réapparaissent après nettoyage.
Durcir après réparation : empêcher la prochaine infection
Le nettoyage est la partie visible. La prévention demande plus de rigueur, mais c’est là que tu gagnes le plus de temps à long terme.
Je recommande un durcissement progressif, sans basculer dans des mesures qui cassent l’exploitation du site.
- Active une authentification forte pour la connexion WordPress (au minimum un second facteur, si ton hébergeur ou ton plugin l’offre). Mets à jour thèmes, plugins, et WordPress dès que possible, en évitant de garder un plugin abandonné. Réduis le nombre de plugins actifs. Un plugin non utilisé est un risque non nécessaire. Utilise des mots de passe uniques et suffisamment longs, et évite les partages. Surveille les événements : créations d’utilisateurs, changement de rôle, mises à jour effectuées, et anomalies de trafic.
Si tu as déjà subi une infection, je te conseille aussi d’aligner ton système de sauvegarde : sauvegardes fréquentes, test de restauration en environnement de préproduction, et conservation d’au moins plusieurs versions datées.
Éléments de preuve : comment savoir quand c’est vraiment fini
La vraie question, c’est “à partir de quand je considère le site sain ?”. Je ne me base pas sur un seul test.
Je valide en trois niveaux :
1) Symptômes front disparus
Plus de redirection, plus de scripts inattendus, pages qui répondent normalement.2) Intégrité des composants
Fichiers WordPress, thème et plugins alignés sur des versions propres. Pas de PHP “fantôme”.3) Stabilité après période d’observation
Je surveille pendant au moins quelques heures après retour en ligne, parfois une journée si des déclencheurs sont conditionnels ou liés au cron.Si l’infection revient rapidement, il y a presque toujours une persistance dans la chaîne (accès hébergement, tâche planifiée, base non purgée, fichier encore inclus).
Quand il vaut mieux confier à un spécialiste
Il existe des situations où le temps n’est pas ton allié :
- Site avec beaucoup de personnalisation custom, impossible à comparer rapidement. Accès serveur incertain (hébergement mutualisé où tu n’as pas les outils, ou logs limités). Infection avec comportement très conditionnel difficile à reproduire. Indices d’accès compromis répété côté serveur.
Dans ces cas, un prestataire ou un expert sécurité peut apporter un vrai gain de temps, surtout parce qu’il sait quoi chercher et comment vérifier l’absence de persistance.
Cela dit, même si tu fais intervenir quelqu’un, tu peux préparer la matière en amont : dates, changements récents, symptômes précis, captures, et sauvegardes.
Réflexe final : penser “cause” avant “nettoyage”
Le nettoyage fichiers infectés WordPress réussi n’est pas celui où tu supprimes ce que tu vois. C’est celui où tu identifie l’origine, puis tu coupes les mécanismes qui permettent à l’intrus de revenir.
Si tu veux retenir une idée simple : commence par diagnostiquer l’entrée et la persistance, remplace par des versions propres, puis purge la base et durcis l’accès. C’est plus méthodique que “tout réinstaller”, mais c’est aussi ce qui réduit le risque de répétition.
Si tu me décris les symptômes exacts (redirection, code injecté, création d’utilisateurs, date d’apparition, plugins récemment ajoutés), je peux t’aider à établir une hypothèse plus précise sur la cause la plus probable et sur l’ordre des contrôles à faire.