WordPress infecté : supprimer des liens externes injectés (phishing)

Un site WordPress qui affiche soudain des liens externes “bizarres” au milieu du contenu, dans les menus ou au bas des pages, ce n’est pas un détail de mise en forme. C’est souvent le signe d’un piratage, parfois discret, parfois bruyant, et dont l’objectif est presque toujours le même: pousser l’utilisateur vers une destination frauduleuse (phishing), monétiser via des redirections, ou propager d’autres charges malveillantes.

Ce qui rend le problème piégeux, c’est que l’injection peut sembler “logique”. Les liens s’intègrent comme s’ils avaient toujours été là. Parfois ils n’apparaissent que pour certains appareils, ou seulement après un certain temps de chargement. Et dans d’autres cas, on croit d’abord à un problème de thème, puis à un plugin, puis à une mise à jour qui a “cassé” quelque chose. En réalité, ce que l’on observe est souvent un mélange de fichiers modifiés, de base de données altérée, et de mécanismes qui ajoutent du HTML à la volée.

Je vais te guider pas à pas, sans promesses magiques, sur la manière de supprimer des liens externes injectés et de remettre le site WordPress au propre. Je vais aussi te dire ce qu’il ne faut pas faire, et pourquoi, car dans ce genre d’incident, une “correction” trop optimiste peut empirer la compromission.

Signes concrets d’une injection de liens externes

Les liens injectés ne se détectent pas toujours en regardant la page en mode navigation normale. Dans certains cas, un simple copier-coller de la source HTML te donne une réponse immédiate. Dans d’autres, il faut comparer plusieurs pages, plusieurs navigateurs, ou même les mêmes pages avec et sans cache.

Les patterns typiques que j’ai rencontrés sur des WordPress compromis ressemblent à ceci, sans que ce soit une règle absolue:

Les liens externes apparaissent dans le footer ou entre deux paragraphes, sans être présents dans l’éditeur WordPress. Le texte d’ancrage (anchor text) est parfois cohérent avec le sujet de la page, ce qui rend l’attaque plus crédible. Les URLs pointent vers des domaines récemment créés, des redirections courtes, ou des destinations qui demandent une connexion, un numéro, un téléchargement “urgent”, etc. Les liens changent selon la page, mais partagent une structure commune. Le comportement se voit dans la source “view-source”, même quand le rendu visuel est trompeur.

Un détail important: si tu vois des liens externes ajoutés dans plusieurs contenus alors que tu n’as rien importé ni modifié récemment, il faut traiter le site comme potentiellement compromis et passer en mode enquête.

Comprendre d’où viennent ces liens: logique d’attaque

Avant de supprimer quoi que ce soit, il faut savoir comment cela a pu être injecté. Sur WordPress, les vecteurs les plus fréquents sont:

Modification de fichiers thème ou plugins Ajout de code dans des fichiers de “bootstrap” (index, wp-config, fichiers dans wp-content) Injections dans la base de données (options, meta, contenus, widgets, menus) Injections via des mécanismes “furtifs” (hooks PHP, cookies, conditions d’accès)

Sur les liens externes injectés, la méthode la plus frustrante est celle qui “semble” venir du thème, car le contenu injecté ressemble à du HTML normal. Parfois, ce n’est pas le thème lui-même qui a été modifié, mais une fonction ajoutée à un endroit inattendu, puis appelée à chaque affichage.

Autre piège courant: croire que supprimer le lien dans l’éditeur suffit. Si le code malveillant reste en place, il va réinjecter le même bloc au prochain chargement, parfois avec de légères variantes.

La première étape: isoler le problème sans casser davantage

Quand tu soupçonnes un phishing ou une injection active, tu as deux objectifs: réduire l’exposition des visiteurs et collecter des indices sans détruire la preuve.

Si ton site est vivant et que tu as la possibilité de le mettre en mode maintenance, fais-le rapidement. L’idée n’est pas de “sauver la face”, c’est de limiter la propagation et le risque de clic.

Ensuite, prenez deux repères avant toute suppression:

la liste exacte des URL de destination frauduleuse (ou au moins les domaines) la présence ou non du code injecté dans la source HTML (view-source) et dans le rendu

Pourquoi ces repères comptent? Parce que quand tu auras nettoyé, tu voudras confirmer l’absence totale, et tu ne veux pas te battre contre un symptôme différent.

Ce qu’il faut vérifier en priorité (avant la purge)

À ce stade, je recommande de travailler avec une approche “diff” et “inventaire”. Tu veux comparer ce qui tourne aujourd’hui à ce qui aurait dû être là.

Sur un WordPress, les dossiers où je regarde en premier, ce sont ceux où un attaquant a un accès facile:

