Quand un site WordPress est compromis, la première tentation est simple: “on nettoie, et ça repart”. Sur le terrain, ça marche parfois, mais la récidive est fréquente. Le virus ne s’installe pas toujours “une fois pour toutes”. Souvent, il laisse des portes dérobées, des identifiants réutilisables, des tâches planifiées, ou il exploite une faille que vous n’avez pas traitée en même temps que le nettoyage.
J’ai déjà vu des sites revenir deux jours après la correction: même redirections, mêmes pages parasites, mêmes comptes réactivés. Le nettoyage avait été fait, mais le système d’accès ne l’avait pas été, ou la vulnérabilité d’origine n’avait pas été éliminée. La bonne approche consiste à séparer la logique en deux étages: enlever ce qui est visible et surtout neutraliser ce qui permet de revenir.
Reconnaître le vrai problème, pas seulement les symptômes
Un “virus WordPress” est un terme pratique, mais il cache plusieurs scénarios. Parfois, il s’agit d’un code malveillant dans un fichier thématique ou plugin. D’autres fois, le contenu frauduleux est injecté via une base de données, ou via des scripts côté serveur (fichiers dans wp-content/uploads, cron système, ou fichiers temporaires).
Il y a aussi des cas où WordPress n’est pas la cible principale. Une compromission d’identifiants chez un fournisseur (hébergement, FTP, compte email, panneau d’administration) peut servir de pivot. Dans ce scénario, même après suppression des fichiers suspects, le prochain auteur malveillant réapparaît.
Avant de “tout supprimer”, il faut faire deux choses en parallèle: comprendre comment l’accès a été obtenu, et cartographier ce qui a été modifié. Sinon, vous risquez de corriger le mauvais endroit et de laisser la chaîne de compromission intacte.
Indices concrets que j’ai appris à surveiller
Les signaux les plus utiles ne sont pas toujours spectaculaires. Le plus parlant est la répétition. Si des URL sont créées, si des redirections reviennent, ou si des comptes réapparaissent, c’est rarement un simple fichier oublié.
D’autres indices reviennent souvent:
- Des fichiers PHP ajoutés ou modifiés dans wp-content/ avec des noms “bizarres” ou des horodatages récents. Des plugins ou thèmes qui changent alors que vous n’avez rien mis à jour. Des tâches planifiées (WP-Cron) qui continuent de s’exécuter alors que vous avez supprimé un plugin. Des modifications dans la base, notamment dans les tables liées aux options, aux utilisateurs, ou à la configuration de certaines fonctions.
L’idée n’est pas de tout maîtriser en profondeur immédiatement, mais d’avoir assez d’observations pour orienter vos actions. Quand on enlève virus WordPress, on agit plus efficacement si on sait d’où vient l’infection.
Nettoyer sans casser: méthode de travail et ordre des opérations
Un nettoyage “au marteau” est tentant. Supprimer des dossiers et réinstaller WordPress peut régler un incident, mais ça peut aussi effacer des données légitimes et vous faire perdre du temps. Mon approche privilégie l’ordre suivant, parce qu’il limite le risque de réinfection pendant que vous travaillez.
D’abord, sécurisez l’accès. Ensuite, isolez l’environnement (au minimum en bloquant certaines exécutions ou en rendant le site temporairement inaccessible). Puis, vérifiez les fichiers et les bases, remettez en état la partie “propre”, et enfin seulement, réactivez et surveillez.
Le piège classique, c’est de nettoyer la couche visible alors que le serveur exécute encore des tâches ou que des identifiants volés permettent de réinjecter du code. Tant que l’accès n’est pas verrouillé, le site est comme une maison où vous enlevez les meubles, mais où quelqu’un a encore les clés de la serrure.
Verrouiller l’accès: l’étape qui évite la récidive
Avant même de toucher aux fichiers, il faut traiter ce qui permet à l’attaquant de revenir. Sur un site WordPress, l’accès peut être compromis via plusieurs entrées: mot de passe, cookie de session volé, clé API, compte admin ajouté, accès via l’interface d’hébergement, ou même un compte FTP.
J’ai vu un cas simple: le propriétaire avait “nettoyé” des fichiers, puis le site s’est re-empoisonné. En investiguant, on a découvert un compte administrateur créé la veille, avec un email différent et un rôle complet. Il était masqué dans le flux normal, car l’attaquant avait modifié légèrement la façon dont WordPress affichait certains éléments. Tant que ce compte existait, le problème était reproductible.
Contrôles rapides d’accès (et seulement après)
Si vous avez accès à l’admin WordPress, faites en priorité un audit des comptes, des sessions et des réglages de base. Si vous n’y avez plus accès, contrôlez côté hébergement.
Voici les actions que je recommande en premier, dans un ordre qui limite la réinfection:
- Désactiver temporairement les plugins non essentiels (et si possible, passer le site en maintenance). Rechercher et supprimer les comptes utilisateurs inconnus, et vérifier les rôles. Réinitialiser tous les mots de passe WordPress, SFTP/FTP, base de données, et comptes liés. Vérifier les réglages de thèmes et plugins, y compris les fichiers fraîchement modifiés. Contrôler les tâches planifiées (WP-Cron et, si l’hébergement l’autorise, cron système).
Cette mini-liste n’est pas une “recette magique”. Elle sert à briser le cycle d’accès pendant que vous analysez et remettez en état.
Inspecter les fichiers sans se noyer
Le nettoyage de fichiers est souvent l’étape la plus longue, parce qu’il faut distinguer “ce qui a été modifié” de “ce qui est légitime”. Sur WordPress, beaucoup de fichiers changent au fil du temps: mises à jour, caches, minification, sauvegardes, logs.
Ce que vous cherchez, ce sont des comportements anormaux:
- Des fonctions PHP ajoutées qui obfusquent le code (chaînes codées, base64, gabarits de code qui déclenchent du contenu selon l’agent utilisateur). Des accès à des fichiers ou des URL externes, surtout si ce n’est pas cohérent avec votre activité. Des fichiers dans des répertoires inhabituels pour vos habitudes, par exemple directement dans la racine ou dans des sous-dossiers non utilisés.
Une méthode pratique consiste à comparer votre installation actuelle à une version “propre” connue (même une base WordPress fraîche et vos dossiers wp-content légitimes). Si vous avez des sauvegardes antérieures, c’est l’option la plus fiable. Sinon, un export de l’état actuel vous permet au moins de revenir en arrière après une suppression.
Le cas fréquent: plugins compromis, pas thèmes
Sur beaucoup de sites, les plugins sont la porte d’entrée la plus probable. Les plugins “gratuits” ou “abonnés à la maintenance légère” augmentent le risque. Mais je ne conclurais pas trop vite: un thème peut aussi être compromis, surtout si vous avez un atelier de customisation, ou des scripts ajoutés “juste pour tester”.
Dans la pratique, ce que je fais est pragmatique: je mets hors ligne tout ce qui n’est pas vital, je teste l’affichage avec un thème minimal, puis je reviens plugin par plugin. Ce travail prend du temps, mais il permet de localiser la source sans effacer des choses au hasard.
Contrôler la base de données: là où la récidive se cache souvent
Même si vous nettoyez les fichiers, la base peut continuer à contenir des entrées malveillantes. Les attaquants utilisent des manières diverses d’injecter: en modifiant des options, en ajoutant des scripts à exécution automatique, en réécrivant certains paramètres, ou en manipulant des champs liés au rendu.
Sur un incident réel, j’ai déjà vu des injections invisibles dans l’interface: l’administration affichait correctement les articles, mais une couche PHP côté front ajoutait des liens et déclenchait des redirections. La partie “fichier” avait été modifiée, mais la logique venait d’options stockées dans la base.
Il faut donc examiner des éléments comme:
- Les options WordPress modifiées récemment. Les utilisateurs ajoutés ou dont le rôle a été changé. Les tables liées aux événements ou au stockage des données temporaires (selon votre version et vos plugins). Les mécanismes d’export ou d’import qui pourraient garder une configuration infectée.
Ne cherchez pas seulement le texte “malveillant”. Souvent, le code est présent ailleurs et le contenu visible est un effet secondaire. L’objectif est de comprendre le mécanisme d’exécution.
Réinstaller proprement: quand c’est la meilleure décision
Quand l’infection est étendue, une réinstallation partielle peut faire gagner beaucoup de temps. Typiquement, vous gardez wp-content après nettoyage et vous réécrivez le reste depuis une version propre de WordPress.
Je recommande ce choix quand:
- Vous avez de nombreux fichiers modifiés, avec des horodatages très variés. Vous n’êtes pas certain de l’origine. Le site a montré des comportements multiples (redirections, spam, contenu injecté, tentatives de connexion).
La règle d’or est de ne pas “réinjecter” un noyau potentiellement infecté. Les fichiers de WordPress (le cœur) sont simples à réobtenir. En revanche, wp-content contient votre travail et vos extensions, donc il faut le traiter comme une zone à risque.
Si vous décidez de réinstaller, faites-le après avoir figé l’état. Sinon, vous supprimez des preuves utiles. Il vaut mieux conserver une copie du système avant modification, même si vous n’avez pas encore toutes les réponses.
Empêcher le retour: un plan de prévention réaliste
Le vrai plan de prévention n’est pas une liste de souhaits. Il doit tenir compte de votre organisation, de votre budget, de votre capacité à surveiller, et des contraintes d’exploitation (par exemple, si vous avez besoin de mises à jour fréquentes, ou si vous maintenez des plugins spécifiques qui mettent du temps à être remplacés).
Le but est de réduire trois choses: la surface d’attaque, la durée de vie des accès, et les angles morts de surveillance.
Les points durs à traiter après un incident
Je conseille de formaliser la prévention en deux niveaux: ce qui doit être fait immédiatement, puis ce qui doit être maintenu. L’immédiat vise la récidive à court terme. Le maintenu évite qu’un futur incident passe en silence.
Voici cinq mesures prioritaires, celles que j’ai vues avoir le plus d’impact sur la récidive:
- Activer une authentification à deux facteurs pour tous les comptes administrateurs (et supprimer tout usage d’anciens méthodes). Mettre en place une politique de mots de passe robuste, y compris pour les accès hébergement et base de données. Mettre à jour le plus vite possible WordPress, thèmes et plugins (en ciblant d’abord les composants les plus exposés). Supprimer ou remplacer les plugins et thèmes non maintenus, surtout ceux dont le code est incomplet ou obsolète. Renforcer la limitation de l’accès (blocage géographique si pertinent, limitation du nombre de tentatives, surveillance des login).
Même si vous avez nettoyé “parfaitement”, ces gestes changent la donne. Ils empêchent l’attaquant de revenir avec les mêmes méthodes.
Durcir les accès: plus que le “mot de passe”
Un incident laisse souvent des traces dans le temps. Un mot de passe réinitialisé ne suffit pas si des sessions restent actives, si des identifiants sont stockés dans un outil de déploiement, ou si quelqu’un a créé un accès persistant via l’hébergement.
Un point souvent oublié: les comptes administrateurs ne sont pas les seuls. Les comptes “éditeur”, “auteur”, ou des intégrateurs peuvent avoir des capacités suffisantes pour réinjecter des contenus ou installer des composants.
Je recommande aussi de vérifier les accès au niveau serveur. Sur beaucoup d’hébergements, le panneau de contrôle, les accès SFTP et les clés SSH peuvent être utilisés sans passer par WordPress. Si l’attaquant a compromis un seul accès, il peut maintenir un mécanisme d’injection indépendant.
Sécurité applicative: plugins, thèmes et habitudes de mise à jour
La sécurité WordPress repose beaucoup sur l’hygiène de dépendances. Vous ne pouvez pas tout auditer à la main à chaque incident, mais vous pouvez construire une démarche qui réduit le risque.
Quand je conseille un plan de prévention, je parle rarement d’un outil unique. Je parle de discipline.
- Mettre à jour régulièrement, mais pas “au hasard”. Remplacer ce qui n’est plus maintenu, même si ça marche. Éviter les plugins qui font “un peu de tout”, surtout ceux qui ajoutent du code PHP ou des scripts chargés à distance. Limiter le nombre d’extensions actives, surtout celles qui n’ont pas de rôle essentiel.
Un exemple concret de mauvais arbitrage
Sur un site e-commerce, un plugin “SEO” et un plugin “cache” étaient installés ensemble. Après incident, le cache était suspect, le plugin SEO aussi. L’équipe a d’abord tout réinstallé, puis a redéployé “tous les réglages” depuis une ancienne sauvegarde.
Résultat: une partie de configuration malveillante s’est réactivée, pas via le code principal, mais via des paramètres. Le problème était revenu parce qu’on avait restauré des valeurs contaminées, pas seulement des fichiers. Ce genre d’erreur arrive quand on traite la restauration comme une copie pure.
Après ça, ils ont fait une restauration ciblée et ont conservé uniquement le contenu (articles, pages, médias) et les paramètres qui n’étaient pas liés aux mécanismes d’injection.
Surveiller ce qui doit l’être, sans noyer l’équipe
La surveillance est le dernier rempart, mais elle ne doit pas devenir une charge impossible. L’idée est d’obtenir des signaux utiles.
Les scénarios qui reviennent le plus:
- Détection de nouvelles modifications de fichiers dans des zones sensibles. Alertes sur des changements d’utilisateurs ou de rôles. Détection de contenu anormal dans des pages clés ou dans des redirections. Alertes sur des pics d’erreurs PHP ou de trafic sur des endpoints non attendus.
Je privilégie une combinaison: surveillance technique côté serveur, et vérification applicative simple. Par exemple, un contrôle hebdomadaire du fichier de configuration, du niveau de debug, et de la liste des plugins peut suffire pour détecter un “re-dépôt” avant que le moteur de recherche ne capture les pages contaminées.
Vérifications régulières que j’ai vues fonctionner
Sans entrer dans des listes, je peux citer des routines efficaces: revérifier les plugins actives après mise à jour, regarder les dates de modification sur les dossiers de thèmes et plugins, exporter la liste des utilisateurs et la comparer à une “référence”, et vérifier les événements liés à la planification.
Sur un site avec beaucoup d’auteurs, cette routine doit être adaptée. Si vous avez dix contributeurs qui travaillent réellement, vous ne cherchez pas à bloquer toute nouveauté. Vous cherchez à comprendre “pourquoi” une nouveauté est apparue. C’est cette explication qui manque souvent après un incident.
Réduire le risque de vecteurs “humains”
Les attaques ne sont pas uniquement techniques. Une partie des infections passe par l’humain, via du phishing, des mots de passe réutilisés, ou des sessions compromises.
Dans la prévention, il y a donc un volet de process:
- Former les administrateurs et éditeurs à repérer les demandes douteuses (liens, pièces jointes, faux sites de connexion). Vérifier les adresses email associées aux comptes et aux outils d’administration. Limiter les personnes qui peuvent installer ou activer des plugins, selon vos besoins.
Je l’ai constaté dans les équipes avec plusieurs contributeurs: quand tout le monde a “tous les droits”, le risque de récidive augmente, même si les mots de passe sont forts. Une personne peut installer un plugin en pensant que c’est une bonne idée, et le plugin peut être le cheval de Troie.
Choisir la bonne approche si vous êtes déjà “infecté”
Le contexte change selon que vous avez encore accès à l’administration, ou que le site est déjà instable.
Si vous avez accès à l’admin, vous pouvez chercher des modifications et verrouiller rapidement. Si vous n’avez plus accès, ou si le site est bloqué par des scripts, la priorité devient d’isoler et d’analyser sans aggravation. Dans ce cas, la restauration à partir d’une sauvegarde propre est souvent le plus rapide, mais seulement si vous êtes sûr que la sauvegarde n’inclut pas l’infection.
Un détail pratique: les sauvegardes automatiques peuvent contenir l’état infecté. Si la sauvegarde a été prise après l’infection, la restauration réinjecte le problème. C’est pour ça que les dates de sauvegarde et l’historique de modification sont si importants.
Documenter l’incident pour éviter que ça recommence “sans qu’on le sache”
Après un incident, le travail utile, c’est aussi de garder une trace. Pas une archive pour faire joli, une documentation pour accélérer la prochaine fois.
Vous voulez répondre à des questions comme: quelle zone a été modifiée, quel compte a été impliqué (si vous l’avez identifié), quel plugin ou thème était suspect, et quelle faille ou quelle faiblesse a permis l’accès. Même des réponses partielles valent mieux que rien.
Quand on documente, on réduit le temps de réaction. Et surtout, on évite les reprises “au feeling” qui finissent en nouvelle infection.
Récidive: comment savoir si vos actions ont vraiment tenu
Le point le plus frustrant, c’est de nettoyer, de croire que c’est terminé, et de découvrir une réinfection plus tard.
Pour éviter ça, je recommande une période de vérification après restauration ou nettoyage. Le site doit rester sous surveillance rapprochée, pas uniquement pendant un jour.
Surveiller le comportement via des tests simples aide beaucoup: pages clés, formulaires, liens sortants, et surtout tout ce qui peut rediriger automatiquement. En parallèle, contrôler les fichiers et l’activité des comptes.
Le signe le plus rassurant, c’est la stabilité. Si, après une période de vérification, rien ne revient, et que les horodatages de modifications restent cohérents avec vos propres mises à jour, vous êtes sur la bonne voie.
Ajuster le plan à votre réalité
Un plan de prévention n’a pas besoin d’être complexe, il doit être tenu. Si vous n’avez qu’une petite équipe, vous ne pouvez pas engager une surveillance permanente à https://gardewp.fr/ la minute. Alors vous privilégiez des contrôles réguliers, des mises à jour maîtrisées, et des accès bien verrouillés.
Si vous avez une agence ou une équipe technique, vous pouvez formaliser encore plus: pipelines de déploiement, environnements de test pour mettre à jour, contrôles automatisés des fichiers sensibles, et gestion stricte des autorisations.
Dans tous les cas, l’objectif reste le même: éliminer les causes, pas seulement les effets. En pratique, c’est ce qui transforme une opération d’urgence en stratégie de durabilité.
Si vous me donnez votre configuration (hébergeur, nombre de plugins, fréquence de mise à jour, et si vous aviez ou non accès à l’admin pendant l’incident), je peux vous proposer un plan de prévention plus adapté, avec des priorités réalistes et un rythme de contrôle qui tient dans votre organisation.