Enlever virus WordPress : comment vérifier la présence de liens sortants frauduleux

Quand on parle de “virus WordPress”, la plupart des gens imaginent un écran bleu ou un binaire qui se télécharge tout seul. En pratique, les infections WordPress ressemblent plus souvent à une mécanique discrète: un fichier modifié, un bout de script ajouté dans un thème, un plugin qui détourne des requêtes, ou encore un champ de la base de données qui insère des liens sortants vers des domaines louches.

Dans ce contexte, vérifier la présence de liens sortants frauduleux est une étape décisive, parce que ce sont eux qui déclenchent le spam, la redirection et la perte de confiance SEO. Et, point important, ces liens ne se manifestent pas toujours “visiblement” pour un visiteur. Parfois, ils ne s’affichent qu’au chargement d’une ressource précise, ou uniquement pour certains navigateurs. Parfois, ils sont noyés dans un script minifié, donc difficile à repérer.

Je vous propose une méthode réaliste, celle que j’utilise quand je dois diagnostiquer vite, sans casser le site, puis éliminer ce qui a été ajouté. L’idée centrale est simple: chercher les anomalies dans les endroits où WordPress est le plus modifiable, puis vérifier que les liens sortants proviennent bien de votre installation, pas d’un proxy, d’une extension saine, ou d’un CDN mal configuré.

Distinguer “infection” et “simple redirection”

Avant de plonger dans le code, prenez cinq minutes pour observer le comportement. Les liens sortants frauduleux se reconnaissent souvent par un effet concret:

une redirection vers une page sans rapport avec votre contenu, des liens externes ajoutés automatiquement dans le HTML final, des appels vers des domaines inconnus dans la page produite, des scripts chargés depuis l’extérieur, qui ne correspondent à aucun plugin ou outil que vous utilisez.

Sur un site que j’avais repris après une reprise “à la va-vite”, le symptôme était trompeur: aucune erreur, pas de bannière, juste un léger ralentissement. En inspectant la source HTML servie, on voyait pourtant un script minifié injecté à la volée, puis un lien sortant vers un domaine fraîchement enregistré. Les visiteurs ne le voyaient pas toujours car le code ne s’exécutait que dans certaines conditions, notamment après interaction sur la page.

Cette nuance est importante. Une configuration cache peut retarder l’apparition du HTML contaminé, et une redirection peut être activée uniquement sur des pages ciblées (par exemple catégorie, recherche, tags).

Ce que “liens sortants frauduleux” veut dire concrètement

Dans une infection WordPress, un lien sortant frauduleux peut être:

1. Un lien hypertexte ajouté dans le contenu rendu (dans l’article, le widget, le footer). 2) Une redirection, par exemple via un script ou un meta refresh. 3) Un chargement de ressource externe (JS, iframe, image), qui à son tour déclenche des redirections ou des popups. 4) Un envoi de paramètres vers un domaine tiers, parfois déguisé en tracking.

La vérification ne doit donc pas se limiter à chercher “http” dans le thème. Il faut aussi regarder les balises script, iframe, link rel, img src, et parfois certains attributs “exotiques” comme onload dans du HTML injecté.

Préparation: vous vérifiez avant de nettoyer

Le piège classique, c’est de supprimer “au feeling” dès qu’on trouve un fichier bizarre. Sur WordPress, un thème ou un plugin peut contenir un code volontaire (premium, custom, ou du caching), et vous risquez de casser une fonctionnalité légitime.

Avant d’enlever quoi que ce soit, procédez dans cet ordre:

Sauvegardez la base de données et le dossier WordPress. Identifiez le contexte: depuis combien de temps ça se produit, et sur quelles pages exactement. Notez vos plugins et thèmes installés. Un plugin de cache ou de sécurité peut influencer le HTML généré.

Ensuite, vous pouvez comparer deux choses: le HTML servi en production, et le code source dans vos répertoires locaux.

Vérifier les domaines externes dans le HTML servi

La première vérification, c’est celle qui donne le plus vite un verdict. Ouvrez une page sur votre site qui pose problème (par exemple la page d’accueil, un article, une page qui reçoit des visites).

Puis, inspectez le HTML “réel” généré. Dans Chrome, c’est le panneau “Sources” ou “Elements”. L’objectif n’est pas de tout lire, mais de chercher des signes:

scripts chargés depuis un domaine que vous ne connaissez pas, iframes vers des domaines tiers, liens externes dont l’ancre ne correspond à rien dans votre texte, balises meta ou scripts qui forcent une navigation.

Ce que je regarde en priorité, ce sont les zones qui changent rarement: le footer, les templates du thème, et les hooks qui s’exécutent en bas de page. Dans une infection, l’injection arrive souvent près de la fin du document, parce que ça permet de modifier le DOM après le rendu principal.

