Une infection WordPress laisse rarement des traces “propres”. Souvent, tout commence par un détail: une hausse de trafic qui n’a aucun sens, des redirections bizarres, des emails sortants qui partent “du site”, ou simplement un site qui affiche parfois une page différente selon l’heure. J’ai déjà vu des sites où le problème semblait mineur, puis où tout s’est aggravé en une nuit, après une tentative de “nettoyage” à la hâte qui avait en réalité remis en place une partie du mécanisme d’infection.
Nettoyer après une intrusion ne consiste pas à supprimer un fichier malveillant et à espérer que tout repart. L’objectif, c’est de briser la chaîne: comprendre comment l’attaque a obtenu un accès, retirer les composants persistants, corriger les causes, et surtout éviter de réinjecter la même faille en remettant un mauvais dossier ou une vieille version compromise.
Je vais détailler une méthode pragmatique pour repartir proprement, avec des points d’attention réalistes, des pièges fréquents, et des arbitrages. Ce guide vise une “sécurité WordPress” efficace, pas une posture théorique.
Ce que signifie “infection” dans WordPress
Dans WordPress, une “infection” peut être très différente selon la porte d’entrée.
- Parfois, c’est un plugin ou un thème compromis, ou un thème “piraté” qui contient un chargeur. Parfois, c’est un compte administrateur pris en main via un mot de passe faible, réutilisé, ou via une faille de plugin non corrigée. Parfois, c’est une modification silencieuse: une tâche cron malicieuse, une reconfiguration .htaccess, ou du code ajouté dans un fichier d’édition (souvent pas à l’endroit où on le regarderait en premier).
Le même résultat visible, “le site est redirigé”, peut venir de causes opposées. J’ai connu un cas où tout pointait vers un plugin “SEO”, alors que la vraie source était une compromission de compte, et le plugin ne servait que d’outil pour déclencher la génération de pages frauduleuses.
Avant de toucher au site, l’approche la plus efficace consiste à se poser une question simple: qu’est ce qui persiste après redémarrage, purge de cache, désactivation de plugins, ou changement de thème? Cette observation aide à classer le problème et à choisir une stratégie de nettoyage.
La première règle: ne pas casser l’enquête
Quand on découvre une compromission, le réflexe “supprimer tout” peut sembler logique, mais il peut ruiner vos chances d’identifier la cause. Si vous supprimez immédiatement des fichiers, changez tous les mots de passe et supprimez des logs, vous perdrez les preuves utiles.
Le minimum que je recommande, c’est de travailler sur une copie de travail:
- sauvegarde complète des fichiers (web root, wp-content, éventuellement le reste si vous avez une configuration atypique), export base de données, copie des logs disponibles (serveur web, PHP, accès, errors, et logs applicatifs si vous en avez).
Dans la pratique, vous n’avez pas besoin d’un “laboratoire” pour bien faire. Une copie des répertoires web et une export SQL suffisent déjà à éviter de tout regretter.
Ensuite, mettez un frein sur la propagation. Si votre site est utilisé pour distribuer du contenu frauduleux, le laisser actif pendant le nettoyage peut accélérer l’empoisonnement des caches, multiplier les serveurs de commande et contrôle qui vous remarquent, et surtout vous ajouter des traces de modification continue. Une mise en maintenance propre est souvent plus utile qu’un silence total.
Mettre le site en sécurité sans le rendre invisible
Mettre WordPress en maintenance n’est pas seulement une question “d’UX”. C’est aussi une façon de réduire le trafic vers les zones compromises pendant que vous contrôlez.
Selon votre hébergeur et votre configuration, vous pouvez opter pour:
- une page de maintenance côté serveur, un verrouillage temporaire via un accès restreint (IP whitelisting si c’est possible), ou une désactivation du front sans toucher à la base de données.
Évitez d’écraser brutalement la configuration si vous n’avez pas de sauvegarde. L’idée, c’est de continuer à accéder à des éléments internes (pour audit et accès contrôlé) tout en empêchant les visiteurs d’être redirigés vers du contenu malveillant.
Comprendre les signes avant de supprimer
Les signes d’infection donnent des indices. Prenez le temps d’observer, même brièvement, et sans paniquer.
Si vous constatez des redirections, testez depuis plusieurs contextes: navigateur “propre” (mode navigation privée), réseau mobile vs fixe, et idéalement un outil de test externe si vous en avez. Le but n’est pas de devenir analyste réseau, mais de repérer si le comportement dépend d’un paramètre, d’un cookie, d’un user-agent, ou d’une origine.
Un autre indice utile: l’échelle du problème. Un petit nombre de pages “polluées” peut indiquer une compromission ciblée (quelques fichiers). Une pollution massive, des URLs multiples, ou des appels distants réguliers suggèrent plutôt une persistance plus organisée.
La stratégie de nettoyage qui marche en production
Nettoyer “proprement” veut dire: retirer ce qui est malade, remettre ce qui est sain, vérifier ce qui reste, puis corriger ce qui a permis l’intrusion.
Je recommande une séquence en quatre temps, généralement efficace même quand vous n’êtes pas certain de la cause au départ.
1) Couper l’accès et réinitialiser le contrôle
La première action après la sauvegarde, c’est de verrouiller tout ce qui peut ré-exécuter l’infection.
Concrètement, changez tous les mots de passe liés à l’administration WordPress et à l’hébergement si vous avez des accès multiples. Si vous utilisez un système d’accès à l’hôte (FTP, SFTP, SSH), changez aussi ces identifiants, ou au moins vérifiez la configuration des clés.
Ensuite, examinez la liste des utilisateurs WordPress et repérez tout compte nouveau, tout rôle inattendu, et toute modification de profil. Un détail que j’ai appris à ne jamais négliger: certains intrus laissent un compte “éditeur” discret, puis l’utilisent à un moment précis. Si vous ne supprimez pas ce compte, vous pouvez nettoyer le code, mais l’attaque revient dès qu’ils reviennent.
Pensez aussi aux tokens ou à la persistance côté navigateur si vous testez depuis votre machine. Un cookie de session peut cacher le vrai comportement. Pour les tests, utilisez un contexte vierge.
2) Remettre WordPress dans un état “réinitialisé”
Quand un site est compromis, j’ai rarement envie de “réparer” au millimètre. La réparation partielle peut laisser une porte ouverte.
Le plus robuste est de comparer vos fichiers aux fichiers originaux de WordPress et de réinstaller ce qui doit l’être.
Procédez en conservant seulement ce qui ne devrait pas être compromis: la base de données, les médias (si vous êtes raisonnablement sûr qu’ils n’ont pas été utilisés comme vecteur), et éventuellement un ensemble restreint de contenus. Mais pour les fichiers WordPress “core” et la structure standard, repartez d’une version propre.
Ce point devient crucial sur deux catégories:
- le dossier racine WordPress et les fichiers core, certains fichiers à risque de modification indirecte (index, wp-admin, scripts chargés, configuration serveur si elle a été altérée).
Si votre site a des personnalisations dans ces fichiers, vous devrez les réappliquer, mais uniquement après identification des modifications.
3) Nettoyer wp-content avec méthode
La majorité des surprises se trouve dans wp-content. Là aussi, on peut aller vite, mais on doit le faire intelligemment.
Regardez les plugins et thèmes activés, puis ceux récemment modifiés. Vérifiez l’existence de fichiers inhabituels dans ces dossiers, notamment:
- des fichiers PHP créés récemment, des noms de fichiers “banals” mais contenant du code suspect, des inclusions vers des URL distantes, des scripts qui se déclenchent selon des conditions (heure, langue, pays, cookie).
Dans un incident, j’ai vu un chargeur basé sur un simple “if” conditionnel, déclenché seulement pour certains navigateurs. En testant depuis un contexte différent, on pense être en sécurité alors que l’infection reste active. Ce genre d’erreur arrive vite si on se limite à un seul type de test.
Même logique pour les fichiers du dossier uploads si vous hébergez des médias. Normalement, les médias ne devraient pas contenir du PHP, sauf si vous avez autorisé une exécution dans un sous-dossier ou si quelqu’un a trouvé un chemin technique. Vérifiez l’existence de fichiers de code dans wp-content/uploads et surveillez les extensions inattendues.
4) Réparer la base de données, puis vérifier la persistance
Une infection peut persister dans la base de données: options modifiées, injections dans des champs, tâches planifiées, contenu frauduleux, ou paramètres qui déclenchent une redirection.
Après un nettoyage des fichiers, la base peut continuer à propulser l’infection. C’est un scénario fréquent: vous remplacez des thèmes et plugins, mais un paramètre dans la base appelle encore un script.
Là, les contrôles “efficaces” consistent à:
- vérifier les options anormales, contrôler les contenus publiés ou modifiés sans raison, examiner les utilisateurs et leurs métadonnées, inspecter la présence de tâches planifiées (cron) qui n’ont rien à faire sur votre site.
Selon votre configuration, les tâches planifiées peuvent être gérées par WordPress lui-même ou par un système externe. L’objectif est d’identifier ce qui a été ajouté pendant l’intrusion.
Les indicateurs techniques à ne pas sous-estimer
Une fois que vous avez remis le core et isolé le contenu, il reste des zones où l’infection se “cache” bien. Je cite ici des signaux qui reviennent en pratique.
Le rôle de la configuration serveur
Si votre site est sur Apache, la configuration dans .htaccess peut être modifiée pour injecter des redirections, pour charger des scripts, ou pour contourner des règles de sécurité. Sur Nginx, ce n’est pas le même fichier, mais l’idée reste: vérifier que la configuration n’a pas été altérée.
Même si vous n’avez pas la certitude que le problème vient de là, contrôlez la configuration autour de:
- redirections, exécutions autorisées dans des dossiers non standards, règles de réécriture.
C’est un point que beaucoup de gens oublient, parce qu’ils se concentrent sur WordPress. Pourtant, un intrus peut “prendre le volant” dès la couche serveur.
Les fichiers temporaires et les scripts “orphelins”
Quand un code malveillant est retiré, il peut rester des morceaux, des fichiers de chargement, des caches d’objets, ou des dossiers créés pour servir de point d’entrée.
Je garde une règle simple: si un fichier ou un dossier est anormal par son existence ou par sa date de modification, je l’examine avant de décider. Ce n’est pas du perfectionnisme, c’est une méthode pour éviter le “faux net”.
La persistance via des plugins “très propres”
Les plugins peuvent être trompeurs. Un plugin “connu” peut rester en place et déclencher l’infection via une configuration ou un paramètre. À l’inverse, un plugin inconnu peut sembler insignifiant, mais être la pièce maîtresse.
Le https://gardewp.fr/securite-wordpress/ bon réflexe consiste à associer l’observation à un contrôle concret. Désactiver des plugins, oui, mais ne pas supposer que “tout va bien” si le front semble correct pendant une minute. Dans plusieurs cas, le comportement malveillant revient après un délai, ou à une condition. Il faut tester dans le même contexte que les visiteurs.
Un plan de vérification après nettoyage
Après avoir nettoyé, le risque n’est pas seulement de laisser un fichier compromis. Le risque, c’est de redémarrer avec un mélange incohérent, une base partiellement restaurée, ou une configuration réinjectée.
Voici un plan simple, conçu pour limiter les angles morts sans transformer votre incident en audit de laboratoire.
Tester le site en navigation privée et avec un autre réseau, pour vérifier les redirections et scripts. Contrôler l’intégrité des fichiers core WordPress et vérifier que les fichiers modifiés sont ceux que vous attendez. Relire la liste des utilisateurs et supprimer tout compte suspect, même si le site “semble fonctionner”. Vérifier dans la base les options anormales, puis contrôler les contenus nouvellement créés ou modifiés. Surveiller les logs quelques heures, pas seulement quelques minutes.Ce déroulé est volontairement pragmatique. Il se base sur ce que j’ai vu le plus souvent: l’infection réapparaît, et ce sont les tests trop “rapides” qui font rater les signaux.
Redémarrer “proprement” sans réintroduire l’infection
Quand le site “revient”, on a tendance à vouloir tout rouvrir immédiatement: réactiver les plugins, remettre les thèmes, publier du contenu. Parfois, c’est acceptable. Souvent, c’est trop tôt.
Le redémarrage propre passe par l’idée suivante: chaque action doit réduire votre surface d’erreur, pas la multiplier.
Commencez par la version la plus simple du site. Si vous devez réactiver des extensions, réactivez par lots, et testez entre chaque lot. Si l’infection réapparaît, vous identifiez rapidement la zone responsable.
Il faut aussi considérer un détail pratique: les caches. Un cache peut masquer un retour d’infection. Même si le front semble sain, une URL spécifique peut déclencher une redirection et contaminer un index. Donc, testez des pages qui étaient touchées, et pas seulement la page d’accueil.
Corriger la cause, pas seulement les symptômes
Si vous ne corrigez pas la cause, vous aurez un deuxième incident. La cause n’est pas toujours technique au sens “un fichier a été modifié”. Elle peut être humaine: un accès faible, un plugin obsolète, un mot de passe partagé, ou un manque de rotation.
Les causes les plus fréquentes que je vois sur des sites WordPress compromis:
- plugin ou thème non mis à jour avec une vulnérabilité connue, mot de passe d’administration faible ou réutilisé, absence de verrouillage après tentatives de connexion, permissions trop larges sur des dossiers sensibles, accès FTP/SFTP/SSH partagé ou peu contrôlé.
Une fois l’incident nettoyé, je recommande d’ajouter un niveau de discipline minimal:
- mises à jour régulières, suppression des thèmes et plugins inutilisés, gestion des rôles (accès d’administrateur réservés strictement), journalisation et surveillance.
C’est moins “spectaculaire” qu’un nettoyage, mais c’est ce qui fait la différence entre un incident isolé et une récurrence.
Points d’attention pour la base de données
Nettoyer la base de données demande de la prudence. Supprimer au hasard des entrées peut casser le site, et ne pas supprimer assez peut laisser l’attaque revenir.
En pratique, je procède par logique:
- d’abord, identifier ce qui a été modifié récemment, ensuite, retirer ce qui est évident (contenu frauduleux, utilisateurs ajoutés), enfin, vérifier les champs liés à la configuration.
Un piège courant: restaurer la base depuis une sauvegarde ancienne trop tardive après infection. Si la sauvegarde contient encore les modifications malveillantes, vous réinjectez l’intrus. L’inverse est aussi vrai: si vous restaurez trop tôt, vous perdez du contenu légitime.
Le choix dépend de vos sauvegardes disponibles. Si vous avez des snapshots rapprochés, vous pouvez être plus précis. Si vous n’en avez qu’un seul, vous devez accepter certains compromis et tester davantage.
Désinstaller l’inattendu: thèmes, plugins, et fichiers de cache
Après une infection, je conseille de faire le tri, mais pas de manière aveugle.
- Si un plugin a été utilisé comme vecteur, le supprimer est souvent plus sûr que le désactiver. Si un thème n’est pas indispensable, partez sur un thème standard propre et travaillez ensuite sur votre thème en local ou dans une base saine, avant de le réinstaller.
Concernant les caches et minifications, ils doivent être remis à zéro. Un cache peut contenir du contenu injecté, et si vous le laissez, vous pourriez “croire” que le site est propre alors qu’il sert encore la version contaminée.
Sur WordPress, selon les outils (cache plugin, CDN, cache serveur), la purge peut être multiple. Je préfère lancer une purge complète côté plugin, puis contrôler côté CDN si vous en avez un, puis vérifier sur un contexte sans cache.
Sécurité WordPress après incident: ce qui change vraiment
Une fois le site reparti, l’objectif n’est pas d’ajouter quinze protections. L’objectif est de rendre votre site plus difficile à compromettre et plus facile à diagnostiquer la prochaine fois.
Voici ce que j’ai tendance à privilégier après un incident, quand le budget est limité:
- comptes: rotation des mots de passe, limitation des rôles, suppression des comptes inutiles, mots de passe: privilégier des passphrases et l’authentification à facteurs multiples quand c’est disponible, mises à jour: plugins et thèmes supprimés ou mis à jour, core régulièrement, durcissement: permissions minimales et gestion des accès serveurs, surveillance: logs et alertes, au moins une vérification quotidienne.
C’est une logique de “réduction de probabilité” et “réduction de temps de réponse”. Si une attaque recommence, vous voulez la détecter plus tôt, et vous voulez savoir où chercher.
Comparer deux approches: patcher vs réinstaller
Quand on veut repartir proprement, une question revient tout le temps: est ce qu’on répare en gardant tout, ou est ce qu’on réinstalle une base propre et on remplace ce qu’il faut?
Voici une comparaison rapide qui reflète les choix que j’ai vus fonctionner.
| Approche | Avantages | Risques | |---|---|---| | patcher en inspectant fichier par fichier | utile si l’incident est très localisé et que vous êtes sûr de ce que vous supprimez | très facile de rater un petit chargeur caché ou un paramètre en base | | réinstaller le core et assainir wp-content et la base avec contrôle | robuste, réduit le doute, meilleure probabilité de repartir sain | peut demander plus de travail si vous avez beaucoup de personnalisations, risque de mauvaise restauration si sauvegardes imparfaites |
Mon point de vue pratique: quand vous n’avez pas une certitude forte sur l’origine, l’approche “assainissement structuré” est souvent plus rentable qu’un patch “au feeling”.
Cas concrets, pour ne pas être surpris
Je vous décris trois scénarios, parce qu’ils reviennent souvent et qu’ils changent la stratégie.
Le site redirige uniquement pour certains visiteurs
Vous constatez une redirection sur mobile, mais pas sur desktop. Vous n’observez pas de problème en navigation privée, mais il revient sur un navigateur “normal” avec des cookies.
Ici, l’infection peut dépendre de conditions, ce qui signifie que votre test doit reproduire le contexte. La remise à zéro du cache, le contrôle des cookies et la validation sur plusieurs contextes sont indispensables. Le nettoyage de fichiers “simples” peut sembler suffisant, mais si la persistance vient de la base, vous n’aurez pas fini.
Un plugin “connu” a été mis à jour juste avant l’incident
Parfois, un plugin mis à jour coïncide avec l’infection. Le piège, c’est de croire que la mise à jour est forcément la cause. Elle peut être la dernière pièce en date, mais pas la cause.
Ce que je fais: je remonte l’historique, je contrôle les fichiers du plugin, et je vérifie les options et tâches planifiées associées. Si la modification vient en base, le plugin est peut être un déclencheur plutôt qu’une source.
Les comptes administrateurs ne sont pas tous “visibles”
WordPress peut cacher des indices. Dans certains incidents, les utilisateurs “normaux” restent propres, mais il y a un compte ajouté et peu utilisé. Parfois, un compte est créé avec un rôle discret, puis il est utilisé seulement à une heure précise ou à une condition.
La réponse, c’est la vérification exhaustive des utilisateurs et l’examen des changements récents. Ne vous contentez pas d’une inspection superficielle, et n’oubliez pas les comptes créés via des plugins d’inscription ou de gestion.
Checklist finale de remise en service
Après nettoyage, avant de déclarer le site “terminé”, je fais toujours une série de contrôles. C’est là que les surprises sortent.
- vérification utilisateurs et rôles, vérification du contenu fraîchement modifié, contrôle des options et des tâches planifiées, tests de redirection et de pages touchées depuis plusieurs contextes, surveillance logs sur une période courte.
Si vous voulez une règle simple: plus l’incident a été “bruyant” (beaucoup de modifications, redirections, trafic anormal), plus vous devez être exigeant sur la vérification. Quand l’incident est silencieux, vous avez besoin de tests variés, sinon vous ne verrez pas les conditions de déclenchement.
Et si vous n’avez pas assez de temps ou de logs
Il arrive qu’on doive agir vite, surtout en cas d’urgence opérationnelle. Dans ces situations, la meilleure stratégie consiste à maximiser les actions qui réduisent l’incertitude.
- réinstaller core proprement, inspecter et remplacer wp-content si vous êtes sûr que les fichiers suspects ont été identifiés, remettre en place une base saine en s’appuyant sur la sauvegarde la plus proche et vérifiable, surveiller les logs après mise en ligne.
Même sans comprendre exactement “comment” l’attaque a commencé, ce type de remise en état réduit fortement la probabilité de persistance.
Dernier point: préparer la prochaine fois
Nettoyer après infection est une mission difficile, mais elle devient supportable quand vous avez déjà préparé votre terrain.
À moyen terme, investissez dans des sauvegardes fiables, des snapshots fréquents et une routine de mise à jour. Ajoutez aussi une surveillance simple. Vous n’avez pas besoin d’un centre de supervision, mais vous avez besoin de savoir si le site change sans votre intervention.
La sécurité WordPress, ce n’est pas seulement une barrière. C’est la combinaison entre prévention, détection, et capacité de reprise. Nettoyer après infection, c’est la partie “reprise”. Pour que ça ne recommence pas, il faut que la prévention et la détection soient en place avant le prochain incident.
Si vous avez des éléments spécifiques de votre cas (type de redirection, comportement, plugins récents, présence de fichiers suspects, logs), je peux vous aider à structurer le diagnostic et à décider ce qui doit être remplacé ou restauré en priorité.