Sur WordPress, l’infection ne se cache pas toujours dans les fichiers PHP. Parfois, elle se glisse dans des éléments “mécaniques” et très visibles de votre site, comme les pages statiques, les fichiers templates, ou des contenus stockés là où vous ne regardez pas en premier. Le résultat est souvent frustrant: une page a l’air normale au premier coup d’œil, puis on découvre un comportement bizarre, une redirection silencieuse, du code injecté dans le HTML, ou des liens frauduleux qui n’ont rien à faire là.
Ce qui complique les choses, c’est que les pages statiques semblent simples. En réalité, elles reposent sur tout un chaînage: thèmes, modèles, shortcodes, plugins, scripts, mises en cache, CDN, et même certaines habitudes de publication (copier-coller depuis Word, import via un plugin, restauration de snapshot, etc.). Quand une infection se loge dans une “page”, elle peut venir d’un contenu injecté, d’un gabarit contaminé, ou d’un fichier de thème modifié.
Je vous propose une méthode de repérage centrée sur les pages statiques, avec une logique de terrain: observer les symptômes, retrouver la surface d’attaque, comparer le HTML, analyser les différences, et surtout distinguer l’attaque réelle de la simple “trace” laissée par un plugin ou un cache.
Pourquoi les pages statiques sont une porte d’entrée fréquente
Une page statique WordPress n’est pas forcément une page “simple” au sens technique. Souvent, elle affiche un template de thème (par exemple page.php, des templates nommés, ou des composants chargés via un constructeur). Même si l’éditeur WordPress vous montre un contenu propre, le rendu final est assemblé au runtime.
Quand une intrusion vise le SEO ou la conversion, elle cherche des points où elle peut injecter rapidement du HTML ou des scripts. Une page qui attire du trafic, une page “À propos”, “Mentions”, “Contact”, ou une page de vente figée est un bon candidat. Ce sont des pages stables, souvent peu modifiées par les équipes. Elles sont aussi parfois “pré-cachées” en production, ce qui masque la modification le temps de la détection.
J’ai déjà vu un cas typique: une entreprise reçoit des alertes “liens sortants inhabituels”. La page d’accueil était saine, la console de recherche aussi, mais une page statique “Ressources” affichait une zone qui n’existait pas la veille. En inspectant le code, on a trouvé un bloc script inséré au moment du rendu, avec une logique conditionnelle du style “si l’user-agent correspond à X, injecter Y”. Le contenu visible restait presque identique, mais le HTML final ne mentait pas.
Les symptômes qui orientent vers une infection côté HTML
Avant de “nettoyer fichiers infectés WordPress”, il faut confirmer le type de compromission. Si vous partez directement en suppression aveugle, vous risquez de casser un thème ou de perdre des contenus légitimes.
Voici des symptômes qui reviennent souvent quand l’injection se manifeste dans les pages statiques:
- Des redirections qui n’ont pas de logique apparente, par exemple une page qui redirige uniquement pour certains pays ou certains navigateurs. Des éléments invisibles qui apparaissent dans le DOM, style “div” ou “script” ajoutés en fin de page, ou dans le head. Des liens externes qui changent sans que le contenu WordPress ne le montre (souvent dans des scripts, pas dans l’éditeur). Des anomalies de chargement, comme des requêtes vers des domaines inconnus juste après le chargement initial. Une différence entre le HTML “vu” dans votre navigateur et le contenu “source” attendu, ou entre deux environnements (staging sain, production infectée).
Le repérage se fait surtout au niveau de la réponse HTTP et du HTML final, pas au niveau du contenu édité. WordPress peut enregistrer un texte propre, tandis que le thème ou un fichier de template injecte ailleurs.
Ce que vous devez vérifier en premier, sans outillage lourd
Avant d’ouvrir un terminal et de lancer des scans, faites une observation structurée. Le but est de réduire le périmètre.
1) Choisissez une page statique “suspecte”
Prenez une page qui présente le problème de façon répétable. Si vous avez plusieurs pages, commencez par celle qui “échoue” le plus souvent.2) Comparez HTML rendu et HTML attendu
3) Regardez le head et la fin du body
Les injections malveillantes aiment se placer dans le head (scripts, iframe dissimulés, balises meta) ou tout à la fin du body (chargement conditionnel, scripts qui exécutent une redirection).4) Vérifiez les ressources réseau
Dans l’onglet Réseau des outils développeur, identifiez les requêtes vers des domaines qui ne font pas partie de votre stack normale. Quand on voit des appels vers un domaine inconnu, on tient un fil.Cette étape peut sembler “simple”, mais elle produit souvent un signal clair: la page statique affiche bien du code injecté dans le HTML final, donc l’infection touche probablement le thème, un fichier de template, un fragment de rendu, ou un script chargé par la page.
Comprendre le chemin de rendu: où l’injection peut se cacher
Une page statique WordPress traverse plusieurs couches. Si vous ne voulez pas vous perdre, pensez en “points d’injection”.
- Le template de page: page.php, templates spécifiques, fonctions du thème qui assemblent les blocs. Les hooks et filtres: un plugin ou un code ajouté sur un hook peut modifier le contenu final. Les fragments injectés via shortcodes: parfois, un shortcode “légitime” est détourné. Les contenus stockés: le contenu enregistré dans la base peut contenir du HTML malveillant (souvent via un champ d’éditeur, parfois via des shortcodes). La couche de cache: la page servie peut être celle d’un cache qui conserve une injection même après correction partielle.
Le repérage devient efficace quand vous reliez un symptôme à un type de modification probable. Par exemple, si l’injection apparaît uniquement sur la page de ressources et jamais sur le reste, le thème ou un template dédié est un suspect sérieux. Si l’injection touche toutes les pages, c’est plutôt côté fichier global du thème, plugin, ou un mécanisme sur un hook.
Méthode de comparaison: distinguer le “contenu” de la “sortie”
C’est souvent là que le diagnostic bascule. Beaucoup de gens regardent l’éditeur WordPress, copient le texte, et concluent que tout est propre. Pourtant, une infection peut se limiter à la sortie HTML.
Faites une comparaison entre:
- Le HTML de la page infectée dans votre navigateur (source ou DOM) Le HTML de la même page sur un environnement sain (si vous avez un staging propre), ou sur une version précédente sauvegardée Le HTML de la page infectée après désactivation temporaire du cache (si vous utilisez un plugin de cache, ou un CDN)
Sans chercher à tout automatiser, l’idée est de relever précisément ce qui change. Si l’écart est un bloc script, vous cherchez une source dans le thème ou un fichier chargé. Si l’écart concerne une section HTML insérée dans le contenu, vous inspectez le contenu stocké et les shortcodes.
Dans un incident récent que j’ai traité, la page statique “FAQ” avait un rendu identique à l’œil nu, mais le code source révélait une balise script ajoutée juste après un bloc FAQ. Le contenu WordPress affichait un texte propre. En comparant la sortie, on a remarqué que la balise apparaissait toujours au même endroit, comme si un hook ajoutait un fragment. Cela a orienté l’analyse vers le thème, puis vers un fichier inclus conditionnel.
Comment repérer une injection dans les pages statiques, concrètement
À ce stade, vous avez soit une idée du type d’injection (script, iframe, lien), soit au moins la zone du DOM où ça se produit.
Voici une approche pragmatique, basée sur l’observation et la vérification de cohérence. Elle s’applique bien à la logique “nettoyage fichiers infectés WordPress : repérer l’infection dans les pages statiques”.
1) Identifiez le marqueur: un bout de code constant
Cherchez un identifiant stable dans l’injection. Par exemple:
- Un nom de fonction étrange, une chaîne de caractères longue, un nom de fichier utilisé par le script Un domaine externe qu’on retrouve dans les requêtes Un attribut style ou class inhabituel
Le marqueur sert de boussole. Sans marqueur, vous naviguez à vue.
2) Recherchez ce marqueur dans votre WordPress
Ensuite, faites une recherche dans le code source du site. L’objectif n’est pas de tout supprimer immédiatement. L’objectif est de trouver “où” le marqueur est produit.
Sur un WordPress compromis, le marqueur est souvent présent dans un fichier de thème, un fichier PHP dans wp-content, ou dans un script chargé par le rendu de page. Il peut aussi être encodé, compressé, ou récupéré dynamiquement depuis un endpoint.
Faites attention aux faux positifs. Un nom de domaine peut exister légitimement si vous utilisez un outil marketing ou un tag management. La clé est de voir si le script injecté correspond au marqueur que vous avez trouvé dans le HTML final.
3) Faites le lien avec les templates
Si votre marqueur ne se trouve pas dans les fichiers globaux, cherchez dans les templates utilisés par les pages statiques. Si votre thème utilise un fichier spécifique pour certaines pages, c’est un lieu logique de contamination.
Un signe qui trompe souvent: vous ouvrez le fichier page.php, vous ne trouvez rien, et vous vous dites que “donc ce n’est pas le thème”. Mais l’injection peut être dans un fichier inclus depuis page.php, dans une fonction du thème, ou dans un script local chargé par template part.
4) Vérifiez la base de données pour les contenus suspectés
Si le HTML injecté est directement une partie du contenu, le marqueur peut être enregistré dans la base. Selon votre thème et vos plugins, ce n’est pas toujours dans le champ “post_content” de la page. Parfois, c’est dans des custom fields, des champs de builder, ou des variables enregistrées par le constructeur.
En pratique, je procède souvent comme ceci: je prends un extrait court du marqueur, je le recherche dans la base (sur la table qui stocke les contenus). Si je trouve une occurrence dans la page concernée, je sais que le nettoyage doit inclure la réinitialisation du contenu ou la suppression d’un fragment.
Les pièges classiques lors du repérage
Même une analyse solide peut être perturbée par des comportements légitimes.
Cache, CDN et minification: la page “ment”
Un cache peut servir un ancien rendu infecté pendant un moment, même après correction. Un CDN peut aussi conserver la version en cache. Si vous modifiez le code et que vous ne voyez rien changer immédiatement, ne concluez pas trop vite.
La vérification utile, c’est de tester sans cache, au moins pour un ou deux cycles. Si le problème disparaît, vous aviez un conflit de couche. Si le problème persiste, vous êtes probablement face à une injection persistante.
Plugins de tracking: confondre légitime et malveillant
Des plugins marketing insèrent des scripts et des tags. Ce n’est pas automatiquement mal. Par contre, quand vous voyez un domaine inconnu, un script chargé depuis un endroit “non prévu”, ou une logique conditionnelle non documentée, vous avez un signal.
Une règle de terrain: si vous ne pouvez pas expliquer pourquoi ce script est là, et que vous n’en voyez pas la trace dans vos réglages (ou dans vos fichiers de configuration), traitez-le comme suspect jusqu’à preuve du contraire.
Pages “statiques” via des shortcodes ou des builders
Beaucoup de pages statiques sont construites avec un builder. Une infection peut s’être glissée via un module de builder, une zone de texte, ou un champ de code HTML.
Dans ces cas, l’éditeur WordPress peut afficher “propre” tant que vous ne voyez pas la source du champ. Selon l’outil, un mode “texte” ou “code” révèle ce qui est réellement stocké.
Nettoyage: quoi faire une fois l’endroit identifié
Le repérage est une étape, le nettoyage en est une autre. Le bon sens consiste à agir “à la source”, et à éviter les réparations cosmétiques.
Quand l’infection se trouve dans des pages statiques, le nettoyage revient généralement à l’une de ces options:
- Supprimer ou restaurer un fichier de thème ou un template modifié Corriger un shortcode ou une fonction de thème qui injecte le code Purger un contenu malveillant dans la page concernée Rétablir le cache et vérifier que l’injection a disparu réellement
Le point important: après un nettoyage partiel, il faut vérifier le rendu côté navigateur, pas seulement le contenu côté WordPress.
Dans le monde réel, j’ai déjà vu une équipe supprimer un fichier, puis constater que la page reste infectée. En fouillant plus loin, on a découvert qu’un autre fichier inclus, plus discret, était resté modifié, ou qu’un plugin placé “dans l’ombre” injectait le code via un hook. Le symptôme survivait parce que le mécanisme de rendu n’avait pas été entièrement neutralisé.
Une check-list courte pour valider que vous ciblez la bonne zone
Si vous voulez une méthode de travail qui évite de courir dans tous les sens, voici une check-list de repérage, centrée sur vos pages statiques. Elle fait gagner du temps quand l’infection n’est pas évidente.
- Repérez un marqueur constant dans le HTML final (script, domaine, fonction, chaîne). Testez au moins une fois avec cache désactivé (plugin de cache et CDN si possible). Comparez la page suspecte à une page similaire saine (même template ou même type). Cherchez le marqueur dans le code du thème et des fichiers inclus par les templates. Si le marqueur vient du contenu, recherchez-le aussi dans la base de données pour la page.
Cette séquence évite la tentation de “nettoyer fichiers infectés WordPress” sans preuve localisée. Une infection se nettoie mieux quand vous savez ce qu’elle fait, pas seulement quand vous savez qu’elle existe.
Cas d’école: injection dans un template de page
Prenons un scénario fréquent. Vous observez que la page “À propos” affiche parfois une redirection. En inspectant le code source, vous constatez un script injecté à la fin du body, avec une condition “si l’URL contient telle structure”. Vous cherchez ensuite ce script dans le thème.
Vous trouvez une fonction dans un fichier du thème, appelée par un hook global. Elle s’exécute à chaque chargement de page, mais n’injecte le bloc que pour certaines slugs. Ce détail explique pourquoi certaines pages statiques sont touchées, mais pas toutes.
Le nettoyage, dans ce cas, ne consiste pas à retirer seulement le script depuis le HTML rendu. Il faut:
- Restaurer la version saine du fichier de thème concerné Supprimer les ajouts sur les hooks Vérifier que le fichier n’a pas été recréé, par exemple via un déploiement automatisé compromis
Ce genre d’injection “ciblée par slug” est difficile à deviner sans inspection du HTML final.
Cas d’école: contenu malveillant dans une page statique (et pourquoi l’éditeur vous trompe)
Autre scénario. Vous ne voyez pas de scripts dans le thème. Pourtant, le HTML final contient du contenu injecté, par exemple un bloc texte avec des liens vers des sites douteux, ou une iframe cachée.
En inspectant la page côté WordPress, vous copiez le contenu depuis l’éditeur et il semble normal. C’est là qu’un mode d’édition “code source” fait la différence. Certains builders ou certains nettoyeurs de contenu affichent une version “transformée”. Le HTML stocké peut contenir des éléments que le rendu masque.
Si vous trouvez une portion suspecte dans la base de données, le nettoyage est souvent plus direct, mais exige de vérifier les champs annexes. Une page statique peut contenir un bloc dans le post_content, mais aussi des données de builder dans des champs spécifiques, ou des shortcodes enregistrés en tant que texte.
Sécuriser après le nettoyage: éviter la récidive
Même quand le repérage est bon et que vous restaurez le bon fichier, une infection peut revenir si l’accès n’a pas été sécurisé. Ce n’est pas un détail. Le “nettoyage” n’est pas seulement une question technique, c’est une question de retour d’expérience.
Après correction, je recommande de vérifier:
- Les comptes utilisateurs et les rôles. Une intrusion passe rarement sans laisser une porte ouverte. Les plugins récemment installés ou mis à jour au moment où le problème a commencé. La présence de fichiers inattendus dans wp-content (surtout des scripts ou des dossiers ajoutés). Les tâches planifiées (cron) et les hooks ajoutés par un plugin compromis.
Je ne donne pas une liste de nettoyage exhaustive ici, car vous pouvez avoir des contraintes d’infrastructure (staging, procédure de déploiement, politique de sécurité interne). Mais la logique reste la même: si le vecteur d’entrée n’est pas neutralisé, les pages statiques seront revisitées encore et encore.
Voici une mini liste de vérification post-traitement, orientée récidive:
- Désactiver temporairement les plugins non essentiels pendant les tests. Vérifier que les fichiers du thème et des templates n’ont pas été modifiés à nouveau. Contrôler les domaines et scripts chargés par les pages suspectes après purge cache.
Comment savoir si c’est “terminé” sur vos pages statiques
Le piège final, c’est de penser que “c’est bon” parce que la page s’affiche correctement. Une infection peut persister mais être conditionnelle. Elle peut toucher un sous-ensemble d’utilisateurs, ou fonctionner seulement quand certaines requêtes réseau sont autorisées.
Pour confirmer, testez la page dans des conditions différentes. Les plus utiles sont souvent:
- Fenêtre privée sans cookies Navigation sur un réseau différent Comparaison de source HTML entre l’état après nettoyage et une capture d’avant Vérification des requêtes réseau vers l’extérieur
Si vous utilisez un outil de surveillance, vous pouvez aussi comparer la structure HTML attendue. Mais même sans outil, l’œil et les outils développeur suffisent si vous savez quoi chercher.
En pratique, un “terminé” propre ressemble à ceci: votre page ne charge plus les domaines inconnus, le marqueur constant a disparu du HTML final, et la logique de rendu reste stable même quand vous changez légèrement les conditions de navigation.
Et si vous ne trouvez pas le marqueur dans les fichiers du thème ?
Ça arrive plus souvent qu’on ne le pense. Un scénario plausible: l’injection provient d’un plugin, d’un fichier dans un autre répertoire de wp-content, ou d’un mécanisme qui écrit du code au runtime, par exemple via une action sur un hook chargé très tôt.
Dans ce cas, la stratégie consiste à élargir le périmètre sans partir en panique:
- Cherchez le marqueur dans l’ensemble de wp-content, puis comparez avec un site sain. Si vous avez accès à un staging, comparez la sortie HTML des pages statiques entre staging sain et production. Inspectez les fichiers activés: un plugin désactivé ne devrait pas injecter son code. S’il le fait, cherchez un code persistant ailleurs. Vérifiez les réglages des plugins de cache et minification. Parfois, ils masquent ou rechargent un contenu.
Le bon sens de terrain: mieux vaut une analyse structurée, même si elle est plus longue, qu’un “nettoyage au hasard” qui vous laissera potentiellement avec une partie de l’infection toujours active.
Repérer l’infection sur les pages statiques, c’est aussi repérer votre propre angle mort
Beaucoup d’équipes surveillent les erreurs PHP, les pages les plus visibles, ou les fichiers les plus “dangereux” par intuition. Mais les pages statiques forment un théâtre discret. Elles sont souvent peu challengées, pourtant elles peuvent être instrumentalisées.
Quand on travaille sur du nettoyage fichiers infectés WordPress, l’angle gagnant est de partir du rendu final et d’identifier ce qui ne devrait pas être là. Le HTML final, le réseau, et la cohérence entre version saine et version actuelle donnent des réponses plus fiables que l’impression d’un contenu “qui ressemble à avant”.
Si vous construisez votre méthode autour de cette logique, vous gagnez un avantage important: vous ne nettoyez pas seulement, vous comprenez. https://gardewp.fr/nettoyage-malware-wordpress/ Et quand on comprend, on corrige plus durablement.