Un site WordPress piraté, ce n’est pas seulement une page blanche et un message “vous n’avez plus d’accès”. Le cas qui revient le plus souvent sur les sites “qui marchent quand même”, c’est l’injection discrète. Le visiteur ne voit rien d’évident, mais le site injecte du code au moment où la page se ferme, souvent dans le footer. Parfois ce sont des scripts d’affiliation ou des redirections, parfois des chargements de ressources malveillantes, parfois des iframes invisibles. Et le plus piégeux, c’est que les fichiers “sensibles” peuvent rester propres, pendant qu’un détail côté thème ou côté fichiers inclus fait tout le travail.
Le nettoyage des fichiers infectés WordPress commence donc rarement par “supprimer tout et réinstaller tout”. Ça commence par comprendre où l’injection se cache, comment elle s’active, et pourquoi elle survit aux premiers nettoyages.
Le footer, zone de confort pour les injections
Le footer est l’endroit où WordPress termine généralement l’affichage HTML. Beaucoup de thèmes y placent du JavaScript, des trackers, des fonds de page, parfois des scripts de performance. Pour un attaquant, c’est pratique: le code s’exécute une fois le contenu rendu, ce qui réduit la probabilité que l’injection casse la mise en page.
Autre avantage, le footer est souvent moins “scruté” que l’en-tête ou les templates principaux. En interne, quand on audite un incident, on regarde d’abord les fichiers du thème, les templates, et les plugins. Puis on vérifie la page en inspection navigateur, et quand on voit un chargement réseau suspect en bas de page, on remonte au bon endroit.
Dans les injections, on retrouve souvent des caractéristiques similaires:
- du code minifié ou chiffré qui se décode au chargement, une condition déclenchée par l’agent utilisateur, le pays, ou le referrer, un ajout tardif de script, par exemple via document.write, innerHTML, ou insertion dynamique dans le DOM, une commande qui semble “inoffensive” à la lecture, mais qui déclenche un chargement vers une URL externe au moment où la page est prête.
Ce sont ces patterns qui guident la détection, avant même d’ouvrir un éditeur.
Comment reconnaître une injection dans le footer (sans se raconter d’histoires)
J’ai vu plusieurs cas où l’équipe pensait avoir “un virus sur le serveur”. En réalité, le serveur exécutait un code propre, mais le thème ou un fichier inclus injectait une portion de script. C’est là que l’observation devient un réflexe.
La première étape, c’est d’observer l’exécution côté navigateur. Ouvrez la page, puis inspectez:
- le HTML final, pour repérer un fragment ajouté après le contenu “normal”, l’onglet Réseau (Network) pour voir si des scripts sont chargés alors qu’ils ne font pas partie de votre liste attendue, la console pour des erreurs qui n’existent pas d’habitude (certains malwares se taisent, d’autres crient).
Quand l’injection est réelle, vous verrez souvent un chargement vers un domaine qui n’est ni celui de votre stack habituelle, ni vos outils marketing connus, ni vos services de CDN. La difficulté, c’est que le domaine peut être “proche” de la vraie marque (typosquatting) ou utiliser des noms courts très banals.
Ensuite, il faut corréler le timing. Si l’appel réseau “suspect” apparaît systématiquement au moment du chargement du footer, ou juste après l’exécution des scripts du thème, c’est un indice solide.
Voici les signes qui m’ont le plus aidé dans des incidents concrets:
- un script ou une iframe apparaît uniquement sur certaines pages, par exemple les articles ou la page d’accueil; les sources réseau changent selon l’origine de la requête, comme si le contenu s’adaptait au visiteur; le code dans le footer ressemble à un bloc chiffré, parfois sur une seule ligne, parfois dans un fichier qui n’est pas censé contenir du PHP; la charge réseau augmente le temps de chargement, avec des requêtes répétées ou des redirections en chaîne; le contenu HTML final inclut des segments qui ne sont pas générés par votre thème “standard” (surtout si vous avez l’habitude de le voir).
Ces signes ne remplacent pas la preuve, mais ils évitent de courir partout au hasard.
Cartographier le chemin d’exécution côté WordPress
Une injection dans le footer n’est pas forcément “dans un fichier nommé footer”. WordPress assemble l’affichage via des hooks, des templates, et parfois des https://gardewp.fr/nettoyage-malware-wordpress/ fonctions ajoutées par un thème ou un plugin. Un attaquant peut viser:
- le fichier template du thème (par exemple footer.php), un fichier d’inclusion du thème (par exemple functions.php ou un inc/*), une surcharge via un hook, par exemple wp_footer, ou même un plugin caché dans la hiérarchie, qui accroche un callback sur wp_footer.
Donc, même si votre suspicion pointe vers le footer, la logique doit rester orientée “hook”. C’est souvent là que tout se joue.
Dans la pratique, je fais une vérification en deux temps:
Identifier où WordPress exécute le footer pour cette page précise. Repérer quel hook ajoute la portion de code suspect.Selon votre niveau d’accès et le type de thème, vous pouvez déjà deviner une partie. Les thèmes classiques appellent wp_footer() dans footer.php. Les constructeurs de thèmes et les thèmes bloc peuvent aussi injecter autrement. Mais le hook wp_footer est fréquent, donc c’est un bon point de départ.
Sans entrer dans des méthodes trop intrusives, l’idée est de retrouver la trace de l’injection dans le runtime: quel code s’est ajouté à ce moment là.
Première passe de tri: plugins, thème, et fichiers modifiés
Avant de supprimer quoi que ce soit, je fais un tri “propre” des fichiers. L’objectif est de réduire le champ, pas d’effacer à l’aveugle.
Le piège classique, c’est de constater que le code suspect est dans le thème, puis de conclure que les plugins sont innocents, ou l’inverse. En réalité, un plugin peut ajouter un hook dans le footer, et un autre fichier du thème peut déclencher un include qui charge du code malveillant.
Sur un incident réel, j’ai eu deux symptômes en apparence contradictoires: l’injection se voyait dans le footer, mais l’outil de comparaison indiquait que c’était une ressource côté plugin qui changeait. Le footer n’était que la scène de l’événement.
Voici comment je procède pour trier efficacement:
- comparer les fichiers modifiés récemment (date de modification) avec votre cadence normale de maintenance; vérifier l’intégrité des fichiers de thème et des plugins, surtout les fichiers qui ne bougent jamais en temps normal; regarder le “contenu” des fichiers, pas seulement leurs dates: certains malwares copient un petit bloc de code dans un fichier banal, et la modification date peut être trompeuse.
Si vous avez accès à un historique via Git, c’est le moment de l’utiliser. Sinon, une comparaison sur une base “ancienne connue” ou sur une version saine est précieuse.
Où chercher exactement quand le footer est compromis
Quand je dis “détecter les injections dans le footer”, je ne parle pas uniquement de footer.php. Je parle de toute la chaîne de génération du markup final.
Les zones qui reviennent souvent:
- wp_footer() et les callbacks attachés à wp_footer via des actions, functions.php dans le thème actif, surtout si un fichier annexe est inclus à la volée, des fichiers situés dans inc/, includes/, ou des sous-dossiers “helper” du thème, des fichiers de plugin, même si le plugin ne fait rien d’autre que charger un hook, des fichiers ajoutés ou renommés dans des emplacements inattendus, par exemple dans des dossiers créés récemment.
Dans certains cas, le code injecté est visible directement dans le HTML final, et dans d’autres, il ne l’est pas. On voit alors uniquement les effets: un script chargé, une redirection, ou un iframe. Le fichier responsable peut rester discret, et le code n’apparaître qu’au moment de l’exécution.
C’est pour ça qu’un simple “Ctrl+F footer.php” ne suffit pas toujours.
Une méthode de détection pragmatique, reproduite plusieurs fois
L’idée est de passer du “je pense que” au “je peux prouver”. Vous pouvez faire ça sans outils complexes, même si des outils d’analyse peuvent accélérer.
Je commence par préparer un environnement d’observation. Idéalement, je teste sur une URL qui reproduit l’injection systématiquement. Ensuite:
- j’ouvre la page en navigateur, je repère le script ou la requête suspecte dans le Network, je copie l’extrait du code qui apparaît dans le DOM final ou dans la source de la page.
Ensuite, je remonte. Parfois l’extrait contient un identifiant unique, une chaîne de caractères, un nom de fonction, ou un URL. Je cherche cette chaîne dans les fichiers du thème actif, puis dans les plugins actifs, et seulement après dans les dossiers moins probables.
La recherche de chaîne est sous-estimée. Beaucoup de malwares laissent des marqueurs, parce que leurs auteurs ne pensent pas que l’on va inspecter le runtime.
Ce que je fais aussi, c’est vérifier les conditionnelles. Si le code suspect s’exécute uniquement pour certains visiteurs, il se peut que vous ne le voyiez pas toujours au premier essai. Dans ce cas, je teste depuis des navigateurs différents, ou je change l’URL d’arrivée (paramètres, pages cibles). Oui, c’est un peu fastidieux, mais ça évite de nettoyer le mauvais morceau.
Nettoyage des fichiers infectés WordPress: choisir une approche qui ne réinfecte pas
Le nettoyage doit être doublé d’une stratégie anti-retour. Sinon, vous supprimez le symptôme, puis l’injection revient dès que quelqu’un redépose du code, souvent via un processus automatisé ou via une autre porte d’entrée.
La meilleure approche dépend de votre situation: vous avez un site simple ou complexe, plusieurs plugins, un thème custom, et surtout, vous avez ou non une sauvegarde saine.
Voici ce que j’envisage en pratique, dans quel ordre.
Corriger la compromission d’accès: comptes utilisateurs, rôles, clés, plugins qui font des imports, thèmes récents installés “par surprise”. Supprimer la persistance: fichiers injectés, scripts ajoutés, hooks déposés, mu-plugins si présents. Vérifier l’intégrité: comparer thème et plugins à une source saine. Surveiller: logs d’erreurs, demandes réseau anormales, et comportement sur un petit jeu de pages.La logique est simple: on ne nettoie pas un footer compromis en espérant que “ce sera bon”, on coupe les mécanismes qui réinjectent.
Premier plan d’action (rapide, mais cadré)
Voici une check-list courte que j’utilise quand il faut gagner du temps, sans sauter les étapes de contrôle.
- Changer immédiatement les mots de passe des comptes administrateurs et vérifier les utilisateurs “créés récemment”. Désactiver tous les plugins actifs, puis réactiver un par un pour identifier l’origine de l’injection. Remplacer le thème actif par une version saine (si possible en copiant un thème équivalent ou via un déploiement de référence). Rechercher dans les fichiers thème et plugins les chaînes visibles dans l’extrait suspect (URL, identifiant, fragment de code). Une fois corrigé, tester plusieurs pages et vérifier via le Network l’absence des requêtes externes liées à l’injection.
Cette approche n’est pas parfaite pour tous les cas, mais elle évite le scénario le plus fréquent: nettoyer le thème, sans traiter le plugin qui a posé le hook.
Cas fréquents d’injection dans le footer, et comment les reconnaître
Les méthodes exactes varient, mais les mécanismes reviennent souvent. La partie la plus utile, c’est de reconnaître les patterns, pour éviter de supprimer le mauvais fichier.
Injection via hook wp_footer
Le cas classique: un callback est ajouté à wp_footer, souvent dans functions.php ou dans un fichier de plugin. Le callback ajoute du script minifié ou une iframe. Le footer devient une sorte de “livraison”.
Si vous repérez une fonction inconnue dans votre thème ou un plugin, avec un bloc de code qui manipule le DOM ou ajoute des scripts, c’est un candidat très fort.
Injection via inclusion conditionnelle
Parfois, le code n’est pas dans footer.php, mais dans un fichier inclus par le thème. Par exemple, functions.php charge un fichier selon une condition liée à la requête, comme une page spécifique. Ensuite, le code injecte seulement dans certains templates, ce qui rend la reproduction variable.
Dans ces situations, vous pouvez avoir l’impression que “le footer n’est pas modifié”, car footer.php est intact, mais le rendu final inclut quand même le contenu.
Injection via base de données
Plus rare dans les sites “thèmes simples”, mais possible: un champ de la base de données, comme un option, un meta, ou un bloc, contient du code qui est réinjecté au rendu. Si votre thème insère du contenu dynamique dans le footer, et que la source vient de la base, l’injection peut survivre à un remplacement de fichiers.
Si vous voyez l’injection sans qu’aucun fichier ne corresponde à la chaîne trouvée dans le HTML final, pensez à la base. Dans ce cas, l’audit doit inclure les options et contenus stockés, pas uniquement les fichiers.
Se protéger pendant le nettoyage: compromis et précautions
Il y a un point que je vois régulièrement mal géré: le nettoyage en prod sans filet. Supprimer un hook au hasard peut casser le thème, supprimer une option peut casser un plugin, et remplacer un thème peut invalider une personnalisation.
Donc je recommande d’agir avec une logique de sécurité:
- testez d’abord sur une copie si possible; si vous n’avez pas de copie, documentez au fur et à mesure les fichiers touchés; privilégiez la comparaison avec une version saine plutôt que la suppression manuelle au kilomètre.
Quand on parle de “nettoyage fichiers infectés WordPress”, il faut aussi accepter que la perfection n’existe pas. Ce qui compte, c’est la maîtrise du risque.
Par exemple, si vous supprimez un fichier suspect dans le thème mais que la persistance vient d’un hook déposé ailleurs, vous aurez supprimé la symptomatique. Le site peut recommencer à injecter le footer au prochain rendu, ou dès qu’un cron ou un processus de plugin se déclenche.
Le bon niveau d’effort n’est pas maximal, il est ciblé.
Détection approfondie: remonter depuis l’extrait
Quand vous avez un fragment de code suspect visible dans la page, le travail devient beaucoup plus rationnel.
Je procède en trois couches:
- recherche de chaînes exactes dans le dossier du thème et dans le dossier des plugins, recherche de variables et noms de fonctions, même si le code est minifié, inspection des fichiers qui utilisent les hooks du footer, en regardant qui appelle quoi.
C’est parfois frustrant: le code malveillant peut être une chaîne chiffrée qui ne donne rien à la recherche. Mais même alors, il laisse souvent des indices, comme un nom de fichier inclus, un URL de destination, un nom de domaine, ou un identifiant utilisé dans une requête.
Quand la recherche échoue, je change de stratégie: j’observe de nouveau le Network pour capturer un domaine ou une URL complète, puis je recherche ce domaine dans le code.
Cette méthode est très efficace parce qu’elle se base sur un comportement prouvé, pas sur une intuition.
Vérifications finales, sinon vous repartez à zéro
Après nettoyage, le “travail fini” n’arrive pas au premier test. J’ai vu des injections déclenchées après un certain temps, après un nombre de visites, ou sur une page précise. Donc je vérifie au moins:
- le rendu de plusieurs pages types, pas seulement la page d’accueil, la présence ou non de requêtes externes suspectes dans le Network, l’absence de nouveaux fichiers modifiés depuis le dernier nettoyage, la stabilité des plugins essentiels.
Si votre site dépend d’un CDN ou de scripts tiers légitimes, faites attention aux faux positifs. Certaines plateformes lancent des scripts au moment du footer et ça peut ressembler à une injection au premier regard. La clé est de comparer avec votre “normal”.
Un bon test, c’est d’avoir une liste mentale de vos acteurs habituels: analytics, consentement, CDN, cache, chat, formulaires. Tout ce qui arrive sans être dans cette liste, et surtout si c’est invisible à la surface, mérite enquête.
Et si vous ne pouvez pas identifier le responsable du premier coup ?
Ça arrive. Parfois l’injection est partagée entre plusieurs éléments, et le site est si modifié qu’on ne sait plus ce qui est “custom” et ce qui est “parasite”.
Dans ces cas, j’ai deux options qui ont sauvé des heures:
- repartir d’un thème propre, puis réintégrer vos modifications une par une plutôt que de réparer un thème “à moitié cassé”; reconstruire le site depuis une sauvegarde saine, en réappliquant uniquement le nécessaire (thème, contenu, paramètres), puis recontrôler les hooks et les fichiers.
Ces choix sont coûteux, mais ils sont parfois plus rapides que de “poursuivre un fantôme” dans un site qui a accumulé des modifications au fil des années.
Le critère décisif, c’est votre niveau de confiance dans l’historique et dans la sauvegarde.
Une dernière chose: réduire la probabilité que le footer soit réinfecté
Le nettoyage n’est pas seulement une opération technique, c’est aussi un changement d’hygiène.
Je ne vais pas vous vendre une seule stratégie miracle. Sur les sites WordPress, les réinfections viennent souvent de:
- comptes compromis, plugins obsolètes, thèmes non à jour ou thèmes custom sans contrôle d’intégrité, permissions trop larges côté fichiers, absence de surveillance.
Si vous voulez que votre prochaine “détection injection footer” arrive plus tôt, mettez en place une routine simple: contrôler les fichiers modifiés, limiter les droits, et surveiller les changements de plugins et de thèmes.
C’est moins spectaculaire que de supprimer du code, mais c’est ce qui empêche l’injection d’être “rééditée” à chaque cycle.
Recadrer le diagnostic quand “le footer semble infecté”
Le point le plus important, quand vous faites du nettoyage fichiers infectés WordPress, c’est de garder un cadre: le footer est souvent la sortie, pas forcément l’entrée. Votre objectif est de trouver l’endroit où le code est ajouté, pas seulement celui où il s’affiche.
Quand l’injection est localisée au footer, vous pouvez gagner un temps énorme en liant trois observations: l’extrait visible dans le HTML final (ou l’effet dans le Network), la logique WordPress des hooks et des templates, et l’évolution récente des fichiers thème et plugins.
C’est ce trio qui transforme un incident stressant en enquête maîtrisée, et qui fait que vous ne recommencez pas le même nettoyage deux semaines plus tard.