Un site WordPress qui se met à rediriger tout le monde, à injecter des liens bizarres dans les pages, ou à envoyer du spam depuis vos formulaires, ce n’est pas un simple “bug”. C’est souvent un mélange de fichiers modifiés, de comptes compromis, de réglages trafiqués, parfois même de trafic malveillant côté serveur. Et plus vous laissez courir, plus vous abîmez votre réputation, vos performances, et votre capacité à récupérer proprement.
J’ai vu des sites où, après l’infection, la recherche Google affichait des pages “fantômes” alors que le back-office était intact. Dans d’autres cas, la redirection ne touchait qu’une poignée de visiteurs, généralement ceux arrivant depuis certains pays, ou sur mobile. Cette variabilité ne rassure pas, elle complique le diagnostic.
L’objectif ici est clair: stopper les redirections et le spam, puis nettoyer WordPress efficacement sans casser l’existant. On va parler de ce qui se passe vraiment, de l’ordre logique des actions, des vérifications concrètes, et des pièges classiques.
Comprendre le comportement: redirection, spam, injection
Quand un site WordPress devient un “propulseur” de nuisances, il y a généralement une de ces familles de symptômes.
D’abord, la redirection. Elle peut être globale ou ciblée. Parfois, elle ne touche qu’une URL précise, par exemple /contact ou une page en particulier. Parfois, elle s’enclenche selon l’agent utilisateur (le navigateur) ou l’IP. Un fichier infecté peut aussi injecter une redirection indirecte, par exemple via un script qui charge ensuite une page externe.
Ensuite, le spam. Il peut venir de formulaires, d’inscriptions, de notifications WordPress, ou de l’envoi automatique d’articles “leurres”. On rencontre aussi du spam de commentaires, mais avec une cadence anormale et des domaines incohérents. Dans un cas récent, le spam sortait depuis un compte “admin” fraîchement créé, dont le mot de passe était inconnu mais dont l’historique de connexion pointait vers des connexions réussies par jour, à des heures répétées.
Enfin, l’injection de contenu. Ce sont ces passages de texte qui ne ressemblent à rien: liens cachés, iframes, scripts qui “marchent” uniquement quand le navigateur est dans le bon état. Même si vous ne voyez rien dans l’éditeur, le code peut être généré à l’exécution via des fichiers PHP modifiés ou des paramètres détournés.
À partir de là, vous pouvez approcher le nettoyage comme une enquête: on coupe d’abord le mécanisme qui nuit, puis on remonte à la cause.
Le plan d’action qui évite d’aggraver les dégâts
La tentation, surtout quand on est pressé, est de “supprimer tout” et de restaurer un snapshot sans réfléchir. Parfois ça marche, mais ça peut aussi effacer des indices utiles, ou pire, remettre en ligne une version déjà compromise.
Voici la logique que j’utilise dans les situations réelles, avec un ordre qui limite le risque:
D’abord, on réduit l’exposition. Si votre site redirige, il faut le stabiliser rapidement, au minimum le temps de diagnostiquer. Mettre WordPress en maintenance ou bloquer temporairement les requêtes suspectes peut suffire, tant que vous gardez accès à l’administration.
Ensuite, on identifie l’origine de l’infection. Le plus fréquent, c’est un mélange de thèmes ou extensions modifiés, de fichiers core modifiés, ou d’ajouts dans le dossier uploads qui servent de réservoir. Plus rarement, c’est une vulnérabilité non corrigée qui a permis l’accès initial.
Puis on nettoie en profondeur. Nettoyer WordPress efficacement, ce n’est pas seulement supprimer un plugin. Il faut aussi vérifier les comptes utilisateurs, les tâches planifiées, les fichiers modifiés récents, et les paramètres de redirection.
Enfin, on renforce pour empêcher la récidive. Changer un mot de passe ne suffit pas si le vecteur d’intrusion n’a pas été corrigé.
Cette approche est aussi celle qui limite le cas délicat où vous nettoyez la surface, mais que l’attaque continue via un mécanisme persistant.
Réduire l’impact sans perdre l’accès
Si le site redirige les visiteurs, votre priorité est de stopper la nuisance sans vous priver de l’accès aux fichiers pour diagnostiquer.
Selon votre hébergement, vous avez plusieurs leviers. Le mode maintenance WordPress peut aider, mais si la redirection s’exécute avant WordPress, cela peut ne pas suffire. Dans ce cas, un réglage au niveau du serveur, par exemple une règle temporaire de blocage, est plus efficace.
J’ai déjà vu des infections où une partie du trafic recevait une redirection et une autre partie atteignait quand même le back-office. Dans ce scénario, le maintien en production piège les visiteurs tout en vous donnant l’impression que “ça va, on peut travailler”. En pratique, tant que le comportement malveillant reste en ligne, il faut considérer que votre serveur continue de servir l’infection.
Une autre option utile, si vous pouvez vous l’offrir, est d’extraire une copie complète de la base de données et du système de fichiers, puis de travailler sur une copie hors ligne. Cela réduit la pression et évite de modifier en aveugle.
La première vérification: fichiers récents et “zones suspectes”
La méthode la plus rentable consiste à chercher ce qui a changé récemment. Quand WordPress est compromis, le motif le plus commun est l’ajout ou la modification de fichiers dans:
- le dossier du thème actif ou des thèmes enfants, le dossier d’extensions, parfois des fichiers dans wp-content/uploads, et parfois des fichiers à la racine, ou des inclusions qui s’accrochent au chargement.
Sur le plan pratique, vous pouvez comparer la date de modification. Les fichiers infectés ont souvent une date récente, même si le site “a toujours existé”. Soyez attentif aux fichiers PHP “anciens” mais dont le contenu a été modifié sans raison. Les incrustations malveillantes sont souvent courtes, mais insérées à des endroits très spécifiques: avant un ?>, ou en fin de fichier, ou dans des fonctions qui sont rarement appelées.
Si votre thème n’a pas été mis à jour depuis des semaines, une modification du functions.php ou d’un fichier template le jour même est un signal d’alarme. Même chose pour une extension qui n’a pas changé.
Un piège fréquent: croire que la faute vient forcément d’un plugin populaire. En réalité, le vecteur d’entrée peut être un plugin vulnérable, mais l’implantation se retrouve parfois dans un thème ou dans un fichier “proxy” placé ailleurs. La cause initiale et la preuve de l’attaque ne sont pas toujours au même endroit.
Vérifier les redirections: où ça se décide
Les redirections peuvent se produire via plusieurs mécanismes. Dans WordPress, le plus classique est l’injection dans des hooks, via un wp_redirect() déclenché à la condition “visiteur correspond à X”. Cela peut être dans un thème, dans une extension, ou dans un fichier chargé tôt.
Vous pouvez aussi voir des redirections “cachées” via des fonctions d’URL, par exemple dans un filtre template_redirect ou dans init. Pour détecter ça, la recherche du code est votre alliée. Cherchez dans vos fichiers des patterns typiques comme wp_redirect, header("Location, base64_decode, eval(, gzinflate, ou des chaînes qui ressemblent à des scripts “auto-dépaquetés”. Les pirates utilisent souvent une couche d’obfuscation, mais les noms de fonctions et les structures restent reconnaissables.
Autre indice: la présence de requêtes vers des domaines externes dans du PHP. Par exemple, un code qui récupère une ressource distante, ou qui ping une URL avant de décider d’agir. Ce genre de lecture réseau en plein rendu de page est un signe quasi certain.
Si vous avez un accès aux journaux du serveur, utilisez-les pour confirmer les routes. Quand vous observez des patterns, vous pouvez croiser avec les URLs concernées. Cela aide à isoler un fichier fautif.
Bloquer le spam en parallèle: formulaires, comptes, tâches
Quand il y a du spam, il faut le traiter comme un incendie: vous voulez arrêter l’émission tout de suite, tout en gardant une trace.
Le spam peut venir de plusieurs sources. Un compte compromis peut publier, poster des messages, ou déclencher des actions automatisées. Des formulaires peuvent aussi être détournés, soit via une injection de champ, soit via un script malveillant qui envoie des requêtes.
Autre vecteur, moins visible: les tâches planifiées. WordPress a une mécanique d’events (WP-Cron). Une infection peut créer des actions qui exécutent un code ou lancent des envois à intervalles réguliers. Si vous supprimez des fichiers, mais que la tâche persiste et pointe vers une fonction toujours disponible, l’infection peut continuer autrement.
Pour agir, commencez par vérifier les comptes utilisateurs:
- Comptes nouvellement créés, surtout admin, éditeur, auteur modifications de rôles récemment accordées tentatives de connexion réussies répétées utilisateurs dont les métadonnées (dernière connexion) coïncident avec la période d’infection
Ensuite, regardez les formulaires. Si votre site utilise reCAPTCHA ou une autre protection, elle peut être contournée ou désactivée. Vérifiez aussi les champs cachés et les scripts liés aux pages de formulaire.
Même sans liste, gardez une logique: stopper ce qui envoie, puis documenter ce qui a déclenché.
Nettoyer WordPress efficacement: méthode de restauration “propre”
Le nettoyage réel demande un choix stratégique. Si vous restaurez un thème ou WordPress core, vous évitez beaucoup de dégâts. Si vous supprimez au hasard, vous risquez d’arracher une partie du code légitime ou de laisser un morceau infecté.
La stratégie qui fonctionne le mieux en pratique est souvent la suivante: réinstaller les composants propres, puis nettoyer le reste.
Concrètement, WordPress core: si le core a été modifié, la voie la plus sûre est de réinstaller WordPress à partir de la version officielle, tout en conservant votre base de données intacte pour le diagnostic. Cette action supprime les altérations dans les fichiers standards.
Pour les thèmes et extensions, il y a un trade-off. Réinstaller un thème peut effacer vos personnalisations si vous ne les protégez pas. Pour un thème enfant, si le code modifié est dans le thème parent, vous pouvez réinstaller le parent propre. Si l’infection est dans le thème enfant, il faut purger le fichier concerné.
Dans tous les cas, ne vous contentez pas de “désactiver”. Une désactivation empêche l’exécution, mais le fichier reste. Si l’infection est dans un fichier appelé tôt, elle peut parfois continuer selon les conditions. Mieux vaut supprimer ou remplacer les fichiers clairement compromis.
C’est ici que la recherche “nettoyer site WordPress infecté,” devient pertinente dans la démarche: on ne vise pas seulement à remettre un site en ligne, on vise un nettoyage cohérent, traçable, et reproductible. Un site “redevenu normal” n’est pas un site “propre” si un résidu reste.
Cas fréquent: uploads infecté et “fichiers fantômes”
Beaucoup de gens se concentrent sur wp-content/plugins et wp-content/themes. Or, wp-content/uploads peut devenir un dépôt d’outils malveillants. Parfois ce sont des fichiers PHP déguisés en images, parfois des scripts dans des sous-dossiers.
Le signal typique, c’est une explosion de fichiers récents, des tailles inhabituelles, et des types inattendus. Si vous voyez des fichiers .php dans uploads, ce n’est pas normal. Sans être “automatiquement” une infection, c’est un drapeau rouge.
Si votre hébergement exécute des PHP dans les sous-dossiers uploads, vous devez aussi corriger la configuration pour empêcher l’exécution. Cela peut passer par une règle .htaccess ou une configuration Nginx, selon votre stack. Ce correctif est une barrière de sécurité. Même si vous nettoyez, cette barrière réduit les dégâts en cas de récidive.
Vérifier le fichier .htaccess, les règles proxy et les includes
Les redirections peuvent aussi être décidées hors WordPress, via .htaccess pour Apache ou des directives côté Nginx.
Un .htaccess modifié peut:
- rediriger certaines routes vers des domaines externes, déclencher des actions selon l’agent utilisateur, ou exécuter des conditions.
Dans un scénario réel, l’équipe a nettoyé tous les plugins, mais le problème persistait sur une seule URL. En comparant le .htaccess, ils ont découvert une règle ajoutée, ciblant exactement cette route. Après retrait de la règle, le comportement a cessé.
Si vous avez accès au fichier, comparez-le à une version de référence (si vous avez une copie en backup) ou vérifiez que seules les règles attendues y figurent. Les injections malveillantes peuvent être noyées dans des blocs, surtout si le pirate a ajouté des conditions.
Sécuriser après nettoyage: comptes, secrets, et surfaces d’attaque
Une fois les fichiers remis en état et les redirections coupées, il reste la vraie question: comment le site a été compromis?
Souvent, c’est l’une de ces raisons:
- un plugin ou un thème vulnérable, des mots de passe faibles, une absence d’authentification à deux facteurs, un serveur mal configuré, des autorisations trop permissives.
Je commence presque toujours par réinitialiser les mots de passe de tous les comptes, en particulier les rôles administrateurs. Puis j’impose une authentification à deux facteurs si c’est possible.
Ensuite, je vérifie les mises à jour. WordPress, thèmes et extensions doivent être au niveau le plus récent compatible avec votre site. Le compromis à accepter: certaines extensions “anciennes” cessent de recevoir des correctifs. Là, vous avez un choix dur, mais sain, remplacer ou arrêter.
Dernier point, qui change tout à long terme: limiter l’accès admin. Restreindre l’accès au back-office par IP, ou au moins ajouter une protection de type rate limiting, aide énormément contre les attaques par force brute.
Je ne promets pas que cela stoppera toute attaque, mais ça réduit fortement la fréquence.
Mettre en place une surveillance utile, pas juste “un plugin”
Après une infection, la tentation est d’installer un outil “qui scanne”. Les scanners sont utiles, mais ils ne remplacent pas une discipline de surveillance.
L’idée est de repérer tôt un changement. La plupart des infections réussies laissent une trace sous forme de modification de fichiers, de création de comptes, ou de hausse du trafic vers certaines URL.
Vous pouvez mettre en place:
- des alertes sur les changements de fichiers critiques, une surveillance des nouveaux utilisateurs, une analyse des logs quand le trafic devient bizarre, et une vérification régulière de la base de données sur des tables sensibles.
Évitez aussi de masquer les problèmes en mettant des couches infinies. Chaque plugin ajoute des scripts et des risques. Le mieux est d’avoir peu d’outils, mais ciblés.
Exemple concret: quand l’infection n’était pas là où on pensait
Je me souviens d’un cas où tout semblait “propre” côté plugins. Les versions étaient à jour, les dossiers ne montraient rien d’évident. Le site, par contre, redirigeait certains visiteurs après la connexion, surtout sur les pages de produit.
Le diagnostic a été fait en cherchant dans les fichiers du thème actif des motifs de redirection. Rien de clair dans les templates, mais une modification dans un fichier chargé par le hook de thème, une condition sur l’hôte et l’agent utilisateur. Le code n’avait presque pas l’air malveillant à la première lecture, il préparait juste une logique, puis il appelait une inclusion externe masquée via un chargement indirect.
Une fois le bon fichier retiré, la redirection s’est arrêtée, et le spam de commentaires a baissé parce que le vecteur d’injection touchait aussi les formulaires.
Le point à retenir, c’est que “rien d’évident” ne veut pas dire “pas d’infection”. La plupart du temps, l’infection est subtile et se cache dans un endroit inattendu.
Checklist courte pour stopper rapidement les redirections et le spam
Si vous devez agir vite, voici un ordre de travail compact, sans magie:
- Mettre en maintenance ou limiter l’accès aux visiteurs, le temps du diagnostic Relever les fichiers PHP modifiés récemment, surtout dans thèmes, extensions, et uploads Vérifier les redirections dans les hooks de thème, les filtres, et .htaccess si applicable Désactiver les extensions inutiles, puis remplacer proprement le core WordPress Contrôler les comptes utilisateurs, rôles, et activités récentes (y compris créations)
Cette liste ne remplace pas une enquête, mais elle évite de perdre des heures à faire le mauvais test.
Comment investiguer sans casser le site
Quand vous manipulez des fichiers en production, vous voulez limiter l’impact. Une méthode que j’aime bien consiste à procéder par étapes, en gardant des points de retour.
D’abord, travaillez sur une copie. Si c’est impossible, au moins sauvegardez base de données et dossiers concernés avant modification.
Ensuite, isolez. Si vous remplacez un thème ou un plugin, regardez si le comportement revient après un changement unique. Cela demande de la patience, mais c’est le moyen le plus fiable de savoir quel morceau est responsable.
Enfin, gardez des traces. Un simple document où vous notez: date, action, résultat, URL impactées, agent utilisateur si vous pouvez, accélère énormément quand vous reprenez plus tard.
Pièges qui font perdre du temps (et parfois des clients)
Voici les erreurs typiques que j’ai vues, et qui coûtent cher en énergie:
Le premier, c’est “mettre à jour” au hasard. Si l’infection vient d’un plugin vulnérable non mis à jour, une mise à jour peut aider. Mais si vous installez une nouvelle version alors que des fichiers sont déjà compromis, vous pouvez déplacer l’infection ou casser votre configuration, sans régler le fond.
Le deuxième, c’est “nettoyer le dossier du plugin” au lieu de le remplacer. Si le fichier injecté est dans un sous-fichier rarement utilisé, vous pouvez rater le bon endroit. Remplacer par le paquet propre est plus sûr quand vous avez identifié le composant compromis.
Le troisième, c’est ignorer la base de données. Des injections peuvent exister dans des options, des meta, des shortcodes enregistrés, ou des éléments de configuration. Si vous ne faites que nettoyer le système de fichiers, l’effet peut continuer, par exemple via des paramètres modifiés.
Le quatrième, c’est oublier la configuration serveur. Une fois l’infection nettoyée, une faille de configuration peut permettre une nouvelle compromission rapide. Par exemple, l’exécution de scripts dans uploads est une mauvaise idée même en situation normale.
Après récupération: validation et retour en ligne
Une fois le nettoyage terminé, vous devez valider le comportement. Ce n’est pas juste “ça marche”. Il faut vérifier les symptômes:
- Les redirections ont-elles cessé pour plusieurs navigateurs et plusieurs types de connexions? Les pages qui étaient touchées sont-elles stables? Le spam a-t-il cessé ou diminue-t-il immédiatement? Les comptes suspects ont-ils été supprimés et les accès sécurisés?
Sur certains sites, le spam peut continuer un peu après le nettoyage si des envois étaient déjà planifiés. Dans ce cas, vous devez vérifier les tâches planifiées et supprimer les actions récurrentes non désirées.
Si vous utilisez un CDN ou un cache, n’oubliez pas que des pages en cache peuvent masquer le retour de l’infection pendant un moment. Pensez à purger le cache ou désactiver temporairement le cache pour tester avec des requêtes fraîches.
Renforcer pour ne pas revivre le même scénario
https://gardewp.fr/Une fois tout en place, la meilleure défense est celle qui rend l’attaque difficile et la détection facile.
Là encore, il n’y a pas un seul bouton miracle. Les améliorations concrètes et raisonnables sont celles qui réduisent le risque, en particulier sur l’authentification et la surface d’exécution.
Si vous devez choisir quelques actions à fort impact, voici celles que je recommande le plus souvent:
- activer l’authentification à deux facteurs pour les administrateurs imposer des mots de passe solides et uniques, et désactiver les anciens comptes mettre à jour WordPress, thèmes, et extensions, supprimer le superflu limiter l’accès à la zone admin quand c’est possible empêcher l’exécution de PHP dans uploads
Ce sont des barrières simples, mais elles changent réellement la probabilité de récidive.
Si vous êtes bloqué: quand demander de l’aide sans perdre le contrôle
Il arrive que vous soyez confronté à un site trop complexe, ou à une infection trop subtile, ou à des accès serveur impossibles. Dans ce cas, vous pouvez demander de l’aide, mais gardez le contrôle sur deux points.
D’abord, exigez une approche “preuves d’abord”. Qui identifie le fichier responsable, qui explique ce qui a été supprimé et pourquoi, qui prouve que la redirection ne revient pas après remise en ligne.
Ensuite, demandez une liste des modifications faites. Sur un site WordPress, le “nettoyé” vague n’est pas suffisant. Vous voulez savoir quels fichiers ont été remplacés, quels utilisateurs ont été retirés, quelles règles .htaccess ont été changées, et quelles mises à jour ont été appliquées.
La bonne intervention, c’est celle qui vous rend autonome ensuite. Sinon, vous risquez de retomber dans la même situation.
Le vrai bénéfice: un site récupéré, mais aussi compris
Un nettoyage “réussi” est celui qui met fin aux redirections et au spam, oui. Mais surtout, c’est celui qui transforme un épisode de crise en compréhension durable de votre site: quelles extensions existent réellement, quels thèmes tournent en production, quels accès sont utilisés, quelles règles protègent vos fichiers, et comment votre back-office est exposé.
Si vous avez déjà vécu une infection, vous le savez, l’urgence est réelle. Pourtant, le nettoyage efficace est rarement une question de vitesse seule. C’est une combinaison de méthode, de vérification, et de correction des causes.
Quand on traite WordPress infecté proprement, on ne “répare pas”, on prépare le terrain pour ne plus recommencer.