wp-content/themes (thèmes) wp-content/plugins (plugins) wp-content/uploads (parfois utilisé pour héberger des scripts ou images de camouflage) fichiers racine (index, wp-config et autres) la base de données (où le site “se souvient” des menus, widgets, options et contenus)

Pour être efficace, fais en sorte d’avoir une copie de travail. Selon ton environnement, cela peut être une sauvegarde complète, ou au minimum une copie de wp-content et un export SQL si tu peux. Ensuite, tu inspectes.

Une erreur fréquente: supprimer tout “ce qui ressemble à du code” sans savoir d’où vient l’exécution. Exemple réel de galère: on retire un bloc dans functions.php, mais le code injectait en réalité via une option SQL et le problème persiste. Inversement, on supprime un fichier dont dépend un plugin légitime, et le site tombe. Donc tu veux une inspection structurée.

Vérifications rapides côté navigateur et source HTML

Avant de plonger dans le FTP, tu peux gagner du temps en observant le rendu.

Ouvre la page touchée et regarde:

le HTML brut (view-source) pour voir si l’injection est côté serveur les scripts chargés, via les outils développeur (onglet Network). Si tu vois un chargement de script sur un domaine inconnu, c’est un indice majeur les variations selon navigateur et device (utile quand l’injection conditionne l’affichage)

Si l’injection est visible dans le HTML brut, c’est presque toujours une modification côté serveur, pas juste un problème CSS.

Premier geste utile: neutraliser les risques pendant l’enquête

Un site compromis n’est pas “juste sale”, il peut rester dangereux même si tu ne vois pas tout de suite. Parfois l’injection redirige seulement certains utilisateurs, ou ajoute une interaction invisible (comme un lien sur toute une https://gardewp.fr/ zone).

Sans entrer dans des détails dangereux, voici une stratégie raisonnable:

mettre le site en maintenance si possible désactiver temporairement les thèmes et plugins suspects, mais seulement après avoir gardé une copie ou un relevé verrouiller l’accès administrateur pendant que tu nettoies, si tu suspectes un compte compromis

Je sais que ça ressemble à une procédure. Ce que je cherche, c’est la réduction du risque pendant que tu analyses.

Méthode de nettoyage: supprimer les liens externes injectés, proprement

Le nettoyage se fait en plusieurs couches, parce que WordPress peut être compromis à plusieurs endroits à la fois. Le but n’est pas uniquement de retirer l’affichage, c’est de supprimer la cause.

1) Chercher les points d’injection dans wp-content

Commence par les fichiers les plus “probables”: functions.php du thème actif, fichiers dans le thème (par exemple header.php, footer.php), et fichiers principaux des plugins.

Tu cherches des éléments typiques comme:

fonctions qui concatènent des morceaux HTML l’utilisation de chaînes qui ressemblent à des domaines externes, ou des patterns d’URL du code qui base64 encode ou décode des contenus des blocs “if” conditionnels très spécifiques des appels à des hooks atypiques

Techniquement, tu peux faire une recherche de texte dans l’ensemble des fichiers pour repérer les domaines malveillants. Même si le code est obfusqué, il laisse parfois des constantes en clair.

Astuce pratique: fais aussi une recherche sur le nom du thème actif et sur les plugins installés récemment. Si l’attaque a été déclenchée après une installation, tu vas gagner du temps.

2) Vérifier les modifications de thème ou plugin

Si tu as un thème custom, il peut être légitime qu’il contienne du code. Le problème, c’est quand tu vois des sections ajoutées qui ne ressemblent pas au reste du projet.

Un signal utile est le changement rapide: si des fichiers ont des dates de modification incohérentes avec ton historique, suspecte.

Dans l’idéal, tu compares avec une version connue saine du thème ou du plugin. Parfois, la version saine ne correspond pas exactement si le site a été customisé, mais tu repères vite les morceaux étrangers.

Si tu n’as pas de version saine, au minimum, compare avec un backup récent si tu en as un. Et si tu n’as rien, il faut être plus prudent et tester après restauration partielle.

3) Inspecter la base de données

C’est là que beaucoup de gens se font piéger. Même si les fichiers semblent propres, la base peut contenir des injections, par exemple:

contenus de pages ou articles modifiés menus (liens ajoutés dans l’interface) widgets de type texte, qui peuvent contenir du HTML malveillant options WordPress modifiées fragments stockés via meta

Si tu as accès à phpMyAdmin ou via un outil équivalent, cherche les domaines frauduleux dans la base. Si tu retrouves un domaine injecté dans plusieurs tables, tu as un point d’ancrage.