Si vous voyez un script minifié avec un identifiant étrange, ou une URL qui ressemble à un domaine “de campagne” (parfois avec des chiffres, ou des lettres mélangées), notez-le. Ne le supprimez pas tout de suite, gardez la trace pour retrouver la source dans vos fichiers.

Construire une liste de recherche à partir des indices

Pour remonter à la cause, il faut des points d’ancrage. Si vous repérez des domaines externes dans le HTML servi, utilisez-les comme mots clés.

Par exemple, si vous voyez dans la page un script chargé depuis example-bad-domain.tld, vous allez chercher ce domaine dans:

les fichiers du thème et des plugins, les fichiers dans wp-content/uploads si des fichiers PHP ont été déposés par erreur, la base de données (options, postmeta, éventuellement commentaires).

Sur un incident, le domaine frauduleux n’apparaissait que deux fois dans le HTML, mais il était présent dans la base de données, sous forme encodée. Le script injecté récupérait une URL stockée dans une option. Tant qu’on ne repère pas l’URL, on tourne en rond.

Où regarder dans WordPress: les emplacements classiques d’injection

Une infection WordPress qui injecte des liens sortants s’installe souvent dans des zones précises, parce que ce sont des points de passage faciles.

Les endroits les plus “rentables” pour une recherche sont:

le thème actif et ses sous-thèmes (fichiers comme footer.php, header.php, functions.php, ou parfois des templates utilisés par des shortcodes), les plugins installés, surtout ceux qui ajoutent des champs, des shortcodes ou du rendu frontend, les fichiers dans wp-content/uploads si quelqu’un a tenté de déposer des payloads déguisés, la base de données, notamment les options et les métadonnées de posts.

Dans le cas de liens sortants frauduleux, on trouve fréquemment des hooks qui s’exécutent sur wp_footer, wp_head ou sur le rendu du contenu.

Un indice utile: si vous modifiez localement le thème et que vous ne voyez plus l’injection, mais que ça revient après activation d’un plugin de minification ou de cache, alors l’injection vient peut-être d’un champ modifié ailleurs, et le plugin ne fait que “le Lien vers le site Web laisser apparaître” plus vite.

Chercher dans les fichiers avec une méthode “douce”

La recherche dans le dossier WordPress est efficace si vous la faites sans tout massacrer. Vous pouvez utiliser un outil de recherche dans votre éditeur ou un utilitaire en ligne de commande.

L’idée est de chercher des motifs fréquents dans les infections, pas uniquement “http”. Les infections utilisent souvent:

