Un jour, tout marche. Le lendemain, votre site vous renvoie ailleurs. Pas vers une page d’accueil propre, pas vers une boutique partenaire, mais vers une destination étrange, parfois en plein milieu d’une navigation normale. Une redirection suspecte est souvent le signal le plus parlant après un piratage WordPress, et c’est aussi le plus piégeux, parce qu’elle peut être intermittente, difficile à tracer, et parfois déjà “nettoyée” partiellement par quelqu’un qui n’a pas compris ce qu’il fallait effacer.
Je suis déjà tombé sur des redirections déclenchées uniquement sur certains navigateurs, uniquement sur les versions sans cache, ou seulement quand l’utilisateur venait d’un moteur précis. Dans ces cas, vous avez l’impression que “ça a l’air revenu”, alors que des morceaux restent en place, prêts à réinfecter au prochain incident.
Voici une façon de raisonner quand vous suspectez un nettoyage virus WordPress, à partir du symptôme principal: des redirections inattendues.
Comprendre ce que vous observez, avant de supprimer au hasard
Une redirection suspecte n’a pas une seule origine. Sur WordPress, elle peut venir:
- d’un fichier injecté dans le thème ou un plugin, d’une modification de la base de données, d’une règle côté serveur (souvent plus rare si vous n’avez pas accès au serveur directement), d’un malware qui ajoute un script dans une zone précise, par exemple dans le footer ou dans le template des pages, ou même d’un plugin “légitime” qui a été compromis, ou d’un plugin installé via un mécanisme d’update.
Le point important, c’est que le symptôme seul ne suffit pas. Deux sites identiques peuvent être infectés différemment, et le “nettoyage virus WordPress” qui a marché sur l’un peut laisser l’autre vulnérable.
Si vous pouvez, observez le comportement avec une approche simple, sans outils complexes au départ: quel type de pages sont concernées, sur quelles requêtes, et avec quels signaux.
Voici quelques indices qui reviennent souvent dans les incidents réels.
- La redirection s’active uniquement quand on n’est pas connecté. Elle se produit sur toutes les pages, mais pas sur l’espace d’administration. Elle cible une URL en HTTP, alors que votre site est en HTTPS. Elle semble suivre un schéma, par exemple vers un domaine différent selon la langue du navigateur. Le navigateur affiche un avertissement de certificat, ou la page redirigée ressemble à une copie rapide.
Ces éléments orientent la piste. Par exemple, si l’administration n’est pas touchée, l’infection a peut-être des conditions dans le code, souvent liées au rôle, au type de requête, ou à la détection du user agent.
Réagir vite, sans casser le site pendant l’intervention
Quand un site commence à rediriger, le premier réflexe est parfois de “désactiver tout”. C’est tentant, mais ça peut aggraver la situation si le malware reste actif ailleurs, ou si vous coupez un plugin dont vous avez besoin pour récupérer des paramètres.
Ce que je privilégie en premier, c’est de réduire la surface de propagation tout en gardant la main sur l’analyse.
La question à vous poser est simple: est-ce que la redirection touche tout le monde, y compris les visiteurs qui consultent des pages statiques, ou est-ce que c’est limité à certains chemins? Si c’est général, la mise en quarantaine est souvent la meilleure option, ne serait-ce que pour éviter que Google, les navigateurs, et vos utilisateurs voient des choses incohérentes pendant que vous travaillez.
Si vous avez accès à votre hébergement, la mise en “mode maintenance” peut suffire à calmer le trafic, mais attention: certains malwares injectent des redirections au niveau global, même en maintenance, ou en ajoutant un comportement avant l’affichage de la page.
Une approche prudente consiste à:
Faire une sauvegarde complète (fichiers et base de données) avant toute modification. Geler les modifications côté administration (changement de mots de passe, mises à jour, installation de nouveaux plugins) jusqu’à avoir un minimum d’analyse et de contrôle. Isoler votre accès: connectez-vous depuis un environnement sain, et vérifiez que vous n’êtes pas en train de tester sur une session déjà compromise.La sauvegarde est un réflexe banal, mais dans les redirections suspectes, elle devient une assurance immédiate. Si vous supprimez un fichier au mauvais endroit, ou si vous corrigez une partie qui n’était pas la source, vous devez pouvoir revenir en arrière rapidement.
Rechercher la source: où se cachent les redirections dans WordPress
WordPress n’est pas un système “verrouillé”. Il s’appuie sur la structure des thèmes, des plugins, et surtout sur la base de données pour générer le contenu. Les redirections peuvent donc être injectées à plusieurs niveaux.
1) Fichiers modifiés dans les thèmes et plugins
C’est le cas le plus fréquent. On voit souvent des morceaux de code ajoutés dans:
- functions.php du thème actif, header.php ou footer.php, des fichiers “fantômes” ajoutés dans le dossier du thème, ou des fichiers dans des répertoires de plugins.
Le malware aime aussi les fonctions de type “callback” et les hooks WordPress. Une redirection peut être déclenchée au chargement, via un hook, ou uniquement sur des pages précises.
Si vous avez un accès FTP ou un gestionnaire de fichiers, cherchez les fichiers dont la date de modification ne correspond pas à vos mises à jour. Sur un site “normal”, les dates bougent rarement sans raison.
2) Base de données: options, contenus, et champs inattendus
Une infection peut stocker des scripts ou des URLs dans la base, pour éviter de toucher aux fichiers. On retrouve alors des changements dans:
- les options (souvent des paramètres “perdus”), les contenus de posts et pages si le pirate a injecté du HTML ou du JavaScript, des champs de type “shortcode” ou des métadonnées qui ajoutent un comportement au rendu.
Le symptôme typique est une redirection qui dépend d’une page en particulier, comme si le code était inclus dans un article ou une page.
3) .htaccess et règles serveur
Si votre site tourne sur Apache ou avec une couche de règles, une redirection peut venir de .htaccess. Dans ce cas, le code ne sera pas WordPress, mais une règle au niveau serveur.
Ce scénario est moins fréquent quand l’attaquant n’a pas accès au niveau fichier de manière étendue, mais il existe. Je l’ai vu quand la compromission venait d’un script qui écrivait directement des règles, ou quand un autre élément du système a été mal sécurisé.
4) Script injecté via une dépendance compromise
Parfois, ce n’est pas le thème, ni le plugin principal. C’est une dépendance: un script chargé en premier, un composant récupéré sur une URL externe, ou une balise ajoutée dans un endroit “banal” comme un champ de configuration.
Le piège, c’est que le navigateur peut vous donner une impression de “ça redirige parce que le site appelle une ressource”, alors que la ressource porte un script malveillant qui fait basculer la page.
Diagnostic pratique: relever ce que fait la redirection
Avant de toucher aux fichiers, j’essaye de documenter le comportement. Ça fait gagner des heures.
Je vérifie au moins:
- l’URL exacte où je me trouve et celle où je suis redirigé, la chaîne d’éventuelles redirections (parfois il y en a plusieurs), si la redirection s’active en navigation privée, si elle s’active avec ou sans cookies, et si le comportement change quand je change de réseau (par exemple mobile vs Wi-Fi).
Dans certains cas, ça n’aide pas, parce que l’attaquant ajoute des conditions basées sur la géolocalisation ou l’heure. Mais même là, vos notes permettent de constater une amélioration après un premier nettoyage.
Si vous avez un accès aux logs, même partiel, regardez les erreurs PHP et les accès aux fichiers inhabituels. Sans “sur-analyser”, cherchez les traces de requêtes répétées vers des https://gardewp.fr/ chemins qui n’existent pas chez vous.
La première action de nettoyage: sécuriser l’accès et couper l’attaque
Quand je parle de “nettoyage virus WordPress”, je vois souvent le travail réduit à supprimer le code. Pourtant, si vous ne sécurisez pas l’accès, le code peut revenir. Le pirate peut avoir laissé:
- un compte administrateur discret, des clés d’API ou des connexions, un mécanisme de persistance via un plugin ou un script planifié.
Avant de supprimer, sécurisez.
Changez les mots de passe, mais pas “à l’aveugle depuis une session potentiellement compromise”. L’idéal consiste à:
- sortir de la session douteuse, changer le mot de passe de tous les utilisateurs avec accès élevé, vérifier les rôles et les comptes existants, vérifier les connexions actives si votre hébergeur le propose.
Un détail qui compte: si le site est injecté et redirige, votre navigateur peut enregistrer des cookies et vous donner une sensation fausse. Testez après chaque changement en navigation privée, sans extension qui pourrait masquer les redirections.
Mini check de sécurité (avant nettoyage en profondeur)
Sauvegarde fichiers et base de données. Désactiver temporairement les plugins récemment ajoutés ou inconnus. Vérifier et supprimer les comptes administrateurs inattendus. Mettre à jour WordPress, thème et plugins uniquement après la phase de diagnostic. Contrôler l’accès FTP et les identifiants du panneau d’hébergement.Ce n’est pas une recette unique, mais sur des incidents de redirections, c’est la combinaison qui évite le plus de retours en arrière.
Nettoyer sans perdre de données: stratégie par étapes
Le nettoyage “efficace” suit une logique. Vous ne supprimez pas au hasard, vous éliminez la persistance une fois que vous avez trouvé la source probable.
Étape 1: isoler le thème et les plugins
Si la redirection se déclenche même quand rien n’est chargé, la source est peut-être serveur ou thème. Mais si elle se déclenche seulement sur certaines pages, un plugin ou une zone de rendu est plus probable.
Désactivez temporairement le thème actif? Ça dépend. Sur WordPress, changer de thème via l’interface peut être bloquant si vous êtes redirigé. Dans ce cas, faites-le depuis votre gestionnaire de fichiers.
L’idée est de retrouver un état où la redirection cesse, même partiellement. Si vous n’avez plus de redirection après désactivation d’un plugin, vous tenez un fil.
Attention au piège: un plugin compromis peut réinjecter du code au moment où WordPress s’initialise. Donc, même si la désactivation semble “réparer”, vérifiez toujours les fichiers associés.
Étape 2: inspecter les fichiers modifiés et les hooks
Quand vous identifiez un fichier suspect, ne vous contentez pas de supprimer une ligne. Regardez le contexte:
- Quel hook est utilisé? La redirection est-elle conditionnelle (page précise, rôle, user agent)? Y a-t-il d’autres fonctions “camouflées” dans le même fichier?
Je me souviens d’un cas où une redirection était déclenchée seulement pour les utilisateurs non connectés, mais le code ajoutait aussi une tâche planifiée. Supprimer la redirection seule avait “réglé le symptôme”, pendant une journée, puis le site a recommencé dès que la tâche a tourné.
Donc, inspectez aussi les morceaux qui semblent “inactifs”.
Étape 3: vérifier les champs en base et les contenus injectés
Une fois les fichiers traités, passez à la base de données. Recherchez les URL vers lesquelles on redirige, ou des segments de code typiques.
Si vous avez plusieurs redirections, vous aurez plusieurs indices. Dans le doute, cherchez dans:
- les contenus (posts, pages), les options, les métadonnées.
Souvent, le code injecté dans une page peut être retiré, mais l’attaquant laisse aussi un déclencheur dans une option. Si vous nettoyez seulement le contenu, la prochaine page éditée peut être contaminée à son tour.
Étape 4: contrôler .htaccess et les règles de serveur
Si vous suspectez le niveau serveur, inspectez .htaccess avant de supprimer quoi que ce soit. Le bon réflexe consiste à:
- garder une copie, comparer avec un modèle attendu pour votre configuration, repérer les blocs ajoutés autour de conditions ou de redirections.
Sur certains hébergeurs, des règles peuvent exister à cause de configurations de cache ou de sécurité. Dans ces cas, on ne supprime pas tout, on corrige le bloc suspect.
Comment traiter les redirections qui reviennent après “nettoyage”
Le retour du symptôme après quelques heures ou quelques jours, c’est le signe classique d’une persistance non supprimée.
Les causes fréquentes que j’ai vues:
- un fichier PHP toujours présent quelque part, pas dans le thème actif, un plugin compromis réactivé automatiquement par un mécanisme, une tâche planifiée (WP-Cron) qui réécrit le code, un compte administrateur resté en place et qui redépose le contenu.
Il y a aussi un cas plus subtil: vous supprimez une infection dans un fichier, mais votre hébergement a une sauvegarde système qui “restaure” automatiquement au prochain intervalle, ou une mise à jour de déploiement interne.
Si votre hébergeur utilise des scripts de restauration ou des “snapshots”, vérifiez le comportement. Ce point est rare, mais quand il arrive, le nettoyage paraît inefficace.
Éviter les fausses bonnes idées
Quand on est sous pression, on veut aller vite. Mais plusieurs décisions peuvent aggraver la situation.
D’abord, ne “remplacez pas tout WordPress” sans vérifier la base et les fichiers injectés dans les thèmes/plugins. Réinstaller le cœur peut restaurer ce qui est propre, mais si le malware vit dans un plugin compromis, il continuera à injecter.
Ensuite, évitez de supprimer uniquement les redirections visibles dans le navigateur si le code ajoute aussi des comportements ailleurs. Un script peut ne rediriger que pour certains utilisateurs, mais garder une autre action discrète.
Enfin, méfiez-vous des outils “automatiques” qui nettoient sans expliquer ce qu’ils suppriment. Je ne dis pas que tout est mauvais, mais quand vous n’avez pas la visibilité sur ce qui a été supprimé, vous perdez un levier essentiel: la compréhension de la source. Or, sans cette compréhension, vous risquez une reprise.
Après la suppression: durcir le site pour que le problème ne revienne pas
Une fois la redirection stoppée, l’objectif est de réduire la probabilité d’un nouvel incident, sans rendre le site inutilisable.
Les vulnérabilités côté WordPress et comptes
- Mettez à jour WordPress, thèmes et plugins de façon cohérente. Le “tout mettre à jour d’un coup” peut casser un thème. Faites plutôt les mises à jour par lot, et surveillez. Supprimez les plugins inutilisés. Un plugin oublié est une porte potentielle. Désactivez la création automatique de nouveaux administrateurs si vous avez une méthode d’import ou un multi-site mal maîtrisé.
Côté comptes, appliquez une logique: moins il y a de comptes à privilèges, plus le risque baisse. Et si vous avez des comptes anciens non utilisés, supprimez-les ou rétrogradez-les.
Sécuriser l’accès et réduire l’attaque brute
Sans entrer dans du technique intrusif, vous pouvez:
- limiter les tentatives de connexion, surveiller les accès admin inhabituels, activer un deuxième facteur si votre plugin de sécurité le permet, et contrôler les identifiants FTP et SSH si vous les utilisez.
Je l’ai vu plusieurs fois: le malware n’est pas “magique”. Il arrive parce qu’un identifiant a été exposé, ou parce qu’un endpoint a été accessible sans protection.
Quand appeler un expert (et quand c’est trop tard pour bricoler)
Il y a un moment où la compétence interne atteint ses limites. Ce n’est pas une question de fierté, c’est une question de temps et de risque.
Faites-vous aider si:
- la redirection est extrêmement persistante malgré une procédure claire, vous suspectez un problème serveur plus profond (règles persistantes, injections à l’échelle système), vous n’avez pas accès complet à la base ou aux fichiers pour confirmer la source, ou vous avez besoin de gérer un volume de sites, par exemple en multi-sites ou en parc client.
Dans ces cas, un diagnostic plus structuré, avec analyse et preuve de suppression, coûte moins cher que des cycles de “nettoyage” qui reviennent.
Signes que vous êtes sur la bonne voie
Après un nettoyage de virus WordPress, vous voulez des signaux concrets. Pas une impression vague.
Voici ce qui rassure le plus:
- la redirection ne se déclenche plus en navigation privée, les URL vers lesquelles vous étiez renvoyé n’apparaissent plus dans les fichiers et la base, les fichiers récemment modifiés sont redevenus cohérents avec votre planning de mise à jour, aucun nouveau compte admin inattendu n’apparaît après quelques heures, et les pages redeviennent stables, sans comportements conditionnels “bizarres”.
Un bon nettoyage ne se limite pas à “ne plus rediriger”. Il rend le comportement reproductible, donc vérifiable.
Questions fréquentes sur les redirections suspectes
“Si je n’ai plus de redirection maintenant, je peux arrêter ici?”
Je ne conseille pas. Attaque intermittente, conditions de cookies, triggers sur rôle ou IP peuvent donner l’illusion d’une disparition totale. Tant que la source n’est pas confirmée et supprimée, vous n’avez pas la certitude.
“Je dois changer le thème ou le plugin même si je pense avoir effacé le code?”
Souvent oui, au moins pour les éléments compromis. Un fichier restauré peut masquer une persistance ailleurs. Remplacer proprement un thème ou un plugin compromis aide à repartir d’un état connu. Si vous avez un thème sur mesure, assurez-vous d’en récupérer une version saine, pas un duplicat déjà infecté.
“Faut-il restaurer une sauvegarde?”
Ça dépend. Restaurer une sauvegarde peut être la voie la plus rapide si la sauvegarde est antérieure à l’infection, mais vous devez alors vérifier que la sauvegarde ne contenait pas déjà l’injection. Et si votre sauvegarde est ancienne, vous récupérez aussi du code obsolète, donc une vulnérabilité potentielle.
Souvent, je préfère une approche hybride: restaurer si nécessaire, puis analyser, sécuriser, et confirmer.
Un dernier point qui change tout: documenter l’incident
Quand l’urgence retombe, prenez cinq minutes pour écrire ce que vous avez observé, ce qui a été modifié, et à quel moment la redirection a cessé.
Je garde habituellement trois éléments: la date et l’URL initiale où le comportement a commencé, l’URL de destination observée, et le type de source confirmée (fichier thème, plugin, base de données, .htaccess). Ce petit carnet évite de répéter la même bataille si un incident similaire survient plus tard.
Parce que sur WordPress, les redirections suspectes ne sont pas une fatalité. Ce sont des symptômes. Et quand on apprend à remonter la chaîne, le prochain nettoyage virus WordPress devient moins un acte de panique, plus un processus maîtrisé.