Important: ne supprime pas “au hasard” une entrée si tu n’identifies pas sa nature. Exemple: supprimer une option pourrait casser un plugin légitime. Dans ce cas, la bonne approche consiste à sauvegarder l’export de la base puis à retirer uniquement les lignes qui contiennent clairement les liens injectés.

4) Nettoyer sans casser les fonctionnalités légitimes

Quand tu trouves le bloc d’injection, tu dois retirer le code qui produit les liens, pas seulement le HTML final.

Si la base contient un champ texte injecté, tu peux le nettoyer et vérifier. Si c’est une fonction PHP dans le thème qui ajoute le HTML, tu supprimes la fonction ou la branche qui génère l’externe.

Après chaque modification significative, teste sur une page touchée, idéalement sur un environnement de staging. Si tu n’as pas de staging, fais au moins un test sur une page unique et surveille la source HTML.

Un mini plan de vérification (calibré pour aller vite)

Quand j’aide quelqu’un sur un site infecté, je fais souvent un cycle “détecter, confirmer, éliminer, re-confirmer”. Pour éviter les oublis, voici un repère simple.

Repérer le domaine ou pattern des liens injectés, et confirmer qu’ils apparaissent dans le HTML brut Chercher ces domaines dans wp-content et la base de données Identifier le fichier ou la donnée qui génère réellement l’injection, pas seulement l’affichage Remplacer les fichiers modifiés par des versions saines ou corriger le code à l’origine Re-tester plusieurs pages, en vidant caches et en testant un navigateur différent

Tu verras vite si l’injection revient, et dans ce cas tu n’as pas encore supprimé la cause.

Gestion des caches, CDN et logique de propagation

Un problème classique: tu nettoies, puis tu vois encore un lien externe, parfois identique, parfois plus discret. Tu crois que le nettoyage a échoué. Souvent, ce n’est que du cache.

Entre les caches WordPress (si activés), le cache serveur (Nginx, Apache), le CDN (si présent), et les règles de “full page caching”, le site peut servir une version ancienne pendant un certain temps.

Donc avant de conclure “ça n’a pas marché”, pense à:

vider le cache du plugin de cache s’il y en a un invalider le cache CDN tester en navigation privée, sans cookies, ou avec un User-Agent différent

Dans des cas plus piégeux, un attaquant peut aussi conditionner l’affichage via cookies ou sessions. Ce comportement peut masquer l’injection lors des tests superficiels.

Suivre la piste des comptes compromis et des accès

Supprimer les liens, c’est une partie de l’histoire. L’autre partie, c’est empêcher le retour.

Si ton site a servi de pivot, il y a de fortes chances que le vecteur soit une identifiant compromis, une attaque par brute force sur l’espace admin, ou un plugin vulnérable. Parfois c’est un simple compte admin ajouté, souvent avec un rôle élevé.

Vérifie:

la liste des utilisateurs WordPress (noms nouveaux, emails inattendus) l’historique de connexion si tu as accès à des logs les modifications récentes de plugins et thèmes les tentatives de login et la présence d’IP suspectes côté serveur

Si tu vois un compte que tu ne reconnais pas, supprime-le, puis réinitialise les mots de passe de tous les utilisateurs légitimes. Et choisis des mots de passe uniques. En cas d’incertitude, force un renouvellement complet.

Cas particuliers: liens injectés uniquement sur certaines pages

Il y a des infections qui ne touchent pas tout le site. Par exemple, elles injectent uniquement dans les pages “articles”, dans les pages de catégorie, ou dans une page particulière.

Ce comportement correspond souvent à:

des conditions dans le code PHP (par ID de page, par slug, par type de contenu) des filtres WordPress appliqués à “the_content” avec une condition un traitement différent par modèle de thème

Dans ce cas, il faut élargir ton investigation. Si tu ne regardes que la page où tu as vu l’injection, tu risques de rater un code de base qui agit ailleurs.

Le test utile est de comparer deux pages proches: une qui est “infectée” et une qui ne l’est pas. Si la source HTML diffère au niveau de certains blocs, tu as une piste.

Cas fréquents de “faux” indicateurs

Je te donne aussi des situations où on peut perdre du temps:

Un lien externe apparaît parce que le site contient déjà des références légitimes (Google Maps, vidéos, CDN d’un plugin). Si tu vois un nouveau domaine inconnu apparu à la même date que l’incident, c’est suspect. Un plugin a une fonctionnalité marketing qui insère des liens. Cela peut ressembler à une injection, mais le code est cohérent et le domaine est connu. Un thème est mis à jour et ajoute une nouvelle section. Là aussi, tu dois comparer à la version saine.

La clé est la cohérence temporelle et la traçabilité: qu’est-ce qui a changé récemment, et quel composant est responsable côté source HTML?

Comment confirmer que le site est réellement nettoyé

