Quand un site WordPress est compromis, on se focalise souvent sur l’attaque elle-même, la porte d’entrée, le thème ou un plugin vérolé. C’est logique. Pourtant, dans la réalité, le désastre se voit surtout ailleurs : sur le contenu public. Des pages “reviennent” avec des annonces bizarres, des paragraphes ajoutent du texte sans sens, des articles hébergent des liens vers des domaines douteux, parfois même du code injecté au milieu des paragraphes.
Le plus trompeur, c’est que tout peut sembler “normal” dans l’éditeur : le contenu “a l’air” de correspondre à ce que vous aviez écrit. Puis, côté navigateur, il y a une pollution. Elle vient souvent de plusieurs mécanismes en même temps : modification en base, filtres de rendu, appels à distance, chargement conditionnel, ou encore exploitation via un compte ayant accès à la rédaction.
Nettoyer le site ne consiste pas uniquement à “supprimer le plugin”. Il faut aussi purifier les pages et les articles infectés, et le faire de façon méthodique pour éviter les faux espoirs et les retours en arrière.
Le scénario typique : un site qui “revient” après nettoyage
J’ai déjà vu des nettoyages qui semblaient réussis. Le responsable d’un site m’a envoyé une capture : les pages avaient retrouvé leur contenu. On pensait l’incident réglé. Le lendemain, nouveau message d’alertes, mêmes pages, même texture d’injection. Le point clé, c’est que le contenu public était seulement “corrigé” dans l’interface, pas éradiqué à la source.
Deux causes reviennent souvent.
D’abord, la contamination n’est pas seulement dans les pages. Elle peut être dans la base, dans des champs d’options, dans des shortcodes, ou encore dans des champs “meta” liés au rendu. Si le mécanisme injecte au moment de l’affichage, vous pouvez réenregistrer le contenu et voir la modification disparaître une première fois, puis revenir à la prochaine visite ou à la prochaine exécution du code.
Ensuite, la compromission peut avoir laissé un fil d’accès permanent. Un plugin frauduleux, un fichier modifié dans le thème, un outil de type webshell, ou même un utilisateur ajouté avec des droits élevés. Tant que le point d’entrée existe, le contenu réinfecté peut être re-généré.
Nettoyer site WordPress infecté, au sens “contenu”, demande donc de traiter simultanément deux fronts : la suppression des données polluées et l’élimination du mécanisme d’injection.
Symptômes concrets à observer sur les pages et articles
Avant de toucher à la base, prenez quelques indices. Ils vous guident vers le type d’infection et vers la meilleure stratégie pour corriger.
- Une page affiche des blocs de texte qui n’ont pas de cohérence avec votre style éditorial, parfois en mélangeant plusieurs langues, ou avec des formulations qui “dérapent” d’une phrase à l’autre. Le contenu est présent seulement dans certaines sections : après un titre, avant un formulaire, dans les commentaires ou dans des encarts qui n’existaient pas. Les liens sortants changent. Vous voyez apparaître des ancres “banales”, des URL longues, ou des domaines qui n’ont aucun sens par rapport à votre niche. L’éditeur WordPress ne montre rien d’anormal. En revanche, le HTML rendu inclut des balises inattendues, du script, ou des éléments insérés à la volée. Les mêmes pages sont touchées, mais pas toujours de la même manière. Parfois, l’injection semble “varier” selon la session ou le user agent.
Ces signaux orientent votre investigation. Par exemple, si l’injection est visible seulement côté rendu, vous êtes probablement face à un filtre PHP, une fonction dans un thème/enfant thème, ou à une logique dans un plugin. Si, au contraire, les champs WordPress contiennent déjà le contenu pollué, il faut purifier les posts et pages directement dans la base.
Comprendre où se cache le contenu injecté dans WordPress
WordPress stocke le contenu des pages et articles dans des tables liées aux “posts”. Le champ principal, c’est le contenu HTML, et il y a aussi la partie “extrait” (excerpt), ainsi que des métadonnées liées au rendu.
Quand on parle de “contenu infecté”, on peut rencontrer plusieurs endroits :
- Le contenu brut des pages ou articles, dans les champs qui représentent la publication. Les excerpt, qui s’affichent parfois dans des modules de liste, ou dans des résultats de recherche interne. Des champs de métadonnées, comme ceux ajoutés par un plugin SEO, un builder, ou des intégrations. Des shortcodes injectés dans des zones qui finissent par se transformer en HTML au rendu. Des scripts qui ne sont pas stockés dans le contenu en tant que tel, mais ajoutés via des hooks, filtrant le contenu avant affichage.
Le point pratique : vous devez vérifier si la source de la pollution est dans la publication elle-même, ou si elle est injectée après coup.
La démarche “contenu d’abord” sans perdre le contrôle
Avant de lancer un grand “nettoyage”, j’aime travailler en deux temps : confirmer le support de l’injection, puis décider la méthode de suppression.
D’un point de vue opératoire, vous voulez éviter trois erreurs classiques :
1) Supprimer le contenu dans l’éditeur, sans comprendre comment il revient
2) Réenregistrer les posts infectés, mais laisser le mécanisme qui injecte au rendu 3) “Nettoyer” en copiant-collant du contenu propre sans restaurer l’état original, ce qui laisse des fragments d’infection dans des champs annexesLa bonne méthode dépend de la nature du contenu pollué.
Si vous observez que le HTML injecté existe déjà quand vous regardez le contenu côté WordPress (par export, par inspection directe dans la base, ou par affichage en mode édition), vous pouvez procéder à un nettoyage ciblé des champs de publication. Si l’éditeur montre un contenu “propre”, mais que le rendu est corrompu, il faut attaquer les hooks et les fichiers qui modifient le contenu.
Dans tous les cas, vous avez besoin d’un point de vérité : une copie propre avant incident, ou au minimum un export, des sauvegardes, et une liste des objets contaminés.
Travail préparatoire indispensable : sauvegarde, périmètre, et contrôle d’accès
La tentation, c’est de “faire vite”. Sur du WordPress compromis, c’est souvent là que les retours arrivent.
Vous devriez basculer le site en état de confinement avant d’intervenir : désactiver l’accès public, ou au minimum mettre un mode maintenance. Cela réduit le risque de re-injection et stabilise vos tests. Ensuite, sécurisez l’administration, car un compte compromis peut continuer d’écrire dans la base.
Concrètement, je recommande de procéder ainsi : vérifier les utilisateurs, changer tous les mots de passe, supprimer ceux qui ne devraient pas être là, et inspecter les droits. Si l’attaque est active, vous pouvez tenter le nettoyage, mais l’infection peut repartir à chaque nouvelle page chargée.
Ensuite seulement, vous passez à l’étape “contenu infecté”.
Diagnostiquer : contenu déjà pollué ou injection au rendu
Un test simple consiste à comparer trois choses :
- Le HTML réellement servi au navigateur Le contenu affiché en mode édition dans WordPress Le contenu exporté (ou récupéré) depuis la base, pour les posts et pages concernés
Si le HTML servi contient du code ou des fragments absents dans l’édition, vous êtes face à une injection via https://gardewp.fr/nettoyage-malware-wordpress/ hooks. Dans ce cas, le nettoyage doit surtout viser le code PHP, le thème, les plugins, et les options.
Si, au contraire, le contenu édité contient déjà les morceaux incohérents, alors l’attaque a modifié les champs de publication. Là, le nettoyage doit purifier la base au niveau posts et éventuellement meta.
Les deux cas peuvent coexister. J’ai déjà rencontré des injections “hybrides” : le contenu était modifié pour certains articles, et en plus un filtre PHP ajoutait un bloc invisible.
Nettoyer les pages et articles infectés : stratégie de restauration réaliste
Quand le contenu est pollué, le moyen le plus sûr dépend de votre historique.
Si vous avez une sauvegarde datant d’avant l’incident, le plus fiable reste la restauration ciblée des posts et pages concernés. Vous réimporte z les versions propres, ou vous remplacez les champs pollués par les champs de la sauvegarde. L’avantage est simple : vous évitez d’imaginer “ce qui devait être là”.
Quand il n’y a pas de sauvegarde exploitable, la tâche devient une reconstruction. Dans certains cas, vous pouvez remonter à une version capturée, à un cache, ou à des versions du site précédemment indexées. Mais il faut accepter que ce ne sera pas toujours fidèle à l’original.
Je vous conseille d’éviter le “nettoyage à la main” au texte en espérant supprimer uniquement les lignes visibles. Le piège : les injections peuvent être cachées dans un attribut, dans un script minifié, ou dans des extraits qui ne sont pas affichés sur la page mais qui reviennent dans des listings.
Voici des points de méthode qui font gagner du temps :
D’abord, isolez la liste des pages et articles suspects. Les infections ont des schémas, et une fois que vous avez trouvé 3 ou 4 exemples, vous pouvez souvent étendre la recherche à l’ensemble des publications touchées.
Ensuite, inspectez systématiquement les champs potentiellement contaminés : contenu principal, excerpt, et champs meta liés à votre rendu. Sur WordPress, un builder peut stocker une partie du rendu dans des champs meta. Si vous nettoyez uniquement “le contenu”, la page restera partiellement contaminée.
Enfin, testez au rendu, pas seulement en mode édition. Le but est que ce soit “propre” dans le navigateur, sur mobile, et idéalement via une vérification de l’HTML final.
Où chercher des traces dans la base, sans se perdre
Sans entrer dans un tutoriel de requêtes ici, l’approche que j’ai utilisée sur plusieurs projets consiste à chercher des motifs dans les tables liées aux contenus et aux métadonnées.
Vous pouvez repérer l’infection par des marqueurs fréquents : un fragment de script, une balise inattendue, un shortcode étrange, un domaine récurrent, ou même une chaîne de texte qui revient dans les paragraphes ajoutés.
Si l’injection est variable, les motifs changent. Dans ce cas, cherchez plutôt des anomalies structurelles : certains champs qui contiennent des tags HTML inhabituels, ou des chaînes qui ressemblent à du code minifié.
Une autre piste utile : comparez les versions normales de vos pages avec celles qui ont été altérées. Sur un site bien tenu, la structure du contenu suit un style stable. L’infection introduit souvent des patterns différents, par exemple un nombre de balises sans rapport avec le reste.
Supprimer l’infection côté rendu : thèmes, plugins, et hooks
Même après avoir nettoyé les posts, si un code modifie le rendu, les pages peuvent se recontaminer ou se “réinfecter” au moment de l’affichage.
C’est là que les thèmes et plugins jouent un rôle. Je ne parle pas seulement des fichiers principaux, mais aussi des fichiers additionnels qu’on oublie : des “helpers”, des fichiers dans des répertoires bizarres, des caches PHP, ou des scripts placés dans des endroits non standard.
Le diagnostic se fait souvent par logique, plus que par magie :
- Faites un état des lieux des fichiers modifiés récemment, si votre environnement le permet. Reproduisez localement le rendu infecté et inspectez le HTML final pour comprendre quel bloc est ajouté. Activez une approche prudente : désactiver les plugins un par un, en observant le rendu, sans toucher encore aux thèmes si vous n’êtes pas sûr.
Dans les cas graves, on procède à un remplacement contrôlé du thème par une version saine, puis on réactive progressivement.
Je n’insiste pas sur la méthode unique, car l’attaque varie. Mais une règle reste constante : tant que vous n’avez pas supprimé le mécanisme d’injection, “nettoyer les pages” n’est qu’un pansement.
Cas fréquent : les pages sont sales, mais l’éditeur n’affiche rien clairement
Il arrive que le contenu injecté soit “invisible” dans le back-office. Soit parce qu’il est ajouté par un hook, soit parce que le filtre modifie la sortie sans altérer le champ d’entrée.
Dans ce cas, la stratégie se déplace :
- Vous vérifiez les filtres qui agissent sur “the_content” et sur des zones liées au rendu, comme les shortcodes. Vous examinez les plugins qui transforment le contenu, même ceux que vous utilisez rarement. Vous repérez les scripts ajoutés conditionnellement, par exemple selon la langue, la région, ou le navigateur.
Ce comportement peut aussi être lié au chargement de scripts externes. Le site semble “propre” à première vue, mais le navigateur reçoit un bloc qui redirige, ou qui affiche une superposition.
Le nettoyage du contenu, dans ce cas, consiste à éliminer le mécanisme et à vérifier que les pages retrouvent leur HTML final sain. Le fait d’avoir “nettoyé” les champs n’assure rien.
Une check-list de triage qui évite les erreurs de tempo
Quand je dois traiter un incident vite, je garde une liste mentale. Pour que ce soit concret, voici une check-list courte, utilisée dans les premiers échanges avec un client :
Mettre le site en maintenance pour stopper la réinfection pendant l’analyse Vérifier les utilisateurs, supprimer ceux qui n’ont pas lieu d’être et changer tous les mots de passe Isoler les pages et articles suspects, puis comparer HTML rendu et contenu édité Déterminer si l’infection est stockée dans les champs, injectée au rendu, ou les deux Lancer un nettoyage ciblé, puis recontrôler le rendu depuis un navigateur externe après suppression du mécanismeCette séquence réduit le risque de “nettoyer deux fois”, parce qu’on traite la cause au bon moment.
Nettoyage ciblé : comment éviter les dégâts collatéraux
Supprimer du contenu injecté, ce n’est pas “tout effacer”. Le risque, c’est de détruire un contenu sain, ou de casser des shortcodes légitimes, ou de supprimer des éléments structurants ajoutés par un builder.
Un cas typique : un article utilisait un constructeur, et l’infection a injecté du texte dans une zone générée. Si vous supprimez le bloc au mauvais endroit, vous perdez des sections entières.
Donc, au lieu d’agir en aveugle, l’approche la plus sûre consiste à :
- Identifier le périmètre exact du contenu infecté dans chaque page Retirer uniquement les fragments pollués, ou remplacer le champ par une version propre Vérifier que les shortcodes et blocs restent cohérents après suppression
Cela demande du jugement, surtout quand la page est longue. Mais c’est moins risqué que de “purger” tout et de reconstruire ensuite.
Dans certains projets, le compromis est assumé : on choisit de restaurer depuis sauvegarde. Si c’est disponible, c’est souvent la meilleure voie.
Après nettoyage : vérifier l’absence de réinfection
Une fois le contenu et le mécanisme traités, il faut vérifier. Et pas uniquement en testant une page au hasard.
Les infections ont des patterns. Parfois, seules certaines catégories d’articles sont touchées. Parfois, c’est lié à des templates spécifiques.
Je fais généralement trois types de contrôle :
- Contrôle de rendu sur un échantillon de pages et d’articles, en reproduisant plusieurs scénarios (mobile, langue, paramètres de cache si pertinent) Contrôle de la structure HTML pour repérer les tags ou scripts inattendus Contrôle des liens et domaines sortants, notamment si vous avez des outils de surveillance des redirections ou des changements de maillage
Si vous voyez des éléments réapparaître, il y a un reste de code, ou un mécanisme de réécriture qui n’a pas été neutralisé.
Dans les environnements WordPress chargés, la cache peut aussi créer une illusion. Une page “propre” peut être affichée grâce à une cache persistante, puis revenir infectée quand le cache expire. D’où l’importance d’avoir un contrôle qui tient compte du caching.
Durcir le site pour que le nettoyage tienne dans le temps
Nettoyer site WordPress infecté, c’est rarement un acte isolé. Une fois que vous avez éradiqué le contenu pollué, vous devez empêcher la prochaine intrusion.
La durcification la plus efficace combine des mesures techniques et des habitudes d’accès. Beaucoup de compromissions reviennent parce que le même point faible est conservé.
Sans en faire une liste interminable, je vous donne deux angles concrets.
D’abord, l’accès admin doit être verrouillé. Un plugin d’authentification renforcée, des limites sur les tentatives de connexion, et une gestion rigoureuse des rôles réduisent la surface. Un compte admin partagé ou un mot de passe identique ailleurs reste un risque.
Ensuite, la maintenance des plugins et thèmes compte autant que le nettoyage. Un plugin abandonné ou un thème modifié sans contrôle est un point d’entrée classique. Le “tout garder parce que ça marche” finit par coûter cher.
Une autre mesure utile consiste à limiter les modifications en production. Par exemple, désactiver les éditeurs en production pour les équipes non techniques, ou travailler via un environnement de staging avec déploiement contrôlé. Cela ne stoppe pas toutes les attaques, mais ça change la vitesse de contamination.
Une mini-liste de durcissement post-incident
Pour rester pragmatique, voilà une seconde check-list, courte, orientée action, après remise au propre :
Mettre à jour WordPress, thèmes et plugins, puis vérifier la cohérence de rendu après chaque lot Revoir les rôles et retirer tout accès inutile aux comptes existants Ajouter une couche de protection d’authentification et surveiller les connexions suspectes Supprimer les plugins ou modules dont vous ne maîtrisez pas le code ou l’origine Mettre en place une surveillance des changements de fichiers et une alerte sur les modifications de contenusSi vous faites ces points, vous rendez le prochain épisode beaucoup moins probable, ou beaucoup plus rapide à détecter.
Les pièges à connaître : quand on pense avoir nettoyé, mais que tout n’est pas fini
Il y a plusieurs pièges https://gardewp.fr/ récurrents que je vois après incident.
Le premier, c’est la cache. Si vous avez des caches serveur, CDN, ou des plugins de performance, vous pouvez afficher pendant un moment des versions propres. La contamination réelle peut être ailleurs, dans la base, et revenir à la prochaine expiration de cache.
Le deuxième piège, c’est le contenu “annexe”. On nettoie le contenu principal, mais on oublie l’extrait, les métadonnées, ou des champs propres à un builder. Visuellement, tout semble correct sur la page unique, mais le listing ou la page de catégorie affiche encore des fragments injectés.
Le troisième piège, c’est l’obtention de droits persistants. Même si vous supprimez les fichiers injectés, un utilisateur compromis peut continuer à republier ou à modifier du contenu, surtout s’il a accès à une catégorie ou à des tâches automatisées.
Enfin, le dernier piège est psychologique : on s’arrête quand “ça ne se voit plus”. Or, un incident WordPress compromis laisse parfois des traces qui ne sont visibles que sur des routes spécifiques, des pages de recherche, ou après un certain comportement côté navigateur.
Quand il faut passer par une restauration complète
Il arrive que le nettoyage ciblé devienne une perte de temps. Pas parce qu’il est impossible, mais parce que vous n’avez pas les garanties nécessaires sur l’étendue de l’infection.
Je conseille d’envisager une restauration complète dans des situations comme :
- Vous ne pouvez pas distinguer ce qui est modifié de ce qui ne l’est pas Les injections touchent trop de types de pages et de modèles Vous suspectez un mécanisme complexe dans le thème ou dans plusieurs plugins Les sauvegardes sont insuffisantes pour restaurer proprement des contenus individuels
Une restauration complète, suivie d’une réinstallation contrôlée des éléments, donne un point de départ plus fiable. Le coût est plus élevé en temps, mais il évite des “petites retouches” qui ne finissent jamais.
Ce que j’attends d’un bon nettoyage “contenu” (et ce que vous devriez exiger)
Si vous êtes client, ou si vous supervisez une équipe, il y a des livrables qui doivent être clairs. Pour un nettoyage des pages et articles infectés, je m’attends à ce que l’on puisse répondre à ces points, sans flou :
- Quelles pages et quels articles ont été nettoyés, et sur quels champs exacts Comment on a vérifié la disparition de la pollution côté rendu, pas seulement dans l’éditeur Quel a été le mécanisme supprimé pour éviter la réinfection Quel a été le plan de durcissement post-incident
Sans ces éléments, vous risquez de rouler sur un nettoyage incomplet. Et ça, même en apparence, finit par se payer.
Dernier mot de méthode : agir en couches, pas en panique
Quand un site WordPress est compromis, la pression monte vite. On veut “enlever le danger” immédiatement. C’est humain.
Mais pour nettoyer le contenu des pages et articles infectés, la meilleure approche reste celle qui combine stabilité et preuve : confinement, diagnostic du mode d’injection, nettoyage ciblé des champs contaminés, suppression du mécanisme au rendu, puis vérification externe avec une surveillance des retours.
C’est ce qui transforme un épisode de crise en chantier propre. Et c’est aussi ce qui évite de recommencer, semaine après semaine, à la moindre réapparition d’un bloc étrange dans une page qui devrait être tranquille.