Dans WordPress, une redirection malveillante ne ressemble pas toujours à un virus qui crie “danger” sur la page. Parfois, c’est un comportement très fin: la page charge, puis bascule vers un autre domaine, ou bien l’internaute est envoyé vers une URL différente selon le navigateur, la géolocalisation ou même l’heure. Ce genre de modification peut tenir dans quelques lignes de code injectées, un fichier “bizarre” dans un répertoire rarement utilisé, ou une règle ajoutée dans un fichier .htaccess trop permissif. Et tant que vous ne contrôlez pas le chemin, vous pouvez tourner en rond avec des symptômes qui s’aggravent.
J’ai vu des cas où la “détection” était en fait une série de réponses partielles: un nettoyage incomplet, un plugin réinstallé, puis une rechute quelques jours plus tard. Ce qui a fait la différence, ce n’est pas seulement de scanner malware WordPress. C’est de combiner plusieurs angles: observer le trafic, inspecter les points d’exécution (fichiers, hooks, thèmes, plugins), vérifier les redirections réellement déclenchées, et s’assurer que le correctif tient après remise en état et durcissement.
À quoi ressemble une redirection malveillante, côté utilisateur
Le premier signal est souvent indirect. Un visiteur signale que “ça redirige” ou que “la page est devenue bizarre”. Selon l’attaque, la redirection peut se produire:
- immédiatement, dès la soumission d’un formulaire de connexion ou d’un panier, au bout de quelques secondes (un script qui charge un redirect plus tard), seulement pour certains profils (utilisateurs connectés, comptes précis, ou navigateurs), seulement sur certaines pages (un article précis, une page d’accueil, des pages tag/catégorie), en fonction du referrer (par exemple, depuis un moteur de recherche).
Le détail important, c’est que vous pouvez avoir une infection qui ne se manifeste pas dans votre navigation habituelle. Si vous testez uniquement depuis votre poste, en réseau de confiance, avec votre compte administrateur, vous risquez de ne jamais déclencher le comportement. C’est la raison pour laquelle la “preuve” doit venir de données: logs, requêtes observées, et inspection des mécanismes WordPress.
Les mécanismes les plus courants sur WordPress
Les redirections malveillantes ont plusieurs façons de s’exprimer. L’erreur classique, c’est de chercher uniquement dans un fichier PHP injecté en plein milieu. Dans la pratique, les attaquants exploitent des points où WordPress exécute déjà du code et où l’intégrité est moins surveillée.
Sur WordPress, je vois souvent trois familles de causes:
Injection dans le thème ou un fichier de modèle
Un fichier du thème, parfois dans un sous-répertoire inattendu, contient du code qui surveille des conditions (user agent, cookie, IP, URL courante) puis envoie un Location: vers une URL externe.Modification de .htaccess ou règles webserver
Sur Apache, .htaccess peut contenir des règles de redirection ou des réécritures conditionnelles. Même si WordPress “gérait” vos liens permalinks, un fichier modifié peut forcer des chemins spécifiques vers une destination externe.Hooks WordPress détournés (actions, filtres, chargement conditionnel)
Une infection peut ajouter un add_action ou add_filter sur un hook de type “avant affichage”, “init”, ou “template_redirect”. Le code reste discret, il attend un contexte précis, puis déclenche la redirection.Il arrive aussi que tout soit “propre” à l’œil dans les fichiers, et que la redirection passe par une ressource externe chargée depuis une balise script ou une iframe. Là encore, le scanner peut vous dire “malware détecté”, mais la compréhension vient de l’analyse des conditions d’exécution.
Pourquoi un simple scanner ne suffit pas
Un outil de scan est utile, parfois décisif, mais il a ses limites. Selon l’outil et sa méthode, il peut:
- détecter un motif connu sans comprendre si le comportement de redirection est réellement en place, signaler un fichier “suspect” sans confirmer l’impact, rater une logique construite dynamiquement (par exemple, une URL construite à partir de fragments), déclencher des faux positifs si une partie du code ressemble à des signatures connues.
Dans les situations réelles, je traite le scan comme une cartographie, pas comme un verdict final. Le bon réflexe consiste à faire trois choses dans cet ordre: identifier ce qui a été modifié, vérifier les redirections réellement déclenchées, puis valider que le correctif bloque le mécanisme sur plusieurs scénarios de test.
Collecter des preuves avant de “nettoyer à l’aveugle”
Avant de supprimer ou remplacer, prenez le temps de collecter des indices. Vous gagnerez des heures plus tard.
L’objectif est simple: comprendre quel mécanisme déclenche la redirection, et sur quel périmètre. Si vous effacez d’abord, vous perdez des informations précieuses sur les chemins exacts.
Ce que je vérifie en premier (sans tout casser)
Je commence par observer le comportement de la page depuis plusieurs contextes. Pas besoin d’être parano, mais il faut sortir de sa routine.
Ensuite, je fais remonter les données côté serveur: journaux d’accès, erreurs, et événements applicatifs. Souvent, les redirections génèrent des codes HTTP (par exemple des 301/302) et des URLs de destination qui apparaissent dans les logs. Même si le trafic est “propre” sur une page, un pattern dans les logs peut révéler que seules certaines routes sont ciblées.
Enfin, je regarde les fichiers et paramètres qui ont un pouvoir de redirection: thème actif, fichiers du thème enfant, .htaccess, et toute zone où le code peut être exécuté tôt dans le cycle WordPress.
Mini-checklist de diagnostic rapide
Avant de lancer un chantier de nettoyage, voici les points qui font gagner du temps. Je les traite comme un fil conducteur, pas comme une procédure figée.
- Tester la redirection depuis un contexte différent (navigation privée ou autre compte, au moins une fois). Relever l’URL de destination et l’instant où la redirection arrive (immédiat ou après chargement). Comparer le comportement entre deux pages de même type (par exemple, page d’accueil vs page article). Contrôler .htaccess et les fichiers du thème pour toute modification récente ou logique conditionnelle. Consulter les logs pour repérer les routes qui renvoient vers l’extérieur.
Si vous cochez ces éléments, vous avez déjà assez pour orienter le scan malware WordPress vers ce qui compte vraiment.
Détecter les redirections: approche “côté navigateur” vs “côté serveur”
Les redirections se voient d’abord dans le navigateur, puis se confirment au serveur. L’idéal est d’en faire une boucle.
Côté navigateur
Dans l’onglet réseau (devtools), vous pouvez repérer des requêtes qui changent d’hôte, ou des requêtes 30x vers un domaine non attendu. Ce qui est utile, ce n’est pas seulement le fait “il y a une redirection”, mais aussi le moment où elle se déclenche.
Si la redirection survient après un chargement, cherchez les ressources scripts, iframes, ou appels réseau qui peuvent être malveillants. Une page peut charger un script injecté, et ce script décide ensuite de rediriger.
Côté serveur
Côté serveur, la preuve la plus directe passe par les logs web. Une route qui renvoie vers l’extérieur, une modification de .htaccess, ou un script PHP qui déclenche une Location vont laisser des traces.
Si vous avez accès aux journaux d’erreurs, regardez aussi les traces de warning, fatal, ou des erreurs temporaires qui auraient pu être introduites par l’infection. Une infection “agressive” laisse souvent un peu de bruit, même quand elle veut rester discrète.
Vérifier les fichiers à risque: thème, plugins, et chargement
Une fois que vous avez un pattern de redirection, vous pouvez remonter à la source. Sur WordPress, je cherche en priorité des endroits qui peuvent se déclencher très tôt.
Le thème (et le thème enfant)
Le thème actif est un terrain classique. Même une modification minuscule peut provoquer une redirection massive. Je passe en revue:
- fichiers principaux du thème, templates, fichiers chargés au démarrage, et, surtout, tout code ajouté récemment.
Les infections dans les thèmes sont parfois “habillées” dans des conditions qui ne s’activent que pour certains cas. D’où l’importance d’avoir testé plusieurs contextes avant.
Les plugins
Un plugin peut aussi déclencher une redirection. Deux cas se présentent souvent: soit un plugin a été compromis, soit un malware a été ajouté sous forme de nouveau plugin.
Quand vous examinez les plugins, faites attention aux détails: fichiers temporaires, noms de répertoires inattendus, tailles de fichiers incohérentes, ou code qui manipule des URL de façon conditionnelle.
Chargement et hooks
Le code peut être installé via des hooks, ce qui rend le comportement très subtil. Dans ce cas, le code est souvent dans un fichier PHP “banal” (dans un plugin ou un fichier ajouté), et la redirection apparaît via un hook comme init, template_redirect ou des filtres liés au contenu.
C’est là qu’un scanner malware WordPress peut être utile pour repérer les fichiers à examiner, mais pas pour vous dispenser d’inspection: vous voulez comprendre la condition d’exécution.
.htaccess: la porte d’entrée quand tout redirige
Sur Apache, .htaccess est un levier fort. Une modification peut provoquer une redirection sur un large ensemble de pages, ou seulement sur certaines URL.
Quand je vérifie .htaccess, je fais attention à des éléments comme:
- règles RewriteRule ou Redirect, conditions basées sur l’URL, l’agent, ou un cookie, et toute directive qui n’a aucun sens par rapport à vos réglages permalinks.
Un point d’expérience: parfois .htaccess n’est pas directement “déclaré” comme malveillant. Il contient des règles qui ressemblent à du réécriture standard, mais la destination contient un domaine externe ou un chemin “catalogue” typique.
Si vous suspectez .htaccess, sauvegardez l’état actuel, puis comparez avec une version connue (par exemple, une sauvegarde avant incident). Le but, ce n’est pas de “casser” le site, c’est de comprendre la règle qui a changé.
Utiliser un scanner malware WordPress: comment le faire proprement
L’usage d’un scanner dépend de votre environnement (hébergement, accès au filesystem, taille du site, présence de sauvegardes). Mais la logique reste la même: minimiser le bruit, maximiser la fiabilité de la piste.
Voici comment je l’aborde sur des projets concrets:
- Scanner ciblé d’abord: thème actif, thème enfant, plugins actifs, dossiers d’upload, racine du site, et fichiers de configuration web. Scanner de cohérence ensuite: vérifier les fichiers modifiés et les différences par rapport à une référence (commits Git, archive, ou installation WordPress connue). Validation après correction: refaire un scan, puis tester la redirection dans plusieurs contextes.
Le point qui revient toujours: un scan peut confirmer qu’un fichier est suspect, mais la correction doit être testée avec le scénario de redirection. Sinon, vous risquez de traiter le symptôme, pas la cause.
Quand le malware est discret: cas où le site “semble normal”
Il y a des infections qui se manifestent seulement pour un groupe de visiteurs. Dans ces cas, vous pouvez avoir un site accessible, une navigation “correcte” pour votre compte, et pourtant une partie du trafic est redirigée.
Pour détecter ça, je m’appuie sur les logs et je fais des tests variés. Un scanner peut ne pas déclencher une condition d’exécution, car son analyse se fait sur le code ou sur des requêtes “neutres”. Le bon réflexe consiste à:
- surveiller les routes où la redirection se produit, vérifier les conditions dans le code (chaînes, expressions régulières, cookies), et tester avec un agent utilisateur différent ou une session non connectée.
Le travail est un peu plus lent au début, mais il évite les fausses sécurités.
Signes d’accès compromis (et comment les distinguer)
Parfois, la redirection malveillante est le symptôme d’un accès compromis: un compte a été pris en main, un plugin a été installé, puis https://gardewp.fr/nettoyage-malware-wordpress/ un code a été injecté.
Distinguer “compromission” vs “infection purement technique” n’est pas toujours instantané, mais vous pouvez chercher des indices comme:
- comptes administrateurs créés récemment, changements de rôles, plugins ou thèmes ajoutés hors cycle habituel, changements dans les fichiers modifiés récemment.
Même si votre priorité est la redirection, traiter l’accès est indispensable, sinon la redirection reviendra. Un nettoyage de fichiers sans sécurisation des comptes revient à réparer un trou dans une chaussure tout en laissant le clou au même endroit.
Nettoyer et restaurer: logique de réparation durable
Une fois la cause identifiée, la réparation doit suivre une logique de continuité. Remplacer, pas seulement corriger, est souvent plus sain pour des fichiers de base (thème, plugins) surtout si vous ne savez pas quelle portion de code a été injectée.
Dans les situations que j’ai vues, la stratégie la plus robuste combine:
- suppression des fichiers ajoutés ou corrompus, remplacement des thèmes et plugins depuis une source connue, nettoyage des règles web (comme .htaccess) pour revenir à l’état attendu, vérification des paramètres et des comptes, puis durcissement.
Il faut aussi accepter un fait pratique: si vous n’avez pas de sauvegarde fiable, vous pouvez nettoyer “au mieux”, mais la preuve de l’absence de mécanisme latent passe par des tests de non régression et un scan post-correction.
Réduire le risque de rechute après correction
Après un incident, la rechute vient rarement de “l’infection” mystérieuse qui revient toute seule. Elle vient souvent de:
- identifiants faibles, plugins non maintenus, permissions trop ouvertes, absence de rotation de clés ou de révision des comptes, ou d’un accès qui n’a pas été totalement invalidé.
Je recommande aussi de vérifier l’activité récente des comptes (connexions, actions). Si vous constatez des connexions depuis des sessions inconnues, il faut traiter la compromission avant de repasser le site en production.
Durcir pour que la redirection ne reprenne pas
Le durcissement ne doit pas devenir une usine https://gardewp.fr/ à gaz. L’objectif est de réduire les points d’entrée qui permettent d’ajouter du code et de modifier des fichiers.
Sans faire une liste trop longue, je me concentre sur trois axes: mise à jour, contrôle d’accès, et surveillance.
Mise à jour ciblée
Mettre à jour WordPress, les thèmes et plugins actifs, mais aussi vérifier les dépendances. Le risque augmente quand la surface logicielle reste ancienne.
Contrôle d’accès
Réviser les comptes, forcer des méthodes d’authentification plus robustes quand possible, et limiter l’exposition des identifiants. Un incident de redirection se nourrit souvent d’un accès admin.Surveillance
Maintenir des journaux accessibles, et garder une routine de vérification des modifications de fichiers. Une alerte sur un changement inattendu peut vous sauver de semaines d’allers-retours. 
Un exemple concret: quand le scanner pointe le mauvais fichier
Je me souviens d’un cas où un scanner malware WordPress signalait un fichier dans un plugin, classé “suspect”. Le nettoyage a été fait sur ce fichier, mais la redirection persistait, et parfois, seulement pour des visiteurs externes.
La vraie cause était ailleurs: une règle dans .htaccess ajoutait une réécriture conditionnelle selon le chemin. Le fichier pointé par le scanner était un leurre ou un morceau d’un mécanisme incomplet. Tant que la règle web n’était pas corrigée, le comportement revenait.
C’est pour ça que je parle de boucle d’analyse: scan pour guider, inspection pour comprendre, logs pour confirmer, puis tests multi-contextes pour valider.
Où chercher quand vous êtes pressé
Si vous êtes en urgence, vous voulez une priorité claire. Je pense que l’urgence doit rester méthodique, même si vous travaillez “à chaud”.
Dans la pratique, je commence par:
- thème actif et thème enfant, plugins actifs, .htaccess et configuration web, dossiers d’upload si des scripts ont été déposés, puis comptes et actions admin.
Si la redirection est immédiate et globale, .htaccess et la couche thème sont souvent plus probables. Si la redirection est tardive ou conditionnelle, je penche davantage pour des hooks, scripts chargés au runtime, ou un code qui attend un contexte.
Vérifier que le site est “propre” sans se raconter d’histoire
Après correction, il faut vérifier avec un mélange de tests et de contrôles.
Je fais une validation en deux temps: d’abord le comportement attendu (aucune redirection vers l’extérieur, pages normales), ensuite l’absence d’activité suspecte dans les logs et les traces de modifications.
Un point subtil: certains malwares cessent de rediriger après suppression partielle, puis reviennent plus tard quand le code latent recharge une partie manquante, ou quand un accès compromis réinjecte le contenu. C’est pour ça que je recommande de planifier une surveillance sur une période raisonnable, plutôt qu’un simple “ça marche maintenant” et basta.
Les éléments à documenter pour l’analyse (et le futur incident)
Quand vous traitez un site WordPress après une redirection malveillante, votre meilleur allié, c’est la mémoire. L’attaque se répète parfois sous une autre forme, ou sur d’autres pages.
Voici les éléments que je consigne dès le diagnostic, puis après correction:
- l’URL d’origine qui redirige et l’URL de destination réelle, le moment approximatif et le type de visite déclencheur (connecté vs non, navigateur vs autre), les fichiers ou règles identifiés comme modifiés (chemin exact), les actions de correction effectuées (remplacement, suppression, révision de comptes), les résultats du scan et les tests de non régression réalisés.
Ce “petit dossier” aide énormément quand vous devez convaincre une équipe, ou quand vous héritez du site après vous.
Références internes: garder votre base de comparaison
Une bonne détection dépend souvent de votre capacité à comparer. WordPress n’est pas compliqué, mais un incident demande de savoir ce qui n’est pas normal.
Si vous pouvez, gardez:
- des archives des versions de thèmes et plugins que vous utilisez, des sauvegardes avant incident, et un historique des modifications de fichiers.
Je sais que tout le monde n’a pas ça. Mais même sans système parfait, des captures d’écran de configuration et des exports de plugins peuvent aider à identifier une dérive.
Détecter des redirections malveillantes sur WordPress, ce n’est pas uniquement “scanner malware WordPress et attendre un verdict”. C’est analyser un comportement, remonter à un mécanisme, corriger avec une logique de restauration, puis vérifier que la redirection ne se reproduit pas dans les mêmes conditions. Quand vous combinez logs, inspection ciblée, tests multi-contextes et réparation cohérente, vous réduisez fortement le risque de rechute, même quand l’infection semble disparaître d’un coup.