Quand on parle d’un WordPress infecté, on imagine souvent un malware “évident”, une redirection brute, un blocage du site, ou un avertissement qui saute aux yeux. En pratique, les infections sont parfois plus discrètes. Le cas que je rencontre le plus souvent, ce sont des liens cachés injectés dans le thème, parfois dans des fichiers PHP, parfois directement dans des fichiers de template, parfois au détour d’un champ “autoload” ou d’une zone de footer.
Le résultat est sournois : le site paraît correct, le contenu public est lisible, mais des visiteurs sont redirigés vers des pages douteuses, des navigateurs détectent des tentatives de scripts tiers, ou Google Search Console remonte des anomalies. Et surtout, si on ne traite pas la source, le nettoyage tient quelques jours, puis ça revient.
Ce guide part d’une idée simple : vérifier proprement, confirmer ce qui est réellement injecté, supprimer les liens cachés sans casser votre thème, et sécuriser pour éviter le retour.
Les symptômes typiques d’un thème “truffé”
On peut détecter un lien caché de plusieurs façons, mais souvent les indices se mélangent. Un thème infecté peut injecter des liens qui ne se voient pas dans l’interface, ou qui ne s’activent que dans certaines conditions (langue, agent utilisateur, pays, heure, requête referrante).
Dans des cas réels, j’ai vu :
- des liens qui ne s’affichent pas dans le HTML rendu, puis apparaissent dans “Voir le code source” après un cache côté serveur ou un minificateur, une anomalie légère dans le footer, comme un espace, un caractère en trop, ou un script “inocent” qui charge une ressource externe, des redirections qui ne touchent pas tout le monde, ce qui rend l’enquête plus lente.
Pour avancer vite, le plus efficace est de comparer. Quand un site a toujours eu un comportement stable, toute variation mérite une trace.
Avant de toucher aux fichiers : sécuriser l’enquête
Avant de supprimer quoi que ce soit, faites deux choses. La première, c’est de préserver des preuves. La seconde, c’est d’éviter de “brûler” le diagnostic en changeant trop de paramètres d’un coup.
Sur un WordPress classique, l’infection dans le thème se manifeste presque toujours au niveau du thème actif, mais parfois aussi dans les thèmes non actifs, ou dans un parent de thème (thème enfant inclus). D’où l’intérêt de travailler de façon structurée.
Je recommande aussi de préparer un environnement de diagnostic. Si votre site est en production, vous pouvez basculer temporairement en maintenance le temps de l’analyse. Cela limite les visites pendant que vous testez.
Mesurer l’ampleur : où regarder en priorité
Les “liens cachés” ne vivent pas seulement dans les templates. Ils peuvent être cachés dans des fichiers qui sont chargés tôt, parfois même au moment du chargement des options.
En général, je commence par vérifier :
Le thème actif et le thème enfant s’il existe, Les fichiers PHP qui contiennent des fragments de code inattendus (par exemple ajout d’un eval, d’un base64_decode, de requêtes HTTP, ou de concaténations étranges), Les fichiers qui servent à “framework” dans le thème, comme les include, les helpers, ou des modules custom, Les sorties front qui touchent au footer ou aux scripts (souvent le point d’injection le plus fréquent).L’idée n’est pas de “tout supprimer”, mais de trouver la ligne qui ne ressemble pas au reste.
Vérifier le site côté navigateur, sans tomber dans le piège du cache
Le navigateur aide, à condition de ne pas se faire piéger par le caching.
La méthode la plus utile que j’ai adoptée : inspecter la page et comparer.
- Ouvrez la page sur laquelle l’anomalie est visible. Affichez le code source. Ensuite, inspectez l’HTML dans le panneau “Elements” (DOM). L’écart entre le code source et le DOM après exécution des scripts peut révéler une injection dynamique. Désactivez le cache navigateur le temps du test. Testez aussi depuis une fenêtre privée.
Côté réseau, regardez l’onglet “Network”. Si votre thème charge une ressource externe étrange au moment où la page se rend, vous verrez au moins un domaine nouveau ou une requête atypique.
Si vous utilisez un outil comme un SAST léger ou un simple grep sur les fichiers, ce que vous repérez dans le navigateur doit ensuite être traçable dans le code.
Inspecter le thème : ce que l’on cherche vraiment dans les fichiers
Le code injecté dans un thème infecté ressemble rarement à suppression malware WordPress du code propre “de production”. Il peut être camouflé dans des chaînes concaténées, compressé, encodé, ou noyé au milieu d’un grand fichier.
Souvent, les signaux d’alerte sont :
- présence de chaînes encodées (base64) suivies d’un décodage, utilisation de fonctions de lecture dynamique ou d’exécution (par exemple eval, assert, preg_replace avec le mode exécutable, selon les cas), appels à des URLs dans des fonctions qui ne devraient pas faire de réseau, accès à des variables globales et conditions très spécifiques (langue navigateur, mobile, référent), ajout d’HTML ou de scripts dans des zones qui ne devraient pas les contenir.
Le point clé : dans WordPress, le thème a le droit d’ajouter des scripts et du markup. Donc ce n’est pas “un script externe” qui prouve l’infection. C’est le comportement, la cohérence, et la source.
Quand le thème charge une ressource externe que vous n’avez jamais mise en place, et que la requête s’accompagne de redirections ou d’une logique cachée, là, vous tenez quelque chose.
Méthode concrète pour trouver les liens cachés (sans tout casser)
À ce stade, vous avez probablement accès à vos fichiers via un client FTP/SFTP ou votre gestionnaire de fichiers. L’objectif est de localiser précisément les emplacements d’injection, puis de supprimer la partie malveillante.
Commencez par faire une copie de sauvegarde complète du thème actif et du thème enfant. Ensuite, isolez ce qui a le plus de chances d’injecter des liens : les points de sortie, typiquement le footer, les fichiers de layout, et les hooks.
Voici un petit plan d’action, simple mais efficace.
Checklist de diagnostic rapide
- Comparez les fichiers du thème actif avec une version connue (ZIP du thème d’origine, ou dépôt si vous le suivez). Recherchez dans les fichiers du thème les occurrences de chaînes encodées et d’appels inhabituels, par exemple base64_decode, eval, gzinflate, str_rot13, ou file_get_contents avec une URL. Inspectez les fichiers qui touchent au rendu de fin de page (footer.php et équivalents) et les includes chargés automatiquement. Vérifiez le thème enfant, car l’injection se fait parfois dans functions.php du child plutôt que dans le thème parent. Contrôlez aussi les thèmes non actifs, car WordPress peut encore charger des morceaux via des dépendances, et une installation peut contenir un reste de code.
Cette démarche vous donne déjà un axe. Une fois la zone identifiée, vous pouvez lire le code injecté ligne par ligne, puis décider du retrait.
Exemple de “lien caché” qui ne se voit pas dans l’interface
Souvent, l’injection ressemble à ceci conceptuellement : on ajoute un bout de HTML ou un script, mais il est dissimulé par CSS, par attributs, ou par conditions.
Par exemple, un lien peut être créé avec des styles qui le rendent invisible, ou placé dans un conteneur dont les classes ne sont pas utilisées par votre design. Un autre classique : l’injection n’ajoute pas directement un href visible, mais elle charge un script qui, lui, calcule une redirection.
Dans ce genre de cas, l’erreur courante est de supprimer seulement l’élément visible. Vous retirez la partie “affichage”, mais pas la logique qui reconstitue le lien ailleurs.
Donc, quand vous voyez un href suspect, cherchez aussi le code autour. Si vous détectez une fonction qui déclenche la redirection, supprimez la logique complète.
Vérifier les hooks WordPress et les injections via functions.php
Les infections qui passent par le thème s’appuient souvent sur le système de hooks. Dans un thème, functions.php peut accrocher un comportement au chargement de la page.
Ce que je cherche en premier dans functions.php :
- un ajout de hook à wp_footer, wp_head, ou à des actions globales, un code qui conditionne l’exécution selon des critères bizarres, une fonction déclarée dans un fichier, puis appelée seulement dans certaines conditions.
Par exemple, si vous voyez un hook vers wp_footer qui ne correspond à rien de votre configuration habituelle, et qu’il ajoute un script encodé, c’est un candidat direct. Un autre indice : les fonctions déclarées avec des noms courts, sans commentaires, et qui ne ressemblent pas au style du reste du thème.
Une fois trouvée, la suppression peut être délicate. Vous ne voulez pas enlever un morceau légitime si vous n’êtes pas sûr. Le bon réflexe consiste à comparer au thème original. Là où l’original ne contient pas la logique, vous pouvez retirer en confiance.
Quand ça revient : l’infection ne s’arrête pas au thème
Il existe un piège fréquent : vous nettoyez le thème, vous vérifiez que le site semble propre, puis une heure ou un jour plus tard, les liens cachés réapparaissent.
Quand j’ai vu ce scénario, ce n’était presque jamais “une simple trace” dans un fichier. Souvent, il y avait :
- un utilisateur compromis (compte admin, éditeur ou auteur) qui réinjecte via les éditeurs de thème, une porte dérobée dans un plugin, ou dans un mu-plugin, une tâche planifiée (WP Cron modifié) ou un script qui recharge le code, un fichier réinjecté à partir d’un autre endroit, par exemple via un nom de fichier masqué.
Donc la question n’est pas seulement “où est le code”. C’est aussi “qui peut le remettre”.
Passer en revue les utilisateurs et les droits
Même si votre symptôme pointe vers le thème, votre première responsabilité est de vérifier l’accès. Un thème infecté peut être la conséquence d’un accès, pas la cause.
Contrôlez les utilisateurs WordPress, surtout ceux qui ont des rôles élevés. Si vous trouvez un compte créé récemment, ou dont le login vous parle de façon suspecte, c’est une alerte directe.
Si vous avez la possibilité, forcez un changement de mot de passe pour les comptes clés, et supprimez ceux qui n’ont pas d’utilité. Faites-le proprement, puis vérifiez s’il reste des fichiers de code dans les zones sensibles.
Checklist sécurité après nettoyage
- Vérifiez tous les utilisateurs, supprimez ou verrouillez ceux créés récemment ou incompris. Changez les mots de passe des comptes à privilèges, idéalement avec des mots de passe uniques. Contrôlez les plugins et thèmes installés, supprimez ceux inutilisés ou non reconnus. Vérifiez la configuration d’upload, pour éviter qu’un dossier inattendu soit utilisé comme cache ou relais. Mettez en place un journal des changements, même léger, pour repérer la prochaine réinjection.
Cette étape peut sembler “hors sujet”, mais elle conditionne la durabilité du nettoyage.
Supprimer les liens cachés : procédure prudente et “réversible”
Une bonne suppression n’est pas forcément un effacement à l’aveugle. C’est souvent un mix entre remplacement propre et retrait ciblé.
La stratégie la plus sûre est souvent :
- remplacer les fichiers du thème par une version originale provenant de l’auteur, puis réappliquer vos personnalisations à partir de ce qui est connu et nécessaire (souvent via le thème enfant).
Si vous n’avez pas le ZIP d’origine, vous pouvez au minimum comparer les fichiers et retirer uniquement les segments qui ne sont pas cohérents. Mais ça demande du temps, et ça repose sur votre capacité à repérer le code injecté.
Une règle pratique que j’applique : si vous ne pouvez pas justifier un morceau de code par la fonctionnalité du thème (carousel, styles, fonctions custom), traitez-le comme suspect jusqu’à preuve du contraire.
Cas particulier : thèmes commerciaux, builders et “customisations” sensibles
Quand le thème est très personnalisé (builder, custom fields, CSS et scripts ajoutés), il est facile de casser des choses.
Deux approches s’offrent à vous :
- soit vous remplacez, mais vous maîtrisez l’origine des personnalisations (souvent par un thème enfant), soit vous retirez à la main, au risque de supprimer un bout “rare” qui n’avait pas l’air suspect au premier regard.
Dans les installations avec des builders, j’ai vu des infections qui se cachent dans des fichiers générés ou dans des caches. Il faut alors éviter de supprimer des fichiers indispensables. La meilleure défense reste de conserver une copie et de pouvoir restaurer rapidement.
Où se cachent les liens : les endroits les plus fréquents
Sans prétendre à l’exhaustivité, voilà les emplacements qui reviennent le plus souvent quand je fais des audits orientés nettoyage.
Le thème, d’abord. Puis ce qui lui est lié. Les injections sont fréquemment placées dans :
- footer.php ou des partials inclus depuis le footer, header.php lorsque l’injection démarre tôt et peut déclencher des scripts, functions.php pour brancher via hooks, des fichiers inclus via require ou include dans des dossiers du thème, parfois des fichiers “optionnels” chargés seulement quand certains paramètres WordPress sont présents.
Ce que vous voulez éviter, c’est de corriger seulement les symptômes dans le rendu. Si une injection passe par un hook, c’est dans le hook qu’il faut agir.
Vérifier que c’est vraiment propre, sans se satisfaire du “ça marche”
Après nettoyage, je recommande une validation par étapes. Sinon, vous pouvez retomber sur un faux positif.
D’abord, testez la page depuis plusieurs navigateurs, avec cache désactivé. Ensuite, regardez le HTML source et le DOM. Enfin, observez le réseau. Si vous ne voyez plus de domaines externes suspects, et que le code injecté a disparu des fichiers du thème, vous avez de bonnes chances.
Mais il reste un risque : un code injecté peut rediriger seulement sous certaines conditions. Par exemple, selon la présence d’un referer, selon une géolocalisation, ou selon l’heure.
Donc, faites des tests au moins dans deux contextes différents : une session “propre” et une autre en tenant compte du comportement que vous aviez remarqué (mobile, pays, navigation interne). Ce n’est pas glamour, mais c’est ce qui évite la rechute.
Nettoyer site WordPress infecté : ce que j’exécute généralement, de façon réaliste
Les mots “nettoyer site WordPress infecté” font souvent penser à un grand ménage unique. Dans les faits, je pense plutôt à un cycle : diagnostiquer, retirer, vérifier, puis durcir.
Le durcissement change tout. Si vous supprimez le code, mais que vous laissez une faille ou un compte compromis, vous payez la note deux fois.
Sur un chantier typique, je m’organise ainsi : récupération de l’origine des thèmes, copie des fichiers actuels, comparaison, suppression ciblée ou remplacement, puis contrôle des utilisateurs et des plugins. Ensuite seulement, je revalide le rendu.
Empêcher le retour : durcir le thème et l’environnement
La prévention ne consiste pas à ajouter dix plugins et espérer. Elle consiste à réduire les surfaces d’attaque et à rendre toute modification visible.
Quelques mesures pragmatiques que j’ai vues efficaces :
- Mettre à jour WordPress, thèmes et plugins, car les infections profitent souvent d’une faiblesse existante. Utiliser le thème enfant pour les personnalisations, afin de pouvoir remplacer le thème parent sans perdre le travail. Restreindre qui peut modifier les thèmes et plugins. Un seul compte “trop large” et vous payez. Surveiller les fichiers du thème, au moins de manière périodique, pour repérer des modifications inattendues. Éviter des droits d’écriture trop ouverts sur les fichiers système.
Les infections aiment le désordre. Un environnement bien cadré rend l’injection plus difficile.
Pièges courants pendant le nettoyage
Quelques erreurs qui coûtent du temps, je les cite parce qu’elles arrivent vite.
Première erreur : supprimer un lien apparent dans le HTML, puis oublier le script qui reconstruit tout. Si l’injection fonctionne via hook, supprimer le rendu ne suffit pas.
Deuxième erreur : remplacer le thème sans réappliquer les personnalisations légitimes, puis “réinstaller” des bouts de code par copier-coller. Si vous copiez aussi l’infection par inadvertance, vous recommencez.
Troisième erreur : considérer que “le thème est infecté” alors que le point d’origine est ailleurs. Un plugin compromis peut modifier des fichiers de thème. Les symptômes vous attirent vers le thème, mais la cause peut être ailleurs.
Plan de sortie si vous êtes bloqué : quand demander de l’aide (et quoi fournir)
Si vous ne trouvez pas clairement la logique d’injection, ou si le site refuse de rester propre, il faut passer en mode enquête approfondie, parfois avec un expert sécurité.
Ce qui aide énormément, c’est d’apporter :
- une ou deux URLs exactes où l’anomalie se produit, un exemple de domaine ou de script suspect repéré via Network, la date approximative où ça a commencé, vos versions WordPress, thème actif, thème enfant, plugins essentiels, et idéalement des exports de fichiers du thème (ou au minimum la partie que vous pensez suspecte).
Avec ça, l’analyse gagne un temps précieux.
Vérifiez, supprimez, puis validez sur le long terme
Nettoyer un site WordPress infecté, surtout quand les liens sont cachés dans le thème, demande une méthode calme. On ne joue pas au chirurgien en enlevant au hasard. On cherche la source, on retire la logique, puis on s’assure que personne n’a la possibilité de remettre le code.
Si vous appliquez une démarche de comparaison (avec une version originale), une vérification dans le navigateur (DOM et réseau), et une sécurité minimale côté accès (utilisateurs et droits), vous réduisez fortement le risque de rechute. Et si le thème doit être remplacé, faites-le avec une version saine, en gardant vos personnalisations dans le thème enfant.
C’est souvent moins spectaculaire qu’un “suppression miracle”, mais c’est ce qui tient dans le temps.