Après correction, tu veux prouver l’absence.

La preuve la plus directe est de:

recharger plusieurs pages et vérifier la source HTML rechercher dans ton code et ta base les domaines frauduleux (ou les patterns) vérifier qu’aucun script externe inconnu n’est chargé tester depuis un navigateur différent, idéalement sur un autre réseau, pour réduire l’effet cache

Tu peux aussi surveiller les logs serveur (erreurs 404 anormaux, requêtes régulières vers des URLs inconnues) et les logs d’accès à WordPress. Si tu observes des comportements bizarres qui continuent après nettoyage, il faut réinvestiguer.

Et oui, parfois il reste un petit résidu, invisible pour l’utilisateur, mais qui continue d’appeler une ressource. Le phishing peut être “indétectable” si les liens ont été retirés, mais l’infrastructure reste présente.

Réécrire l’essentiel: la sécurité après nettoyage

Quand un site a été compromis, l’objectif n’est pas seulement de supprimer des liens externes injectés. C’est aussi d’éviter qu’un attaquant ne revienne par le même chemin.

Le bon sens opérationnel, sans tout refaire à zéro:

mettre à jour WordPress, thèmes et plugins supprimer les plugins inutilisés renforcer l’accès admin (mots de passe forts, limitation d’accès, si possible 2FA) surveiller les tentatives de connexion stocker des sauvegardes versionnées, et tester la restauration

Et je le dis parce que je l’ai vu trop souvent: une seule “reprise” avec un nettoyage partiel, puis un oubli sur une mise à jour, et le problème revient. Le phishing ne lâche pas facilement, il revient par le vecteur d’entrée.

Pourquoi la suppression “rapide” échoue

Si tu as déjà tenté un nettoyage, tu as peut-être rencontré ce scénario: tu supprimes le code visible, tu redéposes un thème, tu nettoies des articles, et pourtant l’injection revient.

Les raisons typiques:

le code malveillant est dans un autre fichier que celui corrigé l’injection vient d’une option SQL, d’un widget ou d’un menu le site charge un script depuis un emplacement masqué un plugin compromis réapplique la charge après chaque chargement le cache sert une version ancienne et donne une illusion de persistance

C’est pour ça que la recherche par domaine et la vérification en source HTML sont déterminantes. Elles te donnent un repère objectif, au lieu de te baser sur le rendu.

Mémo: ce que tu peux faire de suite (sans te mettre en danger)

Si tu veux un cadre d’action réaliste, je te propose de suivre un ordre qui limite les erreurs:

commence par repérer clairement les liens injectés garde une sauvegarde du contenu avant toute suppression élimine la source dans les fichiers et les données invalide les caches et revalide sur plusieurs pages corrige l’accès, change les mots de passe, vérifie les comptes

Sur un WordPress infecté, nettoyer site WordPress infecté demande souvent de la méthode plus que de la “magie”. L’important est de traiter la cause, pas uniquement le symptôme.

Quand appeler un spécialiste (et comment juger)

Il y a des situations où je recommande d’appeler un prestataire ou de demander une aide plus approfondie. Par exemple:

le site est injecté à grande échelle, avec de multiples domaines externes et scripts tu ne sais pas quelles versions saines correspondraient aux thèmes et plugins tu as peu ou pas de sauvegardes, et tu dois éviter une panne tu as besoin d’optimiser le “temps d’arrêt”, sans perdre la traçabilité

Un bon intervenant te demandera des éléments concrets, comme les pages touchées, un exemple de source HTML, l’historique de modifications, et la liste des domaines injectés. S’il te promet un nettoyage “en une heure” sans inspection, ça doit alerter. Sur ce type d’incident, la vitesse sans rigueur crée des retours.

Dernier point important: surveillance après incident

Une fois le site nettoyé, surveille pendant quelques jours. Les attaques peuvent être automatisées. Parfois l’injection revient immédiatement, parfois elle attend. Selon le niveau d’accès dont l’attaquant dispose, il peut réintroduire du code, soit manuellement, soit via un mécanisme déjà en place.

Tu peux suivre:

l’indexation et les signaux des moteurs (si tu as un accès aux outils pour webmaster) les logs d’accès et les erreurs serveur la cohérence du code injecté, via une recherche répétée des domaines externes dans le projet

La phase de “stabilisation” est aussi une forme de nettoyage.

Si tu veux, décris-moi ce que tu observes exactement: une URL de page touchée (ou au moins le type de page), le pattern des liens externes (domaines et format), et si l’injection apparaît dans le HTML brut. Avec ces détails, je peux te proposer une stratégie de recherche plus ciblée pour retrouver rapidement la source de l’injection, sans faire de dégâts collatéraux.