Quand un site WordPress se dégrade sans raison apparente, on pense d’abord au thème, aux plugins, aux mises à jour. Pourtant, dans pas mal de cas rencontrés sur le terrain, le problème est plus basique et plus sournois: du HTML injecté directement dans le rendu, souvent sous forme d’iframe. L’attaque n’a pas besoin de “casser” le site pour être efficace. Elle peut juste ajouter une iframe sur certaines pages, détourner un trafic, déclencher du tracking agressif, ou charger une ressource malveillante dans le navigateur des visiteurs.
Le plus pénible, c’est que ces iframe ne se laissent pas toujours voir. Elles peuvent être ajoutées via un champ de thème, un shortcode détourné, un fichier modifié discrètement, ou même via un plugin qui ne dit jamais son nom. On finit par regarder le code source de la page, et là, on voit un bloc d’iframe qui n’a rien à faire là. D’où la nécessité d’une désinfection WordPress propre, avec une logique de diagnostic, pas seulement un “suppression et on verra”.
Pourquoi les iframe sont un vecteur pratique pour les attaquants
Une iframe est simple à intégrer. Côté attaquant, c’est une manière de “brancher” une autre page dans la vôtre. Tant que l’iframe charge quelque chose de discret, l’impact peut être faible au premier regard. Mais le navigateur charge un contenu externe, et c’est souvent ce contenu externe qui fait le travail.
Selon les cas, les iframe injectés peuvent servir à:
- rediriger progressivement l’utilisateur vers des pages de phishing, parfois en jouant sur des comportements d’affichage exécuter un script dans un contexte cadré, ou déclencher des actions via des événements côté page injecter des publicités non souhaitées, ce qui donne l’impression d’un piratage “commercial” alimenter un fingerprinting ou un tracking qui vous échappe complètement si vous ne contrôlez pas les appels réseau
Sur WordPress, l’attaque se fait d’autant plus facilement que beaucoup de sites affichent du contenu HTML en entrée, utilisent des thèmes avec des champs personnalisés, ou chargent des templates qui concatènent des morceaux de code.
J’ai vu des sites où les iframe apparaissaient uniquement sur certaines URL, par exemple uniquement sur /contact ou sur des pages qui utilisaient un champ ACF. Un visiteur sur deux était exposé, parce que la condition d’injection se basait sur le user agent, la langue, ou un test sur l’heure. Sans inspection ciblée, on passe à côté.
Comprendre où se cache l’injection: ce que vous devez vérifier
Avant de supprimer l’iframe, l’erreur classique consiste à “nettoyer le symptôme” sans comprendre la cause. Si le code source affiche une iframe, cela ne veut pas dire que le fichier injecté est dans le thème. Parfois, l’injection se produit en amont, via un filtre, un hook, ou un contenu stocké en base.
Dans la pratique, je travaille avec trois pistes en parallèle:
1) l’iframe est-elle générée au moment du rendu, ou stockée telle quelle dans la base de données
2) l’iframe apparaît-elle seulement pour certains utilisateurs ou certains navigateurs 3) le contenu injecté correspond-il à un modèle répété, comme un motif dans un fichier modifié ou une fonction qui concatène du HTMLLe but n’est pas d’être parano, il faut juste éviter le faux sentiment de victoire. Quand on répare une désinfection “au hasard”, l’iframe revient souvent après la prochaine visite ou après le prochain chargement d’une ressource.
Symptômes qui trompent
Un détail que j’ai déjà observé: le code source du navigateur peut ne pas afficher toutes les injections. Certains contenus sont ajoutés après chargement via JavaScript, ou via un appel réseau déclenché par une iframe déjà présente. Du coup, vous pouvez croire que l’iframe est la seule pièce du puzzle, alors qu’elle n’est que le couvercle.
À l’inverse, parfois l’iframe est bien visible dans le code source, mais la cause est un champ de base de données rempli de façon malveillante. Dans ce cas, “supprimer l’iframe” dans le thème ne sert à rien: tant que le champ contient le HTML, WordPress le recrachera.
Étape 1: isoler le contenu malveillant sans vous piéger
La première action utile est d’observer l’iframe depuis une source reproductible. Idéalement, vous testez:
- votre navigateur “normal” et un navigateur en navigation privée un utilisateur sans cookies WordPress, si possible un contrôle via un outil d’inspection réseau, pour voir quelles URL sont appelées
Concrètement, ouvrez l’URL concernée, puis affichez le code source de la page (pas seulement le DOM rendu). Notez l’élément iframe exactement, l’attribut src, et tout motif distinctif autour. Le but est de pouvoir faire ensuite des recherches précises dans votre installation WordPress.
Deuxième point important: capturez l’URL et la page exactes où ça apparaît. Une désinfection WordPress efficace gagne un temps énorme quand on sait si le problème concerne une seule page ou tout le site.
Étape 2: rechercher les iframe injectés dans le code
Une fois l’iframe identifiée, la meilleure approche consiste à chercher son contenu dans votre installation, plutôt que de “nettoyer à l’œil”.
Commencez par des recherches dans:
- les fichiers du thème actif et des thèmes enfants les plugins actifs les fichiers générés ou caches, selon votre configuration les fichiers dans les répertoires qui servent à la personnalisation (par exemple des mu-plugins si vous en utilisez)
Si l’iframe comporte un domaine spécifique dans src, utilisez-le pour chercher dans les fichiers. Si l’iframe n’a pas de domaine stable, regardez des morceaux du code, comme une classe CSS, un identifiant, ou un fragment de HTML récurrent.
Ce qui m’a fait gagner des heures, c’est de ne pas se limiter à la chaîne exacte. Souvent, l’attaquant varie les paramètres d’une iframe à l’autre, mais garde le même squelette de balise ou la même fonction d’injection. En pratique, une recherche sur une partie du src ou sur un motif du HTML suffit.
Cas fréquents: injection via thème
Sur WordPress, le thème est un point d’entrée réaliste. Certains attaquants modifient un template spécifique, comme un fichier chargé pour certaines pages uniquement. Par exemple, si l’iframe n’apparaît que sur une page, ça colle souvent à l’existence d’un template dédié.
On observe aussi des modifications qui ressemblent à des ajouts “propres” dans le fichier, mais placés dans des zones où WordPress exécute du code à chaque rendu. Le piège, c’est que la modification peut être minime et passée pour un détail.
Cas fréquents: injection via plugin
Les plugins sont un autre candidat. Même si vous n’utilisez plus un plugin, s’il est encore présent et actif, il peut exécuter du code. Et plus embêtant, certains plugins contiennent des mécanismes de chargement de fichiers externes ou de remplacement conditionnel du contenu.
Quand une iframe apparaît soudainement après une installation récente, j’ai tendance à suspecter un plugin ajouté, ou une mise à jour qui a mal tourné, ou un plugin qui a été compromis.
Étape 3: vérifier la base de données, pas seulement les fichiers
Beaucoup de désinfections échouent parce qu’elles s’arrêtent à la suppression dans les fichiers. Pourtant, WordPress peut enregistrer du contenu HTML dans la base de données, par exemple dans:
- le contenu d’articles ou de pages les champs personnalisés des options globales des contenus de widgets parfois des données liées à des shortcodes
Si l’iframe est injectée en fonction d’une option ou d’un champ, vous pouvez supprimer l’iframe dans le thème et la voir réapparaître instantanément, dès la prochaine page affichée, parce que WordPress reconstruit la sortie à partir de la donnée stockée.
L’approche pratique consiste à repérer l’iframe en sortie, puis chercher un identifiant dans la base. Si vous voyez un domaine dans la balise iframe, cherchez ce domaine dans les tables qui contiennent des contenus, puis élargissez si besoin. Sur un gros site, ça peut prendre du temps, mais c’est souvent plus rapide que d’inspecter des dizaines de fichiers à l’aveugle.
Étape 4: désactiver sans casser, puis nettoyer
Le nettoyage demande un peu de méthode. Si vous coupez trop vite, vous risquez de perdre la capacité à vérifier. L’idée est de mettre le site dans un état stable, tout en conservant une preuve de l’origine.
Une stratégie raisonnable consiste à procéder ainsi:
1) sauvegarder rapidement la base et les fichiers de l’installation 2) basculer le site en maintenance si vous pouvez, ou au moins éviter d’exposer les visiteurs pendant la désinfection 3) désactiver les plugins non indispensables 4) repérer si l’iframe disparaît en désactivant un plugin, ce qui réduit fortement le champ d’investigation 5) inspecter le thème actif et le thème enfant
Si l’iframe persiste après désactivation de plugins, c’est souvent un thème modifié ou un contenu stocké. Si elle disparaît, vous tenez un fil: réactiver progressivement pour isoler la cause.
Voici un petit repère pour garder la main, sans transformer ça en usine à gaz.
- Désactivez les plugins, puis vérifiez une ou deux pages concernées en navigation privée. Réactivez ensuite un plugin à la fois, uniquement si l’iframe revient. Si l’iframe revient à la même URL, notez le moment exact et la liste de plugins active à ce stade. Si l’iframe ne revient pas, c’est généralement un plugin compromis ou une combinaison de plugins. Quand vous identifiez l’élément fautif, ne vous contentez pas de le supprimer, vérifiez aussi si d’autres fichiers ont été modifiés.
Supprimer l’iframe, oui, mais retirer aussi le mécanisme d’injection
Supprimer une iframe dans un fichier, c’est bien. Mais dans un environnement compromis, ce n’est pas suffisant. Une infection sait souvent “se réinstaller” via une chargeur, un hook, ou une donnée en base.
Quand j’inspecte un fichier où l’iframe semble ajoutée, je ne me contente pas de supprimer le bloc. Je regarde aussi:
- la présence de fonctions ajoutées, notamment des morceaux qui manipulent du contenu avant affichage des appels à des URL externes, surtout en dehors du contexte normal du plugin ou du thème des conditions inhabituelles, par exemple du code qui dépend d’un cookie ou d’un paramètre de requête des fichiers récemment modifiés, souvent via un horodatage incohérent avec vos changements
L’idée est simple: si le fichier contient une modification manifestement malveillante, il faut la retirer totalement, et pas juste remplacer l’iframe par un commentaire.
Le piège des “ressemblances”
Un attaquant peut ajouter une iframe “discrète” pour chaque page ou pour un template. Il arrive aussi que l’iframe soit masquée visuellement, avec un style CSS ou un attribut. Si vous cherchez uniquement la balise iframe, vous pouvez oublier d’autres injections qui ne ressemblent pas à une iframe au premier coup d’œil, mais qui déclenchent un chargement similaire via un script.
C’est pour cela que je préfère une approche en deux temps: identification de l’élément visible, puis recherche du mécanisme qui génère ou insère ce bloc.
Sécuriser ensuite, sinon vous réinvitez la même attaque
La désinfection WordPress ne vaut que si vous comblez les failles qui ont permis l’intrusion. Parfois, le site a été compromis via un mot de passe faible, parfois via une extension dépassée, parfois via un thème non maintenu, ou une configuration d’accès négligée.
Sans faire un cours de sécurité, il faut au minimum remettre en état ce qui rend un site “rechargeable” pour un attaquant.
Quelques actions qui font une réelle différence, quand elles sont adaptées à votre contexte:
- changer les mots de passe de tous les comptes administrateurs, et forcer la réauthentification vérifier l’existence de nouveaux utilisateurs non reconnus, et leur rôle vérifier l’installation de plugins ou thèmes ajoutés récemment, même s’ils ne semblent pas actifs mettre à jour le cœur WordPress, les plugins, et le thème si vous avez une maintenance correcte vérifier les règles de sécurité côté serveur, par exemple des limitations sur l’accès aux zones sensibles
Si vous avez un plugin de sécurité, utilisez-le aussi pour inspecter les changements de fichiers et l’historique de modifications. Attention toutefois à ne pas lui “faire confiance aveuglément”. Un système de sécurité peut détecter un indicateur, mais un faux négatif reste possible.
Un scénario concret: iframe sur une page de formulaire, et retour immédiat après suppression
Je repense à un cas où l’iframe apparaissait uniquement sur une page de formulaire. Le premier réflexe a été de retirer le bloc iframe dans le template du thème. Pendant quelques minutes, le site semblait propre. Puis au rafraîchissement, l’iframe revenait.
La cause était simple, mais révélatrice: l’iframe était stockée dans un champ de formulaire, injectée par une modification côté base de données. Le template affichait la valeur du champ, même si personne ne l’avait prévue pour contenir une balise iframe. Tant que le contenu restait en base, WordPress recrachait l’iframe.
Ce cas illustre un point crucial pour votre désinfection: si le site recalcule le rendu à partir de données stockées, supprimer uniquement dans les fichiers donne l’illusion d’avoir réglé le problème.
Quand on a nettoyé la donnée, le site est resté propre.
Détecter les éléments associés: fichiers modifiés, webhooks et chargements externes
Après avoir corrigé l’iframe, je fais toujours un passage rapide sur les signaux de compromission. L’objectif est de vérifier que vous supprimez l’origine, pas seulement l’affichage.
Dans l’inspection, je regarde en particulier:
- des fichiers nouvellement créés dans des dossiers inattendus des fichiers “modifiés récemment” avec une taille ou un contenu qui ne correspond pas à un plugin standard des appels sortants qui n’ont pas de raison d’être, surtout depuis des fichiers du thème ou des plugins des redirections dans le code, qui peuvent remplacer un utilisateur vers une autre destination
Si vous travaillez avec un hébergeur qui fournit des outils de scan, utilisez-les pour accélérer. Mais si vous n’avez pas ces outils, une recherche sur des domaines suspects ou sur des extraits repérés depuis l’iframe reste une méthode efficace.
Quand vous devez restaurer une sauvegarde, et quand vous pouvez nettoyer à la main
Il y a un moment où il faut trancher. Nettoyer à la main peut suffire si le périmètre est réduit, par exemple un thème modifié une fois, un champ en base, un plugin précis. Mais si vous suspectez une compromission plus large, vous gagnerez souvent du temps en restaurant une sauvegarde connue propre.
Le critère pratique que j’utilise est le suivant: combien de fichiers et de points d’injection différents ont été trouvés, et depuis quand le problème dure.
- Si vous avez une sauvegarde datée avant l’apparition, et si vous pouvez restaurer sans perdre des changements importants, la restauration est parfois le meilleur compromis. Si vous n’avez pas de sauvegarde fiable, le nettoyage complet demande alors plus de patience, notamment pour vérifier que rien d’invisible n’a été laissé.
La “désinfection WordPress” n’est pas qu’une suppression d’iframe, c’est aussi un retour à un état cohérent et reproductible.
Préparer un protocole pour éviter la récidive
Le problème, ce n’est pas seulement de retrouver l’iframe. C’est de ne plus être surpris. Sans tomber dans l’excès, un protocole minimal peut éviter de refaire les mêmes erreurs.
Voici ce que je recommande quand vous gérez plusieurs sites, ou quand vous voulez gagner du temps en cas d’incident.
- Documentez la date et l’URL exacte où l’iframe apparaît, et copiez le src de l’iframe. Gardez une copie du code de la page (source) au moment de la découverte, utile pour comparer après nettoyage. Faites une sauvegarde avant toute modification, même si vous pensez que “ça va être rapide”. Après correction, testez au moins deux navigateurs et une navigation privée. Vérifiez les utilisateurs, les plugins et le thème, car l’injection revient souvent par le même chemin d’accès.
Ce type de discipline rend l’analyse plus rapide, et surtout évite les faux retours à la normale.
Bonnes pratiques spécifiques pour WordPress lorsque des iframe sont interdites
Si votre site n’a pas besoin d’iframe, interdire leur présence dans certains contenus peut réduire l’impact. Vous pouvez aussi appliquer des filtres pour empêcher l’insertion HTML non souhaitée.
Le point délicat, c’est que WordPress gère déjà des formats particuliers, et certains thèmes ou plugins utilisent l’iframe de manière légitime, par exemple pour des embeds vidéo. Donc la “règle” ne doit pas être globale à l’aveugle.
Ce que vous pouvez faire de manière raisonnable, selon votre configuration:
- vérifier si vos éditeurs sont autorisés à coller du HTML brut contrôler les rôles et les droits d’édition, notamment pour les comptes non administrateurs durcir la désactivation des privilèges là où ce n’est pas nécessaire surveiller les champs qui acceptent du HTML, surtout ceux affichés sur les pages publiques
Si vous avez besoin d’autoriser certains embeds, vous pouvez encadrer, par exemple via un filtrage qui laisse passer des domaines autorisés, Voir le site Web plutôt que d’accepter tout.
Erreurs courantes qui prolongent la désinfection
Je vois souvent les mêmes difficultés:
La première est de ne corriger que ce que le navigateur affiche. Comme vu plus haut, l’origine peut être en base, pas dans le fichier.
La deuxième est de changer uniquement le thème ou uniquement le plugin, sans vérifier l’autre. Parfois, un plugin compromis injecte dans le thème, ou l’inverse.
La troisième est d’oublier la dimension “identifiants”. Si l’attaquant a changé un mot de passe, vous nettoyez l’iframe, mais l’accès revient. Sans rotation des clés et vérification des utilisateurs, le site reste fragile.
La quatrième est de ne pas vérifier les modifications de fichiers. Un fichier temporairement “réparé” peut encore contenir une logique d’injection, cachée ailleurs dans le code.
Vérifier la propreté après désinfection: comment être sûr
Après avoir retiré l’iframe et corrigé la cause, vous devez vérifier. Pas sur une seule page, pas avec un seul navigateur, pas juste “en rechargeant”.
Je fais au minimum:
- tests sur les pages concernées, avec navigation privée vérification du code source de la page, pour confirmer que la balise iframe n’est plus présente surveillance des appels réseau si vous utilisez une solution d’observabilité ou au moins les outils développeur revalidation que les plugins et le thème fonctionnent normalement
Si vous voyez des latences étranges, des comportements d’affichage bizarres, ou des redirections, traitez-le comme un signal. Souvent, l’iframe initiale n’est qu’un morceau d’une chaîne.
Ce qu’il faut retenir pour une désinfection WordPress réaliste
Supprimer une iframe injectée n’est qu’une étape. Une désinfection WordPress sérieuse répond à deux questions: d’où vient l’injection, et pourquoi l’attaque est possible.
D’un côté, l’inspection du code source et la recherche de motifs dans le thème et les plugins permettent de repérer la sortie malveillante. De l’autre, la base de données et la logique d’affichage révèlent souvent la cause réelle, surtout quand le problème revient après “correction”.
Quand vous combinez ces deux approches, vous réduisez fortement le risque de récidive. Et surtout, vous évitez le scénario frustrant du “ça a disparu” puis du “ça revient”.
Si vous êtes en cours de désinfection et que vous hésitez entre nettoyage manuel et restauration, le meilleur signal reste le périmètre de l’incident: nombre de modifications détectées, nature des fichiers touchés, et cohérence entre ce que vous trouvez et ce que vous observez en page. C’est souvent là que se joue la vitesse, et la fiabilité de votre remise en état.