Une attaque WordPress ne ressemble pas toujours à un “gros hack” spectaculaire. Très souvent, ça démarre par quelque chose de discret, un trafic qui grimpe sans raison, des pages qui semblent propres mais dont le code contient des scripts discrets, ou encore des redirections impossibles à expliquer côté navigation. Et quand on finit par nettoyer les fichiers infectés WordPress, on découvre parfois que le problème ne vient pas uniquement des fichiers. Il peut venir d’ailleurs, des règles Apache, de la configuration de l’hébergement, et surtout des redirections invisibles.
Ce qui est piégeux, c’est que le nettoyage “à l’ancienne” peut faire croire à une réparation complète. On supprime ce qu’on voit, on remplace ce qui a été modifié, on redéploie WordPress, et quelques heures ou jours plus tard, les mêmes symptômes reviennent, parfois plus agressifs, parfois sous une autre forme. Dans ces cas, les règles Apache et les redirections jouent souvent un rôle central. Elles peuvent ramener du code malveillant, réécrire des chemins vers un contenu empoisonné, ou forcer un visiteur vers un domaine tiers sans que cela se voie dans WordPress.
Je vais vous décrire une méthode de diagnostic réaliste, celle qui évite de perdre du temps à “nettoyer deux fois” le même problème. L’objectif n’est pas seulement de supprimer du code, mais de vérifier que le système de redirection et de règles serveur n’est pas en train de réinjecter ou de contourner le nettoyage.
Les symptômes qui pointent vers Apache plutôt que vers WordPress
Avant même d’ouvrir un fichier, j’aime m’appuyer sur des indices concrets. Quand l’infection touche les fichiers, on observe souvent des traces dans les thèmes, plugins, ou des scripts dans des fichiers PHP. Mais quand le rôle d’Apache ou des redirections est important, les symptômes ont tendance à être “comportementaux”.
Par exemple :
- Des visiteurs arrivent sur des pages normales, puis sont renvoyés vers une autre URL quelques secondes plus tard, parfois sans erreur claire dans le navigateur. Des pages spécifiques sont redirigées, mais pas tout le site. L’attaque peut cibler un sous-répertoire, une catégorie, ou un chemin très précis. Les redirections sont intermittentes. Cela arrive quand des règles reposent sur des conditions comme l’User-Agent, la langue, ou des variables de serveur. Le code malveillant ne réapparaît pas forcément dans WordPress après remplacement, mais les redirections continuent. Dans ce scénario, WordPress a peut-être été “utilisé”, puis le relais est passé à la config.
J’ai déjà vu un cas où le site affichait une page d’erreur “propre”, mais les requêtes réseau montraient des 301 et 302 vers un domaine étranger. On avait “nettoyé” les fichiers, on avait même réinstallé des thèmes, tout semblait bon côté fichiers. Le vrai coupable était dans des règles de réécriture, ajoutées dans la configuration Apache ou via un fichier de configuration local. Une fois ces règles retirées, le trafic est retombé.
Ce que vous pouvez rencontrer dans une infection WordPress
Nettoyage fichiers infectés WordPress ne veut pas dire uniquement “supprimer des lignes”. Dans une compromission, l’attaquant peut :
Modifier des fichiers directement (PHP dans le noyau, un plugin, un thème, un fichier uploadé). Ajouter des fichiers de backdoor à des endroits inattendus. Utiliser des mécanismes de redirection via serveur, pour que la victime soit envoyée ailleurs. Exploiter les paramètres de l’hébergement, en particulier des règles de réécriture.Les redirections peuvent être mises en place de plusieurs façons. Sur un serveur Apache, la plus fréquente passe par mod_rewrite dans des fichiers comme .htaccess (dans le document root ou un sous-dossier), ou via des fichiers de configuration chargés plus haut.
Le problème est que WordPress peut être rétabli, mais l’infection persiste côté serveur. Et inversement, des règles Apache modifiées peuvent être la seule partie compromise, sans que des fichiers WordPress soient “sales” au moment du contrôle.
Où vérifier les règles Apache, sans vous égarer
Selon votre configuration d’hébergement, vous n’avez pas forcément accès à tous les fichiers. Mais vous pouvez au moins vérifier les endroits les plus plausibles.
Les fichiers .htaccess, souvent le point d’entrée visible
Le fichier .htaccess est le premier suspect dans un environnement Apache, surtout si vous utilisez des permaliens WordPress. WordPress génère un bloc de règles, et l’attaquant peut le copier, l’encadrer, ou l’ajouter juste avant pour qu’il ne casse pas le site.
Ce que je recherche typiquement :
- Des règles RewriteRule qui redirigent vers des domaines externes. Des conditions RewriteCond avec des variables inhabituelles, comme une dépendance à des headers spécifiques. Des exceptions ou des “if” qui ciblent certains chemins ou certains types de requêtes. Des références à des fichiers écrits par l’attaquant, ou des URLs en clair dans la règle.
Un piège classique : le .htaccess peut ne pas être énorme. Quelques lignes suffisent pour tout casser. Et parfois, la règle est masquée derrière une condition qui ne s’active que pour certains visiteurs, ce qui rend le test en navigation “normale” trompeur.
Les configurations chargées au-dessus de WordPress
Sur certains hébergements, vous n’avez pas accès à la racine de l’instance Apache, mais les règles peuvent exister à d’autres niveaux, par exemple dans des templates de virtual host ou des configurations incluses. Même sans accès direct, vous pouvez souvent diagnostiquer via le comportement HTTP.
Si vous voyez des redirections qui ne correspondent pas aux règles de .htaccess visibles, ou si vous n’avez pas de .htaccess modifié et que ça redirige quand même, il faut envisager un niveau plus haut.
Les scripts de contrôle d’accès ou de sécurité
Certains hébergeurs ajoutent des règles WAF, d’optimisation, ou de redirection. Une compromission peut exploiter ces mécanismes, ou l’attaquant peut laisser derrière lui une “signature” compatible avec les outils de l’hébergeur.
Je fais attention à ne pas tout supprimer “au hasard”. Si vous retirez une règle de sécurité légitime, vous pouvez transformer une compromission en dégradation de disponibilité. D’où l’idée suivante : diagnostiquer avant d’agir.
Vérifier les redirections avec une approche simple et probante
Les symptômes de redirection peuvent être trompeurs si vous testez uniquement dans un navigateur. Ce que je recommande, c’est de vérifier au niveau requête-réponse, sans interprétation.
Ouvrez l’outil réseau du navigateur et cherchez :
- Les codes HTTP de type 301, 302, 307 ou 308. La destination exacte de la redirection (l’URL complète). La page de départ (le chemin demandé). La séquence, si plusieurs redirections s’enchaînent.
Si vous pouvez, ajoutez une vérification “profonde” en testant avec un autre client, par exemple sur une autre machine ou un autre navigateur. Les attaques ciblent parfois un User-Agent ou un type de navigation. J’ai déjà vu une redirection qui ne se déclenchait que sur mobile. Du coup, sur un poste de bureau, tout semblait “ok”, et c’est l’accès mobile qui révélait la redirection.
Autre point utile : si votre hébergeur utilise un CDN ou un reverse proxy, la redirection peut être injectée par le proxy et pas par Apache au sens strict. Dans ce cas, vérifier les règles serveur reste pertinent, mais il faudra aussi regarder côté CDN et cache. Sans inventer, je dirais simplement que le chemin du diagnostic doit suivre la chaîne réelle qui voit vos requêtes.
Nettoyage des fichiers infectés : faire plus que “remplacer WordPress”
Vous allez probablement refaire un nettoyage de fichiers infectés WordPress, parce que c’est souvent nécessaire. Mais le piège, c’est de penser que la réinstallation est la fin de l’histoire.
Une méthode que j’ai trouvée efficace consiste à séparer les tâches :
- Réparer WordPress et supprimer le contenu suspect. Ensuite seulement, valider que le serveur n’a pas été “configuré” pour contourner ce nettoyage.
Concrètement, quand je restaure WordPress, je le fais de façon à réduire les ambiguïtés :
- Je compare les versions et je remplace les fichiers du noyau avec une source fiable. Je purge les thèmes et plugins non nécessaires, et je ne garde que ce qui est indispensable. Je vérifie les fichiers modifiés récemment, mais sans considérer que “ancien” signifie “safe”.
Ensuite, je reviens à Apache et aux redirections. Si la redirection reste, je ne me bats plus contre WordPress, je me bats contre le serveur.
Quand l’attaque passe par les règles de réécriture
Sur Apache avec mod_rewrite, les redirections peuvent être utilisées pour injecter un chargement distant, ou pour envoyer des victimes vers un site malveillant.
Il existe plusieurs scénarios typiques :
- Redirection globale des pages WordPress vers une URL externe. Souvent, l’attaquant cible index.php ou un chemin “proche du front”. Redirection conditionnelle, qui s’active seulement pour certains chemins, par exemple /wp-admin/ ou /?something=. Redirection basée sur des paramètres, comme la présence d’un cookie ou d’un header. Redirection après un traitement, par exemple en manipulant la manière dont les URLs sont réécrites en permaliens.
Le rôle de ces règles dans un nettoyage est simple : même si WordPress est propre, la mauvaise règle peut détourner la navigation avant que WordPress n’affiche quoi que ce soit.
Exemple de comportement à surveiller
Imaginons que vous avez remplacé WordPress, vous redéployez les fichiers, mais quand vous accédez à /contact/, vous êtes redirigé vers un domaine inconnu. Si le domaine inconnu est identique à celui qu’on trouvait dans les fichiers infectés, l’attaquant a probablement créé un pont. Dans ce cas, la règle serveur peut pointer vers un fichier PHP ou un script hébergé ailleurs.
Une autre variante : la page semble normale, mais les ressources chargées (images, scripts, iFrames) viennent d’un domaine douteux. Dans ce scénario, les règles de réécriture peuvent modifier des chemins et forcer le chargement d’assets corrompus. La frontière entre WordPress et Apache devient alors floue, et c’est normal. La bonne réponse, c’est de corréler : redirection HTTP d’abord, puis chargement des ressources ensuite.
Cas fréquents dans les compromis Apache sur WordPress
Voici les situations que j’ai le plus rencontrées lors de diagnostics, avec des conséquences directes sur le nettoyage.
.htaccess qui a l’air “presque normal”
Le fichier .htaccess peut contenir le bloc WordPress, plus quelques lignes additionnelles qui ressemblent à du “raffinage SEO” ou à des règles de sécurité. Le problème est qu’un attaquant peut écrire des règles crédibles visuellement.
Le bon réflexe est de ne pas chercher uniquement des phrases évidentes comme un domaine. Cherchez aussi :
- Une logique de RewriteCond qui n’appartient pas à votre site. Des règles qui ciblent un type de requête inattendu. Des références à des scripts ou des chemins hors de WordPress.
Dans un cas réel, les lignes ajoutées étaient “propres”, sans code PHP dans le .htaccess. Elles redirigeaient vers un chemin du même domaine, qui pointait ensuite vers un fichier de backdoor à l’intérieur d’un répertoire peu consulté. À l’œil nu, le site WordPress ne montrait rien, mais la chaîne d’exécution via redirection était complète.
Redirections liées aux permaliens
Si votre .htaccess a été modifié, les permaliens WordPress peuvent se comporter de manière anormale. Par exemple, des URLs SEO peuvent renvoyer vers des pages inattendues.
Dans ce cas, la redirection peut être un sous-produit de la compromission, mais elle n’est pas moins dangereuse. Même si l’attaquant n’en a pas besoin, il peut avoir mis à jour la logique pour que son code soit servi efficacement.
Mauvaise gestion de l’ordre des règles
Apache évalue les règles dans un ordre qui peut faire toute la différence. Un attaquant peut insérer une règle avant le bloc WordPress, pour qu’elle s’exécute avant que les règles attendues ne s’appliquent.
Pour éviter de casser votre site au moment de la correction, ne “recopiez” pas aveuglément des .htaccess depuis un autre site. Utilisez plutôt le fichier de référence de votre WordPress et votre configuration de permaliens. Si vous changez le contenu, validez en https://gardewp.fr/nettoyage-malware-wordpress/ testant l’ensemble des types d’URLs : pages, articles, catégories, tags, et pages qui ne sont pas en permaliens.
Stratégie de correction : ordre des opérations et validation
Je vous propose une logique d’intervention qui réduit les retours en arrière. L’idée est d’éviter le scénario “on corrige, ça marche, puis on découvre que c’était un autre morceau”.
Stopper la propagation si vous observez une redirection active vers un domaine externe. Dans certains cas, même un “nettoyage” simple peut ne pas suffire car l’attaquant continue de servir le contenu malveillant via serveur. Vous pouvez mettre le site en maintenance ou restreindre l’accès pendant le diagnostic, si votre activité le permet. Nettoyer WordPress de manière contrôlée : suppression des fichiers clairement suspects, restauration à partir de sources propres, vérification des plugins et thèmes. Analyser et corriger Apache et redirections : .htaccess, règles de réécriture, et toute anomalie visible via les réponses HTTP. Revalider avec des tests orientés “comportement” : redirection, réponse HTTP, contenu servi, et éventuellement le chargement d’assets.Cette séquence n’est pas juste une question de confort. Elle évite de confondre un effet secondaire avec la cause.
Deux checklists qui sauvent du temps
Je limite volontairement les listes pour garder un fil clair, mais il y a deux moments où une checklist courte aide vraiment.
Vérifications rapides côté navigateur et HTTP
- Cherchez les codes 301, 302, 307, 308 dans l’onglet réseau. Notez l’URL cible exacte de la redirection, domaine compris. Testez au moins deux URLs différentes, une au hasard et une “suspecte” (celle où vous aviez observé un souci). Comparez un test sur mobile et un test sur ordinateur si vous suspectez un ciblage. Vérifiez si la redirection disparaît après un cache nettoyé, au moins côté navigateur.
Points à contrôler dans .htaccess et règles associées
- Présence de RewriteRule pointant vers des domaines externes. Conditions RewriteCond liées à des headers ou cookies inhabituels. Règles ciblant des chemins précis (admin, login, répertoires upload, ou fichiers PHP non attendus). Ordre des règles, surtout si une règle est placée avant le bloc WordPress. Conformité avec votre configuration de permaliens (pages, catégories, tags).
Si vous trouvez une règle clairement malveillante, la correction est généralement directe. Le plus délicat, c’est quand les règles sont ambiguës, par exemple parce que vous ne savez pas si c’est un réglage ancien de votre hébergeur ou quelque chose ajouté tardivement.
Comment décider sans casser votre site
Le doute est fréquent. Vous ouvrez .htaccess, vous voyez des lignes que vous ne connaissez pas. Vous ne savez pas si elles sont issues d’un module de sécurité, d’un plugin, ou d’un réglage hébergeur.
Voici comment j’arbitre, sans prétendre à une certitude universelle :
- Si la règle contient une redirection vers un domaine externe, c’est presque toujours à supprimer ou à remplacer par une règle saine. Si la règle manipule des chemins pour injecter un fichier non standard, c’est suspect. Si la règle ressemble à un correctif WordPress ou à un réglage connu de permaliens, vous pouvez la conserver, mais seulement si elle n’introduit pas d’URL externes et si elle n’est pas incohérente avec votre site. Si vous avez une trace de modification (date, historique serveur, commit, ou au moins une cohérence avec un moment où le site a commencé à poser problème), le contexte vaut plus que la forme.
Un détail pratique : faites des sauvegardes avant toute modification. Pas un simple copier-coller mental, une sauvegarde chiffrée ou au moins conservée hors serveur si possible. Les infections apprennent vite, elles profitent d’erreurs. Si vous cassez votre .htaccess, vous pouvez rendre votre diagnostic plus difficile, donc votre capacité à prouver ce qui est corrigé.
Et si les redirections ne viennent pas de .htaccess ?
Cette question revient souvent : “j’ai nettoyé le .htaccess, mais ça continue”. Deux raisons principales :
Les règles sont ailleurs : configuration virtual host, include serveur, ou mécanisme au-dessus de votre document root. Le comportement vient d’un autre composant : CDN, reverse proxy, ou plugin de sécurité installé sur le serveur et modifiant la manière dont le contenu est servi.Dans ce cas, vous pouvez encore avancer sans accès complet à la configuration :
- En observant les en-têtes HTTP, comme Location (pour les redirections) ou des headers spécifiques de proxy. En testant en direct si vous avez un moyen d’éviter le cache, même provisoirement. En vérifiant la cohérence entre ce que vous voyez sur plusieurs chemins.
Je reste prudent sur ce que je peux affirmer sans accès système. Mais le principe de décision reste le même : si le serveur redirige, le correctif doit être trouvé du côté de la chaîne qui produit cette redirection, pas uniquement du côté WordPress.
Restaurer la confiance : contrôle après nettoyage
Une fois que vous avez corrigé les fichiers et les règles suspectes, il faut une validation. Le test ne doit pas être uniquement visuel, il doit être “fonctionnel” sur la navigation.
Je conseille de vérifier :
- Accès aux pages publiques, et vérifiez les redirections à nouveau. Accès aux zones d’administration, si vous les utilisez. Les formulaires, les chargements de scripts et images, car certains contenus infectés peuvent se déclencher seulement lors du rendu. Les erreurs 403, 404, 500 inhabituelles qui peuvent signaler des règles cassées.
Vous pouvez aussi surveiller le trafic ou au moins les logs applicatifs et serveurs sur une période courte. Beaucoup d’attaques ont un rythme. Si vous observez un retour des patterns, vous avez un signal. Le but est de détecter tôt une réinfection, ou une persistance via un autre vecteur.
Pièges courants pendant le nettoyage
Quelques erreurs reviennent, et elles coûtent cher en temps :
- Remplacer WordPress sans vérifier .htaccess. Le nettoyage “côté fichiers” ne suffit pas quand la redirection est la cause principale. Nettoyer uniquement les fichiers les plus visibles (thèmes et plugins connus) et oublier des scripts dans des dossiers plus discrets. Modifier .htaccess sans comprendre le mode de permaliens. Vous risquez un effet domino sur toutes les URLs. Oublier que certains outils d’administration ou de sécurité peuvent aussi modifier la configuration serveur.
Un dernier piège, plus subtil : si votre hébergeur ou votre système de déploiement ajoute ensuite des règles automatiquement, vous pouvez croire que l’infection revient alors que c’est une réapplication de config. D’où l’intérêt de conserver une copie de ce que vous aviez avant modification, et de noter la date exacte de chaque changement.
Pourquoi vérifier Apache et redirections fait gagner du temps
Le temps perdu arrive quand on traite uniquement les symptômes WordPress. Oui, les fichiers infectés WordPress doivent être nettoyés. Oui, les plugins et thèmes compromis doivent être remplacés.
Mais quand vous prenez l’habitude de vérifier Apache et les redirections dès que vous observez des comportements de type renvoi, vous évitez un aller-retour classique : nettoyer, réinstaller, puis constater que le serveur continue de détourner les visiteurs.
Dans une compromission, la logique de l’attaquant est pragmatique. Il utilise le chemin le plus efficace pour servir le contenu malveillant. Parfois, ce chemin passe par un fichier PHP. Souvent, il passe par la manière dont le serveur réécrit et redirige les requêtes. Une règle bien placée peut survivre à une restauration WordPress.
Si vous retenez une seule idée, c’est celle-ci : WordPress et Apache doivent être considérés comme un ensemble. Le nettoyage des fichiers est une étape essentielle, mais la configuration serveur est le “chemin” qui décide de ce que le visiteur reçoit.
Quelques actions concrètes si vous êtes en urgence
Si votre site redirige déjà vers un domaine externe et que vous devez agir rapidement, l’urgence impose un compromis entre sécurité et disponibilité. Je ne détaille pas de procédures de contournement dangereuses, mais l’esprit est simple : réduire l’exposition, puis isoler la cause.
- Mettez le site en mode maintenance si votre activité le permet, ou limitez l’accès le temps du diagnostic. Lancez le contrôle des redirections via l’outil réseau, vous aurez une direction immédiate. Sauvegardez .htaccess avant toute modification. Nettoyez les fichiers suspectés, puis revenez à Apache pour confirmer que les redirections sont bien corrigées.
À ce stade, vous ne cherchez plus “un fichier infecté” au sens vague. Vous cherchez une règle de persistance, puis vous la supprimez ou vous la remplacez.
Si vous passez cette étape, votre nettoyage devient durable, et les symptômes disparaissent vraiment. C’est la différence entre “réparer aujourd’hui” et “ne plus revivre le même incident demain”.