Un site WordPress qui affiche soudainement des redirections bizarres, parfois vers des pages de faux support, parfois vers des publicités en rafale, finit presque toujours par rejoindre la même catégorie d’ennuis: le site WordPress infecté, au sens opérationnel. Ce n’est pas seulement “un hack”, c’est un comportement. Et ce comportement se voit: un clic, une URL qui change, un paramètre ajouté, une chaîne obscure dans le code, puis un navigateur qui finit sur une destination qui n’a rien à faire là.
Quand le problème est une redirection malveillante, l’urgence est double. D’un côté, vous devez rétablir le parcours normal des utilisateurs et éviter l’aggravation (utilisateurs piégés, perte de confiance, logs saturés). De l’autre, vous devez traiter la cause réelle. Dans ce type d’incident, on voit souvent une série de “couches” qui se relaient: une entrée injectée dans le thème, un fichier modifié dans le dossier d’uploads, un script dans un plugin, un cron compromis, puis une persistance via .htaccess, ou via des en-têtes ajoutés par un proxy ou un plugin de sécurité.
Je vais donc vous guider dans un parcours qui a du sens en exploitation, avec des choix prudents, des vérifications qui évitent de casser davantage, et des cas limites que l’on rencontre réellement.
Reconnaître le type de redirection, sans courir partout
Avant de toucher à WordPress, prenez dix minutes pour observer. Vous cherchez des indices qui indiquent où se situe la redirection, pas uniquement “le site a été infecté”.
Les signaux fréquents:
- La redirection se déclenche sur certaines pages uniquement, par exemple uniquement sur /contact ou sur les pages qui chargent un certain script. Elle se déclenche uniquement sur certains navigateurs, ou après soumission d’un formulaire, ou quand un paramètre est présent dans l’URL. Vous voyez une redirection en chaîne, par exemple votre domaine vers un domaine intermédiaire, puis vers une destination finale. Le code source de la page renvoie des signes: une balise meta refresh, un script qui redirige vers une autre origine, ou un contenu injecté en haut de page.
Dans un incident typique, la redirection est mise en place soit au niveau serveur (fichiers de configuration, règles .htaccess), soit au niveau applicatif (thème ou plugin, fonctions PHP, injections dans les fichiers), soit au niveau du navigateur via une redirection “côté front” (mais souvent déclenchée par une ressource injectée). Cette distinction change entièrement votre stratégie.
Un détail utile: testez en navigation privée, puis depuis un autre réseau ou un autre appareil. Un cache CDN, un cache navigateur, ou une extension peut masquer le comportement réel. C’est frustrant, mais ça évite de croire que “ça ne redirige plus” alors que seuls certains parcours ont été corrigés.
Isoler, limiter les dégâts, et éviter de “nettoyer” sans preuve
Quand on intervient sur un site infecté, on a deux tentations: soit tout supprimer vite, soit tout analyser pendant des heures. Le bon compromis est de réduire l’exposition pendant que vous identifiez la source.
La première mesure pragmatique, si vous avez accès à votre hébergement, consiste à limiter temporairement la surface d’entrée:
- Protégez les formulaires d’administration, et vérifiez que l’authentification est solide (et pas contournée). Si vous avez un pare-feu applicatif ou un module WAF côté serveur, surveillez les patterns de requêtes anormales. Si la redirection touche toutes les pages, vous pouvez mettre le site en maintenance pendant l’investigation, surtout si vous suspectez une propagation via un script récurrent.
Ensuite, collectez des preuves. Sans tomber dans l’excès, sauvegardez:
- Une copie des fichiers de configuration impliqués (au minimum .htaccess, et tout fichier de thème ou plugin modifié). Les logs d’erreur et les logs d’accès à l’instant où le problème se manifeste. Une liste des fichiers récemment modifiés, si votre hébergeur fournit un outil “timestamp” ou un “file change detection”.
Sur les incidents à redirections malveillantes, on gagne beaucoup à savoir si la modification s’est produite à une heure précise. Si vous voyez “les redirections ont commencé à 02:14”, et que dans la minute suivante un plugin a été installé, ou qu’un utilisateur a créé un compte, vous avez une piste concrète.
Repérer les modifications de surface: thèmes, plugins, fichiers persistants
La méthode la plus efficace, sur ce type d’infection, consiste à rechercher les éléments caractéristiques plutôt que de “tout recharger”.
Dans WordPress, les endroits où l’on retrouve le plus souvent des redirections malveillantes sont:
- des fichiers du thème, notamment functions.php, header.php, index.php, ou un include discret dans un sous-dossier; des fichiers de plugin, parfois dans un dossier apparemment “standard” mais qui contient du code injecté; des fichiers dans wp-content/uploads, si quelqu’un a caché du code dans un fichier “d’apparence inoffensive”; des règles de redirection dans .htaccess; un cron WordPress ou un appel programmé qui régénère la charge malveillante après nettoyage.
La partie délicate, c’est que le code peut être minimal. J’ai vu des redirections pilotées par une seule ligne de function_exists ou une inclusion dynamique, avec une chaîne de caractères chiffrée ou fragmentée. Rien n’est garanti à la lecture rapide.
Ce que je cherche en premier, c’est l’incohérence: une fonction qui n’a rien à faire dans votre site, un “base64 decode” qui sort de nulle part, une boucle qui “concatène” une URL, ou des appels à des fonctions PHP de type “curl” ou “fileget_contents” vers des domaines externes non attendus.
Si vous n’avez pas envie d’analyser à la main pendant des heures, vous pouvez combiner deux approches. D’un côté, comparez la version installée avec la version “propre” (celle du thème et des plugins depuis leurs sources officielles). De l’autre, vérifiez les fichiers récemment modifiés, puis ouvrez uniquement ceux qui ont des dates incohérentes.
Un cas qui surprend souvent: la redirection dans .htaccess
Même si la charge malveillante “semble” venir du front, les redirections peuvent être pilotées à l’échelle serveur. .htaccess est un coupable classique.
Quelques symptômes: redirection globale, règles ajoutées “en haut” du fichier, présence d’un code qui dépend d’un header particulier, ou mention d’URL externes dans des conditions.
L’important: ne réécrivez pas .htaccess à l’aveugle. Si votre hébergement utilise des modules (mod_rewrite, configurations spécifiques), un fichier mal restauré peut casser votre site ou vos permaliens.
Le bon réflexe est de sauvegarder l’ancien .htaccess, puis de comparer avec une version attendue. Si vous ne savez pas ce que contient votre configuration d’origine, partez des règles minimales nécessaires à votre WordPress, et remettez ensuite ce qui est compatible. Ici, le jugement compte plus que “supprimer tout”.
Nettoyage méthodique: restaurer la base saine, puis supprimer la persistance
Quand on a une infection, la tentation est de supprimer le code suspect. C’est nécessaire, mais rarement suffisant si un mécanisme de persistance existe.
Sur un incident réel, j’ai déjà vu un nettoyage réussi sur le thème, puis une redirection réapparaître quelques minutes après. La cause n’était pas “le même fichier”, c’était gardewp.fr un cron qui injectait à nouveau le fragment dans functions.php. Une fois la persistance trouvée, le nettoyage est devenu durable.
La logique qui marche le mieux est en général:
1) restaurer les composants à partir de versions connues; 2) enlever les charges malveillantes restantes; 3) vérifier qu’aucun mécanisme ne réinjecte; 4) renforcer l’accès et corriger la faille d’entrée.
Avant de lancer une restauration, faites un point sur vos contraintes. Si votre site a des modifications légitimes dans un thème custom, vous ne pourrez pas simplement “réinstaller le thème”. Il faudra distinguer ce qui est “personnalisé” et ce qui est “injecté”.
Où restaurer, et où ne pas toucher immédiatement
WordPress (le cœur) peut être remplacé proprement sans toucher à vos contenus. Les thèmes et plugins, eux, nécessitent plus de prudence.
Règle pratique: si un thème ou un plugin n’est plus maintenu, ou si vous n’êtes pas sûr de l’origine des modifications, la restauration depuis la source la plus récente et “saine” est souvent plus rapide que du patch manuel. Mais si vous avez un thème très custom, la restauration demandera de reconstruire vos modifications, ou de les récupérer avant suppression.
C’est la raison pour laquelle, avant toute action lourde, je conseille de faire une sauvegarde fichier et base de données, même si elle n’est que partielle au début. Si vous devez revenir en arrière, vous gagnez beaucoup de temps.
Procédure opérationnelle (précise, mais prudente)
Voici une procédure que j’utilise pour ce genre de redirection malveillante. Elle vise un nettoyage efficace, sans casser le site, et sans oublier la persistance.
Étape 1: travailler “hors ligne” autant que possible
Si vous pouvez mettre le site en maintenance, faites-le. Sinon, isolez l’accès à l’administration. Ensuite, désactivez temporairement les plugins non indispensables, surtout si certains sont connus pour ajouter du JavaScript côté front.
Le but est simple: réduire le nombre de variables pendant la recherche.
Étape 2: repérer les fichiers altérés
Recherchez les incohérences et les patterns de redirection dans:
- les fichiers du thème actifs; les plugins actifs; .htaccess; les fichiers PHP dans wp-content que vous n’attendiez pas.
J’insiste sur la phase d’observation. Ouvrir vingt fichiers au hasard fait perdre du temps et crée des erreurs.
Étape 3: vérifier les mécanismes de persistance
Sur WordPress, la persistance peut prendre plusieurs formes: comptes admin fraîchement créés, nouveaux utilisateurs, tâches cron anormales, ou scripts qui modifient d’autres fichiers au prochain passage.
Vous voulez vérifier aussi les paramètres dans la base, au moins pour détecter des traces d’ajout.
Étape 4: supprimer le code malveillant, puis restaurer les composants
Quand vous trouvez le code, vous le supprimez. Ensuite, vous restaurez les fichiers touchés à partir d’une version fiable. Autrement dit, vous ne vous contentez pas de “corriger la ligne”.
Étape 5: réactiver et contrôler
Une fois le site nettoyé, vous réactivez, vous surveillez, et vous testez plusieurs parcours.
Voici le point important: testez aussi les pages qui n’étaient pas infectées au départ. Parfois, une charge malveillante n’affiche la redirection qu’après un certain paramètre, ou sur un type de page spécifique.
Checklist courte avant de toucher aux fichiers sensibles
Avant de modifier quoi que ce soit, voici une petite checklist utile, qui évite des erreurs classiques:
- Sauvegarder les fichiers modifiés (au minimum le thème actif, plugins actifs, wp-content si concerné, .htaccess). Faire une capture des pages redirigées (URL de départ et URL de destination finale, plus au moins une URL où la redirection ne se produit pas). Noter les plugins et thèmes actifs, et repérer ceux que vous n’avez pas mis à jour récemment. Vérifier les comptes utilisateurs, surtout les comptes créés récemment. Vérifier la présence d’un cron suspect ou d’une régénération (redirection qui revient après suppression).
Cette checklist est courte, mais elle force l’alignement entre “ce que vous observez” et “ce que vous allez modifier”.
Vérifications techniques qui font gagner des heures
La partie la plus rentable, dans une infection de redirection, n’est pas toujours le code suspect lui-même. C’est souvent la validation autour.
Surveiller le code côté serveur et côté page
Une redirection peut être pilotée par le serveur, mais parfois elle apparaît dans le code HTML rendu. Si le serveur renvoie directement une URL dans un meta refresh, vous pouvez la repérer via le “voir le code source”.
Si c’est une redirection HTTP (status 301 ou 302), vous la verrez dans l’en-tête de réponse, et parfois dans des logs ou dans des outils de diagnostic.
En pratique, je fais toujours deux tests:
- Test “page” en copiant l’URL exacte qui redirige, sans paramètres supplémentaires. Test “header” via un outil de requête qui montre le status et la destination.
Ce double angle aide à localiser la couche de contrôle.
Observer les domaines de destination
Si la destination est toujours le même domaine, ça facilite l’enquête. Mais si les destinations changent, la charge peut récupérer une cible depuis un serveur distant, ce qui complexifie le nettoyage manuel.
Dans ce cas, il devient encore plus important de supprimer toute fonction ou fichier qui tente de “télécharger” ou de “calculer” une destination.
Vérifier les inclusions dynamiques
WordPress permet des inclusions de fichiers via include, require, ou chargement conditionnel. Les charges malveillantes aiment s’accrocher à cette mécanique.
Si vous voyez dans un thème ou un plugin un chargement conditionnel en fonction d’un paramètre, cherchez la source de cette condition. Souvent, elle est formulée pour éviter de se déclencher pendant vos tests, puis pour se déclencher dans des conditions réelles (agent user, région, heure, origine).
Ce point explique pourquoi vous pouvez voir la redirection chez un utilisateur et pas chez vous.
Remettre la sécurité au bon niveau après le nettoyage
Nettoyer ne suffit pas si vous laissez l’accès ouvert. Sur les infections de redirection, la faille d’entrée est souvent une combinaison de points faibles:
- mot de passe faible ou réutilisé; plugins ou thèmes non mis à jour; permissions trop larges sur certains dossiers; WordPress exposé à des attaques répétées d’accès à wp-admin; admin créés sans que vous l’ayez remarqué.
La correction dépend de votre contexte, mais l’approche générale est assez stable.
Renforcer l’accès admin
Je commence par la base: mots de passe uniques, validation des rôles, et suppression des comptes non reconnus.
Ensuite, si votre hébergeur ou votre configuration le permet, limitez l’accès à wp-login et wp-admin par des règles réseau ou au minimum par une protection anti brute force. Vous n’avez pas besoin d’un empilement de couches si vous avez déjà de la protection côté serveur, mais il faut une barrière réelle.
Réviser les plugins et thèmes
Si un plugin est rarement mis à jour, ou si vous avez installé un plugin “gratuit” pour une fonctionnalité très spécifique, c’est souvent lui le point d’entrée. Pas toujours, mais assez souvent pour qu’on le traite avec sérieux.
La règle raisonnable: gardez peu de plugins, gardez ceux qui sont maintenus, et supprimez ceux que vous n’utilisez plus.
Vérifier les mises à jour et la chaîne de déploiement
Dans certaines entreprises, la cause n’est pas un plugin, c’est le processus de déploiement. On pousse des fichiers via FTP, on copie des thèmes en manuel, et parfois on écrase des versions sans vérifier. Si votre processus n’a pas de garde-fou, vous augmentez le risque de réintroduire un fichier corrompu.
Un contrôle simple consiste à comparer les checksums avant déploiement, ou au minimum à garder un historique des versions de thème et plugin.
Quand le nettoyage manuel ne suffit pas
Il y a des cas où, même en trouvant “un fichier suspect”, vous n’avez pas l’assurance que tout est parti. Par exemple:
- redirection qui revient systématiquement après chaque modification; plusieurs fichiers injectés, dont certains difficiles à localiser rapidement; comportement qui semble distribué (différentes destinations selon les requêtes).
Dans ces cas, la stratégie la plus fiable reste souvent une réinstallation complète des composants applicatifs, en conservant uniquement ce qui est certain (base de données de contenu si elle n’est pas altérée, média si vous avez un moyen de vérifier l’intégrité).
Attention, je ne dis pas “effacer tout”. Je dis “réduire la surface au strict minimum contrôlé”. C’est parfois plus rapide que de poursuivre une chasse au fichier à l’aveugle.
Si vous devez restaurer une base, assurez-vous que la version choisie est saine. Si vous restaurer une base infectée, vous réintroduisez des traces.
Erreurs fréquentes qui aggravent les redirections
Quelques pièges reviennent souvent quand on s’y prend “à la main”.
Le premier piège est de supprimer uniquement la redirection visible dans un fichier de thème, sans vérifier les mécanismes qui la réinjectent. Résultat, ça revient.
Le second piège est de “corriger” .htaccess en supposant qu’il suffit de retirer une règle, sans tenir compte des règles de permaliens. Vous vous retrouvez avec un site cassé, ce qui retarde le diagnostic.
Le troisième piège est de réactiver tous les plugins immédiatement. Si un plugin est à l’origine de l’injection, il peut recommencer au prochain chargement. Vous voulez plutôt réactiver progressivement, en surveillant.
Enfin, le piège le plus coûteux: nettoyer sans vérifier les comptes utilisateurs et les rôles. Un compte admin non reconnu peut reposer sur une persistance dans la base.
Vérifications finales après correction
Quand le site ne redirige plus, on se sent soulagé. C’est normal. Mais une dernière série de tests évite les faux “succès”.
Je teste en général:
- plusieurs pages, y compris celles qui redirigeaient; une page de login et une tentative d’accès admin; des URL avec et sans paramètres; le site depuis un autre environnement, idéalement une session sans cookies.
Côté technique, vérifiez aussi les logs d’accès pendant quelques heures. Si vous voyez une vague de requêtes inhabituelles, et que la redirection n’apparaît plus, c’est une bonne nouvelle, mais ça ne prouve pas l’absence de persistance ailleurs. Cela indique surtout que le code de redirection n’est plus activé.
Si votre hébergement fournit une détection d’intégrité, ou si votre plugin de sécurité peut scanner, utilisez-le en contrôle. Mais gardez un esprit critique: certains scanners identifient des signatures, d’autres donnent des alertes trop larges. Si un scanner vous dit “tout est propre”, vérifiez quand même les fichiers récemment modifiés et l’historique.
Petites mesures de prévention qui ont un vrai impact
Une fois le site stabilisé, quelques habitudes font une différence réelle, sans transformer votre gestion en projet interminable.
D’abord, mettez WordPress, thèmes et plugins à jour, mais avec un délai raisonnable et un test sur un environnement de préproduction si vous en avez un. Ensuite, limitez les privilèges, et évitez de donner “admin” à tout le monde. Enfin, gardez des sauvegardes testées, pas uniquement “faites”. Une sauvegarde que vous ne savez pas restaurer ne sert pas au bon moment.
Les redirections malveillantes sont souvent spectaculaires, mais elles ont presque toujours un point commun: quelqu’un a réussi à écrire quelque part, ou à modifier la chaîne de rendu. Votre objectif est de réduire la probabilité que cela se reproduise, et de réduire le temps nécessaire pour revenir à un état sain.
Si vous devez retenir une seule idée, c’est celle-ci: traite le site WordPress infecté comme un système. Pas seulement comme une page qui redirige. Vous cherchez la persistance, puis vous remontez vers la cause, mot de passe, plugin, fichier modifié ou configuration.
Si vous voulez, décrivez-moi votre situation en quelques lignes: le type de redirection (301, 302, meta refresh), où vous l’observez (toutes les pages ou seulement certaines), et si .htaccess a été modifié récemment. Je peux vous aider à prioriser les vérifications dans le bon ordre.