des chaînes minifiées, avec eval( ou base64_decode, des appels à des fonctions de type “curl” ou “file _get_contents” sur des URL externes, des patterns comme document.createElement('script'), des window.location ou location.href dans des fichiers PHP contenant du JavaScript, des URL encodées ou des caractères “bizarres” mélangés.

Je préfère chercher aussi des fragments comme wp_footer, wp_head, add_action, shortcode, et des balises HTML ajoutées de manière non cohérente. L’objectif est de retrouver un endroit d’où part l’injection.

Si vous trouvez un fichier modifié récemment (modification au timestamp), c’est un bon candidat. Mais attention, un déploiement peut aussi changer les timestamps. Le bon réflexe est de comparer avec une version saine connue.

Vérifier la base de données quand les fichiers semblent “propres”

Parfois, les fichiers de votre thème et de vos plugins ne contiennent rien de suspect, et pourtant l’HTML servi est contaminé. Dans ce scénario, l’infection peut être dans la base.

Les zones typiques:

les options qui stockent un code ou une URL externe (par exemple options liées à un plugin), les champs de métadonnées liés à des pages ou des articles, parfois les commentaires ou des champs d’un builder, plus rarement, des tables caches de rendu si un plugin les reconstruit.

Pour vérifier sans paniquer, identifiez d’abord si le HTML servi contient une URL spécifique. Puis cherchez cette URL (ou un morceau) dans la base.

Techniquement, vous pouvez faire une recherche via phpMyAdmin, ou via une connexion SQL. Si vous utilisez phpMyAdmin, filtrez par table, commencez par les tables d’options et de métadonnées. Sur un site infecté que j’ai traité, le domaine frauduleux était dans un champ de postmeta, et c’est ce qui expliquait pourquoi certaines pages étaient touchées et pas d’autres.

Deux vérifications rapides avant de conclure

À ce stade, vous avez souvent des indices. Mais avant de “supposer” une infection, faites deux contrôles pragmatiques.

D’abord, regardez vos plugins de performance et de sécurité. Certains minifient le HTML, ajoutent des scripts externes légitimes (par exemple un CDN), ou injectent des scripts de monitoring. Un plugin peut ressembler à une infection si le code est minifié et si le domaine ressemble à un tracking.

Ensuite, vérifiez s’il y a un CDN ou un reverse proxy. Parfois, ce n’est pas votre WordPress, mais une couche entre le navigateur et le serveur qui ajoute un tag. Le HTML “que voit” l’utilisateur contient alors des éléments qui ne sont pas dans votre installation locale.

Ces vérifications vous évitent de supprimer le mauvais composant, ce qui est coûteux, surtout si vous n’avez pas de copie propre récente.

Une checklist pour confirmer les liens sortants frauduleux

Voici la partie qui sert vraiment sur le terrain, quand vous devez confirmer sans débat. Je vous conseille de la faire dans l’ordre, sur une page affectée.

Ouvrez une page affectée, inspectez le HTML final, notez chaque domaine externe présent dans script, iframe, img src, link href ou a href. Comparez avec le même rendu sur une page “saine” supposée, ou avec une page moins exposée. Cherchez un des domaines ou fragments notés dans wp-content/themes, wp-content/plugins, puis dans wp-content/uploads (si vous avez déjà vu des fichiers PHP suspects). Si rien ne remonte côté fichiers, cherchez le même fragment dans la base de données, en particulier les options et les métadonnées. Une fois la source trouvée, désactivez le plugin ou mettez en pause le thème incriminé (en staging si possible) pour valider que les liens disparaissent.

Cette séquence réduit énormément le risque de “faux positif”.

Le scénario fréquent: injection via hook du thème

L’un des schémas les plus courants, c’est l’ajout dans un fichier du thème d’un hook qui exécute un bout de code au chargement.

Un symptôme typique: l’injection apparaît uniquement sur certaines pages ou uniquement quand vous êtes connecté, parce que le hook est conditionné.

Si vous trouvez un code du type “fonction PHP qui imprime du JavaScript”, ce n’est pas forcément malveillant, mais c’est suspect si l’URL externe ne correspond à aucun outil que vous utilisez.

Mon réflexe est de vérifier la cohérence: le thème doit déjà contenir un rendu qui correspond à votre projet. Un ajout d’URL dans un endroit inattendu, par exemple au milieu d’un modèle qui ne sert pas à ça, est un drapeau rouge.

Le scénario alternatif: injection via plugin compromis

Quand l’injection passe par un plugin, vous verrez souvent des fichiers modifiés dans wp-content/plugins/nom-du-plugin. Parfois, l’infection est “cachée” dans un fichier qui n’est pas appelé normalement, mais qui est activé via une condition.

Il existe aussi des plugins où le code malveillant n’est pas dans les fichiers principaux, mais dans un dossier annexe, ou sous un nom trompeur. C’est pour ça que la recherche par mots clés sur des domaines frauduleux est plus efficace que la lecture manuelle.

Si vous suspectez un plugin, la validation doit être méthodique: désactivez-le sur une copie de votre site, ou via un plan de bascule minimal, puis vérifiez si le HTML ne contient plus les domaines externes.

Clarifier une zone délicate: la “suppression” sans récidive

Enlever le virus, ce n’est pas juste supprimer le fichier. Si la source est dans la base, il faut nettoyer les champs compromis. Si le plugin est compromis, il faut le remplacer par une version saine, pas uniquement supprimer une ligne.

Et si vous avez un accès administrateur compromis, le site peut être infecté à nouveau après restauration partielle, parce que le vecteur d’accès reste en place.

C’est souvent là que les délais explosent: on supprime la trace visible, et deux jours après, ça revient.

Pour éviter ça, traitez au moins trois points:

changements de fichiers, contenu dans la base, état des comptes et des clés d’authentification.

Sur un incident que j’ai géré, les liens sortants étaient revenus parce qu’un compte admin avait été créé à côté, puis supprimé une première fois. Ensuite, le code malveillant ne s’était pas rechargé via le même fichier, mais via un mécanisme d’écriture côté application.

Contrôler les comptes et l’accès, sans tomber dans le théâtre

Même si votre objectif est “enlever virus WordPress”, vérifier l’accès fait partie du diagnostic des liens sortants frauduleux. Les injections sont souvent la conséquence d’un accès ou d’une capacité d’écriture.

Sans partir dans une chasse aux sorcières, vérifiez:

les comptes utilisateurs, leurs dates de création et leurs rôles, les fichiers et dossiers modifiés récemment, les clés ou jetons de session si votre hébergeur fournit des outils.

Je vous conseille aussi de changer les mots de passe et de révoquer les sessions si votre gestionnaire d’hébergement le permet. Sur les sites que je maintiens, c’est un réflexe standard après un nettoyage.

Remettre le site sur des rails: échange des fichiers et tests

Une fois que vous avez identifié la source, l’étape suivante consiste à restaurer un état stable.

En pratique, il y a un compromis entre “réparer au plus juste” et “remplacer proprement”. Si un thème est custom mais contient un fichier compromis, on peut réécrire le fichier à partir d’une version de référence. Si le thème n’est pas custom et vient d’un fournisseur, le remplacer est souvent plus sûr.

Pour les plugins, même logique: quand vous suspectez une compromission, remplacez par une version connue et à jour, ou réinstallez. Gardez toutefois une copie du plugin suspect, juste pour archive interne et pour comprendre ce qui a été injecté.

Après restauration, testez sur plusieurs pages. Les infections ne touchent pas toujours tout le site. Une page peut être “propre” pendant que d’autres chargent encore le code.

Comment éviter les faux pas pendant l’enlèvement

Deux erreurs reviennent souvent.

Première erreur: chercher uniquement “des liens” dans les fichiers PHP, alors que l’infection injecte plutôt du JavaScript. Vous voyez les effets côté navigateur, mais le mot “http” peut être absent ou encodé.

Deuxième erreur: nettoyer une page sans nettoyer l’amorce. Exemple: vous supprimez des balises dans footer.php, mais la base continue d’injecter une option. Le résultat est un site partiellement réparé, qui “recontamine” après un certain hook.

La bonne approche, c’est de relier les symptômes à une source précise. Chaque domaine externe observé dans le HTML final doit, idéalement, correspondre à un emplacement dans vos fichiers ou votre base.

Après nettoyage: valider avec des tests concrets

Une fois “enlever virus WordPress” fait, faites une validation qui correspond à ce que les visiteurs voient.

Ouvrez plusieurs pages: home, article, page de catégorie, page où l’infection se montrait. Vérifiez que les scripts et iframes externes suspects n’apparaissent plus. Vérifiez aussi le comportement, pas seulement le HTML: pas de redirection, pas de chargement anormal, pas de latence liée à des scripts tiers.

Si vous avez accès à un outil de suivi réseau ou au moins à l’inspecteur “Network”, vérifiez les requêtes externes. Même si le HTML n’affiche plus le domaine, un script pourrait rester chargé via un autre chemin.

Enfin, gardez une trace: date du nettoyage, plugins modifiés, fichiers touchés, URL supprimées. Cela aide énormément pour le prochain audit, et pour expliquer l’intervention.

Et si vous ne trouvez rien dans les fichiers ni dans la base ?

Ce cas existe, et c’est frustrant. Mais il y a des explications plausibles:

le site n’est infecté qu’en production à cause d’une différence de configuration (cache, variables, règles du serveur), l’injection vient d’une couche externe (reverse proxy, CDN, WAF mal configuré), le code est injecté via un fichier “très petit” ou encodé et échappe à la recherche naïve, vous analysez un cache ancien et pas le rendu actuel.

Dans ce scénario, le bon réflexe est de comparer le HTML servi en temps réel. Si vous avez la possibilité d’accéder à une version staging, reproduisez la page, puis comparez. Si vous n’avez pas staging, travaillez avec un cache forcé contrôlé, ou faites des tests sur un environnement local si votre hébergeur le permet.

Dernier point: la sécurité n’est pas uniquement “pour ne plus être infecté”

Après avoir enlevé les virus et les liens sortants frauduleux, il reste une responsabilité pratique: réduire la surface d’attaque.

Je ne vais pas vous noyer sous des mesures générales, mais retenez ceci. Les infections WordPress arrivent souvent par un point faible répétitif: mot de passe faible, plugin obsolète, thème non mis à jour, ou compte administrateur inutile.

Sur un site qui avait déjà été nettoyé une fois, le vrai problème n’était pas le code injecté, c’était le plugin non mis à jour depuis des mois. Le nettoyage avait tenu trois semaines. Ensuite, l’infection revenait parce que la porte restait ouverte.

Le nettoyage, c’est le frein. La prévention, c’est la route.

Pour avancer maintenant

Si vous êtes au milieu d’un incident, commencez par le plus productif: repérez les domaines frauduleux dans le HTML servi, puis cherchez ces fragments dans vos thèmes, plugins et la base. Une fois la source identifiée, remplacez par des versions propres et valide sur plusieurs pages.

Si vous voulez, décrivez moi ce que vous observez, par exemple: quels types de liens externes apparaissent, sur quelles pages, et si vous avez un plugin de cache ou de minification. Je peux vous aider à cadrer les emplacements les plus probables et à éviter les fausses pistes.