Quand un site WordPress commence à rediriger les visiteurs vers des pages louches, ce n’est pas un détail “SEO” ou un simple plugin mal configuré. Dans beaucoup de cas, c’est le signe d’une compromission, parfois via une chaîne de malvertising, parfois via une injection dans le thème, le fichier functions.php, ou des scripts cachés dans la base de données. Le point commun, c’est la même sensation côté admin: “ça marchait hier”, puis aujourd’hui le navigateur affiche un changement de destination avant même que la page se charge correctement.
J’ai vu des cas où l’on pensait d’abord à un plugin de redirection, ou à un réglage de cache agressif. Mais dès qu’on observait des redirections systématiques, avec des URLs qui ne ressemblent à rien de légitime, la piste devenait plus sombre. Les attaquants aiment les scénarios qui passent inaperçus, notamment quand la redirection ne s’applique qu’à certaines sessions (par exemple, seulement sur mobile, ou https://gardewp.fr/nettoyage-malware-wordpress/ uniquement pour certains pays), ou seulement quand un header particulier est présent.
L’objectif de ce billet est de décrire une démarche réaliste de désinfection WordPress, centrée sur le traitement des redirections vers des sites frauduleux, avec des points d’attention sur les caches, les différences entre navigateur et serveur, et les pièges fréquents. On va parler concret, avec des choix qui dépendent du niveau de risque que vous êtes prêt à accepter.
Comprendre ce que vous voyez, vraiment
Une redirection malveillante peut se présenter de plusieurs façons.
Parfois, c’est une redirection HTTP directe: la réponse renvoie un statut 301 ou 302 vers une URL externe. D’autres fois, c’est une redirection côté navigateur, déclenchée par un script dans la page, un tag injecté, ou un faux chargement de ressource qui détourne le flux. Dans le contexte de malvertising, l’objectif est souvent d’envoyer l’utilisateur vers une page de “partenariat”, une fausse page de mise à jour, un site de “récompense”, ou une série de redirections en cascade.
Ce qui trompe, c’est que WordPress peut masquer ces signaux derrière des mécanismes légitimes:
- un plugin peut ajouter du javascript en front un thème peut inclure une balise script conditionnelle un CDN ou un plugin de cache peut servir une version altérée, même après correction une règle de réécriture dans .htaccess peut être modifiée de façon “propre” à l’œil nu
La première étape, avant de toucher à quoi que ce soit, c’est de caractériser le comportement.
Si vous pouvez, testez depuis un environnement “propre”: une fenêtre de navigation privée, sans extensions, avec un DNS standard. Prenez une capture de l’URL finale, pas seulement l’URL affichée au départ. Si possible, regardez aussi le chemin de redirection: est-ce que la destination commence toujours par le même domaine? Est-ce que ça change selon l’heure? Selon le pays? Selon le device?
Cette observation guide la suite: une redirection “à tout le monde” pointe souvent vers une altération de code dans le thème ou dans un fichier PHP, alors qu’une redirection “sélective” ressemble davantage à une logique côté script, ou à une condition basée sur des headers.
Les symptômes typiques d’une compromission
Il n’y a pas une signature unique, mais il y a des patterns qui reviennent.
Le plus courant, c’est une injection de code dans des endroits inattendus. Par exemple, un fichier du thème modifié alors que “personne n’y a touché”. Ou une entrée dans la base de données, dans des options, des shortcodes, ou des métadonnées, qui finit par sortir sur certaines pages uniquement.
Un autre scénario fréquent: un “drop” dans un fichier PHP minifié, avec un contenu qui ressemble à du code valide mais qui exécute en réalité une charge utile. Les attaquants aiment réduire la taille et casser la lisibilité.
Enfin, le troisième pattern, plus vicieux, est la persistance via le mécanisme WordPress: création d’un compte administrateur caché, modification d’un plugin “proche” du bon, ou ajout d’un contenu dans un champ qui sert de gabarit.
Le point clé est que la redirection peut être la partie visible de la compromission, mais pas forcément le seul problème. Si le code injecté est là, il peut aussi exfiltrer des données, déposer d’autres scripts, ou modifier des formulaires.
C’est pour ça qu’une “désinfection minimale” qui supprime seulement la redirection peut échouer à moyen terme. On corrige d’abord la cause, puis on vérifie que la persistance a disparu.
Isoler le niveau de la redirection: HTTP, script, ou règle serveur
Avant de réinstaller quoi que ce soit, j’ai pris l’habitude de répondre à une question simple: la redirection se fait-elle avant le rendu de la page, ou après?
Vous pouvez le faire de façon pragmatique:
- Si la redirection se déclenche immédiatement, même avec javascript désactivé, cela évoque une redirection serveur ou une réponse HTTP modifiée. Si la page s’affiche brièvement puis bascule, ou si la destination apparaît après quelques secondes, cela évoque un script injecté. Si une seule URL est touchée, alors que le reste du site est sain, cherchez une injection dans le template de cette section, ou un gabarit de page spécifique. Si toutes les pages renvoient vers la même destination, alors cherchez un mécanisme central: header template, functions.php, un plugin chargé tôt, ou un fichier chargé à chaque requête.
Pour aller plus loin, utilisez vos outils de diagnostic. Les navigateurs ont des vues “réseau” qui montrent l’enchaînement des requêtes. Côté serveur, vous pouvez aussi observer les en-têtes de réponse. Le but n’est pas de devenir analyste malware, mais de savoir où agir en priorité.
Quand j’ai affaire à des redirections “en cascade” vers plusieurs domaines, je privilégie la piste “script injecté”, car les attaquants peuvent charger un script distant qui orchestre la suite. À l’inverse, quand je vois des statuts 301 sur toutes les ressources, j’irai d’abord vérifier les fichiers de configuration serveur, comme .htaccess ou des règles dans Nginx.
Protocole de désinfection WordPress orienté redirections
Il existe une tentation: “je réinstalle WordPress”, “je change le mot de passe”, et j’espère. Parfois ça suffit, mais si la base de données ou une config serveur est restée polluée, la redirection revient.
Le protocole ci-dessous vise un équilibre entre vitesse et rigueur. Il ne remplace pas une réponse à incident complète, mais il couvre la plupart des cas rencontrés.
Un plan d’action court mais structuré
Mettre le site en quarantaine: au minimum, limiter l’accès pendant l’analyse, ou désactiver temporairement les pages publiques si votre activité le permet. L’idée est de réduire la contamination des visiteurs pendant que vous nettoyez. Sauvegarder proprement: récupérez une copie complète des fichiers WordPress (y compris thèmes et plugins), ainsi qu’un dump de la base de données. Gardez aussi les logs du serveur et, si vous en avez, les journaux de votre reverse proxy ou CDN. Comparer et inspecter: vérifiez les fichiers modifiés récemment, puis inspectez les points d’entrée classiques (thème actif, functions.php, plugins muets chargés tôt, fichiers chargés via include). Ciblez les injections de scripts, les “base64” et les fonctions d’exécution inhabituelles. Contrôler la base de données: cherchez les changements dans les options, les champs de contenus injectés, et toute trace de code dans des endroits où WordPress n’attend pas du code exécuté. Restituer un état propre puis vérifier: remplacez WordPress et les thèmes par des versions fiables, désactivez les plugins tiers, puis réactivez progressivement après vérification de l’absence de redirection.La nuance importante: remplacez ce qui peut être remplacé sans perdre de votre contenu. Le cœur WordPress se réinstalle facilement. Le thème et les plugins, c’est plus délicat si vous avez des modifications custom. Dans ce cas, vous pouvez choisir une approche “diff” via contrôle de version, ou une revalidation manuelle des fichiers.
Ce qu’il faut inspecter en priorité (quand vous êtes sur WordPress)
Sur un site WordPress, l’injection utile finit souvent par être déclenchée au bon moment. Cela signifie que les attaquants modifient des fichiers qui se chargent presque à chaque requête.
Les zones que je contrôle en premier, dans un ordre pragmatique, sont:
- le thème actif (et ses dépendances) notamment functions.php et les fichiers de template le header output (fichiers qui construisent la partie head) les plugins qui se chargent très tôt, ou qui ont des hooks sur wp head, wpfooter, ou le rendu de contenu des éléments de base de données qui contiennent des fragments injectés, par exemple des options de type “code” utilisées par un thème ou un plugin les fichiers de configuration de l’hébergement, notamment .htaccess et tout fichier de redirection
Quand vous examinez du code, cherchez des signaux plutôt que des “preuves”. Des patterns comme du code très compact, des appels à fonctions de création de chaînes bizarres, ou la présence de chaînes longues sans rapport avec votre projet. Les attaquants masquent souvent des URL externes, des fragments d’HTML, ou des éléments javascript.
Un piège classique: vous trouvez un “petit ajout” qui semble anodin, une ligne qui inclut un script distant. Vous l’enlevez, ça cesse de rediriger en partie, mais la base reste infectée. Résultat: les redirections reviennent via une autre page, ou plus tard quand un cache expire.
D’où l’étape “vérifier” à la fin, sur plusieurs pages et plusieurs navigateurs, avec cache nettoyé.
Redirection, cache et CDN: pourquoi ça persiste même après nettoyage
Je l’ai déjà vécu après suppression d’injections: “c’est revenu”. Pas une semaine plus tard, mais parfois dès la minute suivante, parce que le cache servait une ancienne version.
Sur WordPress, vous pouvez avoir plusieurs caches:
- cache interne du serveur cache de page via un plugin reverse proxy ou CDN cache d’objets cache navigateur côté visiteur
Si la redirection est dans le HTML final, un cache de page peut conserver la version altérée, même après correction des fichiers. Si la redirection est dans une ressource script injectée, un cache d’assets peut aussi prolonger le problème.
Pour éviter de tirer de mauvaises conclusions, je recommande de:
- vider les caches du site (plugin cache, cache objet si utilisé) purger le CDN si vous en avez un tester en navigation privée, pour réduire l’effet cache navigateur tester aussi avec un paramètre qui force une re-génération (quand c’est possible)
Il arrive aussi que le script injecté soit dans une version mise en cache de page pour une URL précise. Vous corrigez globalement, mais seules certaines pages semblent saines, d’autres redirigent. C’est cohérent, et ça ne veut pas dire que vous avez raté un morceau. Ça veut dire que la “surface” infectée était plus large ou plus ancienne que la correction.
Sécuriser l’accès: mots de passe, sessions, comptes
Une désinfection n’est jamais complète sans mesures de sécurité. Les redirections n’ont de sens que si la compromission a permis de modifier votre site. Une fois que vous nettoyez, vous devez empêcher l’attaquant de revenir.
Sans tomber dans la paranoïa, il y a des actions simples et efficaces:
- changer tous les mots de passe des comptes WordPress, y compris ceux qui ne sont pas admin si vous en avez invalider les sessions (sur certains hébergements, vous pouvez forcer la déconnexion) vérifier la liste des utilisateurs, supprimer ceux qui n’ont pas de raison d’être contrôler les plugins et thèmes actifs, et désactiver tout ce qui n’est pas nécessaire pendant la période de stabilisation vérifier les clés et configurations sensibles
Le point délicat, c’est quand vous utilisez un SSO ou un outil externe. Si votre WordPress ne s’authentifie pas directement, il faut aligner les actions sur l’identité réelle, sinon vous changez bien vos mots de passe WordPress, mais l’accès revient par l’autre canal.
Mesures de diagnostic: où chercher la trace dans le code
Vous allez sûrement trouver des “indices” avant même de confirmer. Le but est de ne pas vous perdre dans 200 fichiers.
Pour garder le focus, je recommande un chemin de recherche orienté “sortie navigateur”. Si la redirection se fait via script, il y a très probablement un endroit qui injecte du contenu côté HTML.
Cela peut être:
- un appel wp enqueuescript ou wp enqueuestyle sur un script qui pointe vers un domaine suspect une balise script construite dynamiquement du code qui écoute un événement, puis change location.href
Quand vous inspectez, ne cherchez pas uniquement des mots comme “redirect”. Les attaquants évitent l’évidence. Parfois ils stockent des fragments URL en base64, parfois ils concatènent des morceaux de chaînes, parfois ils utilisent des variables qui ressemblent à des options normales.
Voici une petite liste de signaux qui reviennent souvent dans des injections réelles, sans que ce soit un diagnostic absolu:
- présence de scripts externes vers des domaines sans lien avec votre activité construction dynamique d’URL avec des fragments obscurs (concaténations, encodages) utilisation de fonctions ou flux inhabituels dans le thème ou functions.php tailles de fichiers ou temps de modification incohérents, par rapport à votre historique code “minifié” ou pseudo-aléatoire dans des zones éditables autrement
Cette liste aide à prioriser, mais vous devez confirmer par la logique et le point d’exécution.
Cas particuliers: redirection seulement sur certaines pages
Un cas fréquent est la redirection qui ne touche qu’un sous-ensemble du site. Par exemple, uniquement la page d’atterrissage, ou seulement les articles d’une catégorie.
Quand j’observe ça, je pense souvent à une injection dans un gabarit spécifique, comme un template page.php, un fichier du thème qui gère les templates de contenu, ou un composant de shortcode. Les attaquants exploitent WordPress parce que le thème produit l’HTML, et un shortcode peut être injecté même sans changer le reste du système.
Il faut aussi considérer un plugin de builder ou un thème framework. Certains frameworks permettent d’insérer du code custom via des options, et si une option est compromise, l’injection peut être contenue dans des champs d’apparence “admin” mais qui finissent par sortir dans le head.
Dans ce contexte, un nettoyage global “remplacer le thème” peut être coûteux. Si vous avez un thème modifié avec des fonctionnalités importantes, la revalidation manuelle est parfois plus rapide que la reconstruction complète, à condition de bien tracer ce qui sort.
Une règle d’expérience: si la redirection est contenue dans un template ou un champ spécifique, commencez par isoler cette sortie et corriger la source exacte. Sinon, vous allez réinstaller en masse et perdre du temps sur une cause qui n’est pas là.
Cas particuliers: la redirection vient du serveur, pas de WordPress
Tous les redirections ne viennent pas du code WordPress.
Sur certains hébergements, un attaquant peut modifier .htaccess, ajouter des règles de rewrite, ou injecter des directives. Cela ressemble parfois à une configuration “normale”, surtout si l’attaque a modifié un bloc particulier.
Le symptôme typique: même des endpoints qui devraient être statiques, comme wp-login.php ou certains fichiers images, déclenchent la redirection. Dans ce cas, cherchez côté serveur.
Je fais en général:
- une comparaison de .htaccess (et de toute configuration équivalente selon votre stack) une recherche des domaines de destination dans l’ensemble des fichiers une inspection des logs pour voir d’où vient l’enchaînement de réponse
Une règle pratique: si la redirection se produit avant le rendu du thème, elle ne peut pas venir uniquement d’un fichier PHP dans le thème. Elle peut venir du serveur, du cache, ou d’un niveau proxy.
Réinfection: comment éviter de “nettoyer puis rechuter”
Après désinfection, la rechute se produit pour deux raisons principales: persistance non supprimée, ou vecteur d’entrée pas corrigé.
Vecteur d’entrée signifie: faille d’un plugin non mis à jour, thème abandonné avec vulnérabilité connue, mot de passe réutilisé ailleurs, ou accès exposé via un compte admin compromis.
La désinfection sans correction du vecteur, c’est comme remplacer un fusible sans corriger la cause du court-circuit. Ça marche une fois, puis ça recommence.
Côté pratique, je recommande de:
- mettre à jour WordPress, thèmes et plugins uniquement après avoir stabilisé le système retirer temporairement les plugins non indispensables, surtout ceux qui injectent du code en front renforcer la sécurité d’accès (authentification forte si possible, limitation d’accès, surveillance) surveiller la charge serveur et les pics inhabituels, car des scripts malveillants peuvent générer un comportement réseau étrange
Ne prenez pas une décision “au hasard” quand vous réactivez des plugins. Réactivez par lots restreints, testez, puis avancez. Sur un site qui redirige, chaque plugin peut être un multiplicateur.
Une méthode de validation: vérifier sans se tromper
Avant de “remettre en ligne”, il faut valider. Le plus simple est de tester plusieurs URLs, pas seulement la page d’accueil.
Je fais généralement un contrôle sur:
- page d’accueil page d’article ou page type wp-login.php (si accessible, en test de redirection) une URL image ou CSS une URL qui déclenche le type de gabarit suspect
L’objectif est de vérifier que la redirection ne se déclenche plus sur les points d’entrée connus.
Pour gagner du temps, vous pouvez aussi enregistrer l’URL finale vers laquelle le site renvoyait les visiteurs. Puis vous testez que cette URL n’apparaît plus dans les redirections. C’est un test simple et utile, tant que vous le faites sur un environnement nettoyé (navigation privée, cache purgé).
Quel niveau de réparation choisir: correction ciblée ou restauration complète
Entre correction ciblée et restauration complète, le choix dépend de la situation.
Si vous avez une sauvegarde saine et récente, et que le site n’a pas de modifications complexes, une restauration complète peut être la voie la plus rapide et la plus sûre. Vous limitez l’incertitude.
Si vous n’avez pas de bonne sauvegarde, ou si le site est très custom, la correction ciblée prend plus de temps mais peut préserver votre travail. Dans ce cas, la clé est de prouver que la persistance est partie. Vous ne pouvez pas vous contenter de “ça ne redirige plus sur ma page”. Il faut tester plusieurs surfaces et inspecter les points d’exécution.
Un compromis que j’ai souvent utilisé: restaurer le cœur WordPress et les thèmes et plugins non custom, puis traiter les custom avec un audit. Cela réduit énormément la surface à risque.
Sécurité au quotidien après la désinfection
Une fois le site propre, vous devez réduire la probabilité d’un retour. Ce n’est pas du “moral”, c’est du travail d’hygiène.
Voici ce qui change concrètement après une attaque par redirection:
- vous limitez les plugins à ceux qui sont réellement nécessaires vous gardez un rythme de mise à jour, même si c’est par petites vagues vous imposez une gestion stricte des rôles, seuls les comptes de confiance peuvent modifier les options vous surveillez les changements, par exemple en comparant les fichiers avec votre historique
Le gain de cette discipline, c’est que la prochaine fois qu’il y a une anomalie, vous identifiez beaucoup plus vite ce qui a changé et quand. Et vous ne repartez pas de zéro.
Quand faire appel en urgence
Si vous constatez des redirections vers des sites manifestement frauduleux, que le volume de trafic semble toucher des visiteurs en nombre, ou que vous voyez des signes additionnels comme des formulaires modifiés, des erreurs réseau inhabituelles, ou des comptes ajoutés, ne traînez pas.
Le point de bascule, c’est aussi l’impact métier. Un site qui redirige peut être pénalisé dans l’écosystème, et surtout il abîme la confiance. Même si vous nettoyez rapidement, le mal est parfois déjà fait côté perception.
Une désinfection WordPress sérieuse, orientée redirection et persistance, se fait mieux quand vous gardez une trace de tout: fichiers modifiés, entrées supprimées, actions de sécurité, et résultats de tests avant réouverture.
Ressources internes utiles pour votre équipe
Si vous travaillez avec une équipe, je recommande de consigner le diagnostic et la correction sous forme de notes internes. Pas comme un https://gardewp.fr/ roman, plutôt comme une fiche opérationnelle: date, comportement observé, domaines de destination, fichiers touchés, paramètres changés, tests effectués après correction.
Sur des incidents similaires, ce “journal” réduit la charge mentale. Vous évitez aussi que quelqu’un réactive un plugin “parce que ça marchait avant”, sans comprendre que c’est peut-être le plugin qui a ouvert la porte.
En pratique, ça veut dire aussi documenter votre procédure de sauvegarde et votre stratégie de cache, parce que beaucoup de redirections “fantômes” après nettoyage viennent d’une version servie par un cache.
Si vous êtes en train de traiter un site actuellement redirigé vers des domaines frauduleux, dites-moi ce que vous observez concrètement: la destination ressemble à quoi (même une description), si la redirection arrive avec javascript désactivé ou pas, et si c’est toutes les pages ou seulement certaines. Avec ces éléments, je peux vous aider à prioriser les zones à inspecter et à choisir entre correction ciblée et restauration plus large, pour une désinfection WordPress plus fiable.