Quand un site WordPress bascule du “ça va” au “ça ne répond plus correctement”, la cause la plus fréquente n’est pas toujours une infection au sens classique. Il peut s’agir d’un plugin mal maintenu, d’un thème compromis, d’un script injecté via un formulaire, ou de comptes administrateurs ajoutés sans votre accord. Et pourtant, dans la majorité des cas qui finissent par exiger un nettoyage, on retrouve un fil conducteur: quelque chose a modifié le site sans passer par votre processus normal de déploiement.
J’écris cette méthode comme je la pratique sur le terrain, en gardant deux objectifs simultanés: arrêter le mal sans aggraver la situation, puis restaurer proprement sans supposer à tort que “réinstaller WordPress” suffit. Réparer un site infecté, c’est autant une affaire de rigueur que de calme, parce que chaque action peut impacter les traces, les sauvegardes et la capacité à prouver ce qui s’est passé.
Les signaux qui doivent vous faire lever la tête
Un “virus” sur WordPress peut se manifester de façons très différentes, et certaines sont trompeuses. Parfois, vous voyez immédiatement un comportement anormal, et parfois vous ne le remarquez qu’après coup, via des baisses de trafic ou des alertes dans la Search Console.
Voici les indices qui reviennent le plus souvent quand on examine des cas réels:
- pages qui affichent du contenu qui n’a rien à voir avec votre charte (liens, iframes, redirections), formulaires qui deviennent des portes d’entrée (commentaires, champs de login, prise de rendez-vous), augmentation brutale de l’usage CPU ou mémoire côté serveur, accès suspects dans les journaux (créations d’utilisateurs, requêtes vers des fichiers inhabituels), plugins ou thèmes qui se mettent à jour “toute seuls”, des nouveaux fichiers dans des dossiers que vous n’utilisez pas.
J’ai déjà vu des sites qui semblaient fonctionner, mais qui redirigeaient une petite partie des visiteurs, parfois uniquement sur certains navigateurs ou sur une plage d’IP. Dans ces cas-là, l’infection n’est pas toujours visible dans l’interface, elle se repère dans les logs et dans les fichiers. À l’inverse, il arrive aussi que le “symptôme” soit causé par une mauvaise configuration ou un plugin défaillant. Le piège, c’est d’attaquer le serveur au hasard.
Avant d’agir: sécuriser les accès et figer l’état
La tentation, c’est de “tout supprimer” ou de “réinstaller”, surtout quand on pense que le site est irréparable. Sur un site possiblement compromis, c’est rarement la meilleure première décision. La priorité est de comprendre ce qui s’est passé, tout en empêchant l’adversaire de continuer.
Concrètement, vous voulez préserver ce qui peut être utile: les journaux (si vous avez accès), les fichiers qui ont été modifiés, et la configuration actuelle. Si vous changez tout en premier, vous perdez les repères.
Je conseille de commencer par deux actions simples, sans attendre:
1) mettez le site en mode maintenance ou au moins restreignez l’accès si c’est possible,
2) prenez immédiatement une sauvegarde complète des fichiers et de la base de données, idéalement en conservant aussi vos logs applicatifs si votre hébergement le permet.Même si vous pensez que la sauvegarde “de votre hébergeur” date de la veille, elle peut ne pas refléter l’état courant. Sur certains incidents, on observe des injections qui apparaissent et disparaissent en quelques heures.
Préparer une “chaîne de preuves” minimaliste
Une analyse sérieuse ne nécessite pas un laboratoire, mais elle demande une discipline d’exécution. Sur WordPress, les compromissions se traduisent souvent par des modifications dans:
- le répertoire wp-content (thèmes, plugins, uploads), la racine (fichiers inhabituels, scripts ajoutés), la base de données (options, utilisateurs, posts avec du contenu injecté), parfois des réglages dans wp-config.php.
Dès que vous suspectez une infection, documentez ce que vous observez. Une capture des timestamps, la liste des fichiers modifiés récents, et le contenu de certains “fichiers inconnus” peuvent sauver des heures plus tard. Cette rigueur évite aussi un problème fréquent: refaire le même nettoyage deux fois parce qu’on n’a pas identifié le point d’entrée.
Étape 1: vérifier sans hypothèse trop rapide
La première inspection vise à répondre à une question très simple: qu’est-ce qui a vraiment été modifié, et où?
Contrôler les utilisateurs et rôles
Une infection WordPress laisse souvent des traces dans les comptes. Regardez s’il existe des utilisateurs que vous ne reconnaissez pas, ou des rôles inattendus. Le symptôme ne se limite pas aux “admins”: parfois un auteur ou un contributeur a été ajouté et sert à injecter du contenu ou à planifier des publications.
À ce stade, ne supprimez pas trop vite. Si vous retirez immédiatement des comptes, vous pouvez perdre des éléments utiles pour comprendre la logique d’injection.
Examiner les plugins et thèmes
Sur beaucoup de sites compromis, le vecteur principal est un plugin obsolète ou un thème modifié. Cherchez les choses qui sortent du cadre:
- plugin installé récemment puis désactivé, plugin “à l’apparence normale” mais avec des fichiers bizarres, thème modifié ou compressé en archive puis rechargé.
Si vous avez un historique clair de vos mises à jour, comparez-le aux timestamps actuels. Si un changement date de deux semaines alors que vous n’avez rien déployé, c’est un signal.
Étape 2: repérer la présence d’un code injecté
Le nettoyage exige de trouver le code. Sans ça, on travaille à l’aveugle.
Fichiers inhabituels dans la racine et wp-content
Quand on parle de “virus”, on imagine souvent un exécutable. Sur WordPress, l’infection est très souvent du PHP injecté dans des fichiers inattendus. Les emplacements varient, mais on retrouve fréquemment des scripts dans des zones où ils n’ont aucune raison d’exister.
Votre objectif consiste à repérer:
- des fichiers récemment créés, des fichiers avec un nom “camouflé”, du code qui exécute des requêtes externes, lit des fichiers système, ou obfusque des chaînes.
Ne cherchez pas uniquement des mots comme “eval” ou “base64”. Il existe des payloads qui n’utilisent pas ces signatures de manière évidente. Le critère le plus robuste, dans les incidents réels, c’est “ce fichier devrait-il exister, et correspond-il au comportement de WordPress standard?”.
Contenu injecté dans la base
Un autre scénario très fréquent: la base contient des injections dans des options, des métadonnées ou des articles. Parfois, il s’agit de contenu visible, parfois d’un mécanisme qui déclenche une redirection ou un affichage de script côté front.
À l’échelle WordPress, la base est vaste. L’approche la plus efficace, c’est de cibler l’anormal: des valeurs modifiées récemment, des options qui pointent vers des URL externes suspectes, des pages ou publications créées sans votre intervention.
Outils: comment je les utilise, sans devenir dépendant
Il existe plusieurs plugins de sécurité et des scanners de fichiers, mais je ne recommande pas de vous reposer uniquement sur un score. Un scanner peut:
- rater des variantes (faux négatifs), alerter sur des faux positifs (fichiers générés, caches), proposer des corrections qui cassent le site si elles sont appliquées trop vite.
Dans ma pratique, j’utilise les scanners comme une boussole, pas comme un GPS. Ils m’aident à localiser rapidement des zones à vérifier, puis je confirme en lisant le code.
Si votre hébergement propose des outils de sécurité côté serveur, vous pouvez les exploiter pour repérer les patterns de trafic. Le bon réflexe consiste à recouper: ce que le scanner soupçonne doit correspondre à ce que vous trouvez dans les fichiers ou les requêtes.
Étape 3: isoler le vecteur d’entrée avant le nettoyage
Nettoyer sans corriger le point d’entrée, c’est accepter que ça revienne. Dans les incidents WordPress, le point d’entrée peut être:
- un identifiant compromis (mots de passe réutilisés, fuite, brute force), une vulnérabilité sur un plugin ou un thème, une faille de configuration (droits trop larges, exposer des fichiers), une attaque via une fonctionnalité exposée (upload de fichiers, thème, import).
Même si vous ne savez pas encore exactement, vous pouvez réduire fortement les risques en durcissant les accès: révoquez les sessions si votre hébergeur le permet, changez les mots de passe avec des règles strictes, et vérifiez l’absence d’autorisations inattendues.
J’ai déjà vu des équipes qui nettoient le code, puis qui changent les mots de passe, et qui se font re-infecter le lendemain. Le problème venait d’un plugin non corrigé, et donc l’infection se reproduisait après coup, même avec des identifiants “propres”.
Étape 4: choisir la méthode de nettoyage (et accepter les compromis)
Il y a deux méthodes principales. La première consiste à nettoyer au cas par cas, en supprimant les fichiers malveillants et en purgeant la base. La seconde consiste à restaurer les éléments à partir d’une version saine, puis à réinjecter votre contenu.
Le bon choix dépend de l’ampleur et du temps disponible.
- Si l’infection est localisée et que vous identifiez clairement les fichiers injectés, un nettoyage ciblé peut être plus rapide. Si vous voyez trop de zones modifiées, si vous constatez des fichiers inconnus dans plusieurs dossiers, ou si les logs montrent des comportements erratiques, la restauration à partir de zéro devient plus fiable.
Ce compromis est souvent celui qui sépare “un nettoyage propre” de “un bricolage qui tient deux semaines”.
Checkpoint pratique avant modification: plan de rollback
Avant d’éditer des fichiers ou de toucher à la base, posez un plan de rollback. Vous ne voulez pas d’un site “en cours de chirurgie” sans solution de retour.
Voici mon mini-checklist, très simple, mais qui évite des catastrophes:
- sauvegarde complète des fichiers et de la base, datée et vérifiée (taille et cohérence), liste des plugins et thèmes installés, avec version et état actuel, accès admin fonctionnel confirmé (et notez le chemin d’accès exact), mode maintenance activé ou accès restreint, note des timestamps de modification suspects pour recouper après coup.
Une fois cette base posée, vous pouvez agir sans perdre totalement le contrôle.
Étape 5: nettoyage ciblé des fichiers et réinstallation propre
Si vous avez identifié des fichiers malveillants, la suppression est une première étape. Mais dans beaucoup de cas, il faut aussi:
- supprimer les traces dans la base, vérifier que les fichiers “de départ” n’ont pas été réintroduits, remplacer les fichiers WordPress core et ceux des thèmes ou plugins modifiés.
Sur WordPress, je recommande souvent de restaurer les éléments suivants à partir de sources propres:
- WordPress core (fichiers système), thèmes et plugins que vous n’êtes pas capable de vérifier, fichiers de configuration modifiés, certains fichiers dans wp-content si vous constatez des modifications non légitimes.
Même si vous ne supprimez que le fichier suspect, il existe des infections “persistantes” qui re-génèrent du code. La réinstallation des composants essentiels coupe cette persistance.
Étape 6: nettoyer la base sans casser le site
La base de données est l’endroit où les infections deviennent insidieuses. Pour éviter une rupture, je travaille en ciblant.
J’examine en priorité:
- utilisateurs et rôles (créations, emails inattendus), entrées créées récemment dans les contenus, options qui stockent des scripts, des chemins ou des URL externes, transients et caches persistants si vous les identifiez liés à l’injection.
Selon la plateforme d’hébergement, vous pouvez utiliser phpMyAdmin ou des outils plus avancés. Quoi qu’il arrive, prenez un soin particulier à ne pas supprimer site dangereux malware WordPress “tout ce qui est récent” au hasard, car WordPress stocke des données système à différents endroits, y compris des caches.
Le point délicat, c’est qu’une infection peut être déguisée en contenu “normal”, avec un texte qui ressemble à un spam SEO ou à une page de renvoi. Là, vous devez comparer avec votre comportement habituel: rythme de publication, style rédactionnel, et cohérence des catégories.
Étape 7: vérifier les injections via le front, pas seulement via l’arrière-boutique
Une infection peut être active côté rendu public, mais invisible dans l’admin une fois “nettoyée partiellement”. Je fais donc une vérification front.
Quelques tests utiles, sans devenir parano:
- ouvrir le site sur navigation privée, tester plusieurs pages, notamment celles qui reçoivent du trafic SEO, vérifier si une redirection se produit selon l’agent navigateur, vérifier les scripts ajoutés dans le HTML et leur origine.
Si vous utilisez un outil de console navigateur, regardez le code source rendu. Vous cherchez du script externe, des iframes non attendus, ou des éléments insérés dans des zones du thème.
À plusieurs reprises, j’ai vu un nettoyage “réussi” côté fichiers, puis un nouvel affichage malveillant via un champ de thème (par exemple dans functions ou un template), ou via un contenu injecté dans une page.
Étape 8: durcir WordPress pour éviter la rechute
Le nettoyage est la phase visible, mais la durabilité vient du durcissement. Vous devez supposer que le point d’entrée existe encore, tant que vous n’avez pas prouvé le contraire.
Voici les mesures qui comptent vraiment, parce qu’elles réduisent les scénarios de compromission:
- mots de passe solides pour tous les comptes, y compris ceux qui n’ont que des rôles éditoriaux, suppression des comptes inutiles (si un “ancien développeur” a encore un accès, c’est une surface), mise à jour des plugins et du thème, ou suppression des plugins non utilisés, analyse des utilisateurs “créés récemment” et revue des rôles, limitation des tentatives de connexion, si votre hébergement ou un module de sécurité le permet, contrôle des droits de fichiers, éviter d’avoir des permissions trop ouvertes.
Je sais que ça peut sembler “standard”. Mais en incident réel, la négligence répétée sur un seul point peut suffire à déclencher une rechute.
Mode pratique, quand vous manquez de temps
Parfois l’urgence business impose d’agir vite: le site est pénalisé, les prospects n’arrivent plus, ou des navigateurs affichent des alertes de sécurité. Dans ce cas, je fais une version “accélérée” de la démarche, tout en gardant des garde-fous.
L’approche consiste à restaurer au plus vite un site stable à partir d’une sauvegarde antérieure raisonnable, puis à procéder à l’analyse pour comprendre la cause. Cela réduit l’exposition, même si vous perdez un peu de contenu récent.
Le critère, c’est la confiance dans la sauvegarde. Si elle date de trop longtemps, vous risquez de réimporter la compromission. Si vous avez plusieurs sauvegardes, testez celle qui précède la première détection, même si cela implique un petit décalage.
Comment savoir si le nettoyage est terminé?
Un site peut “avoir l’air normal” alors qu’il reste une partie de l’infection. Je considère qu’un incident est clôturé seulement quand plusieurs conditions sont réunies:
- plus de nouveaux fichiers ou scripts inconnus après une période de contrôle, plus de création de comptes non autorisés, pas de redirection ou d’injection visible sur le front, logs de serveur moins suspects, pas d’explosion d’erreurs ou de requêtes répétitives, cohérence entre ce que vous voyez dans la base et ce que votre site devrait contenir.
Je fais généralement une surveillance courte, mais réelle, souvent sur 24 à 72 heures, selon la fréquence de mise à jour de votre trafic. Sur certains sites, les injections ne se déclenchent qu’après des conditions précises (heure, langue, géolocalisation). Sans période de vérification, on ferme trop tôt.
Les erreurs classiques qui font perdre du temps
J’en vois régulièrement, et elles sont rarement “malveillantes”. Ce sont des raccourcis compréhensibles, mais coûteux.
La première erreur consiste à supprimer des dossiers sans vérifier s’ils ont été régénérés via un mécanisme persistant. La deuxième erreur: changer uniquement les mots de passe sans corriger la vulnérabilité qui a permis l’accès. La troisième: restaurer WordPress core, puis conserver un thème compromis, ou conserver un plugin que vous n’avez pas réellement inspecté.
Enfin, il y a la confusion entre “site lent” et “site infecté”. Un plugin lourd, un cache absent, ou une base gonflée peuvent expliquer une partie des symptômes. Dans l’urgence, on sur-traite parfois, et on finit par casser un site déjà fragile.
Étapes finales: recette de contrôle après remise en ligne
Après le nettoyage, je ne remets pas le site en production comme on redémarre un ordinateur. Je fais une séquence de contrôle qui limite les mauvaises surprises.
Pour garder cette phase claire, voici une courte séquence, volontairement limitée:
Relancer en mode maintenance seulement le temps des tests, puis ouvrir progressivement, Valider les pages clés, formulaires et pages d’administration (login compris), Vérifier le code source rendu des pages les plus visitées, Surveiller pendant 24 à 72 heures les créations d’utilisateurs et anomalies serveur, Mettre à jour et supprimer ce qui n’est pas nécessaire, puis activer des durcissements (selon votre stack).Si vous avez un outil de monitoring ou de sécurité, laissez-le actif. La qualité d’un nettoyage se voit souvent après coup.
Cas concrets: trois scénarios typiques et comment je réagis
Sans inventer de détails précis d’un “cas unique”, je peux décrire les situations qui reviennent souvent.
1) Redirections discrètes
Le site semble normal, mais une partie des visiteurs tombe sur une page externe. Dans ce scénario, le front est la priorité: inspection du HTML rendu, recherche de scripts injectés, et contrôle des fichiers modifiés dans le thème ou un plugin. Une fois trouvé, je remplace les composants à risque et je purge la base des configurations qui déclenchent la redirection.
2) Création d’administrateurs “fantômes”
Vous trouvez un compte admin que vous ne reconnaissez pas. Là, je coupe l’accès en supprimant les comptes non attendus, puis je cherche le point d’entrée: plugin vulnérable, formulaire d’upload, ou faiblesse de mot de passe. Le nettoyage est presque toujours incomplet sans durcissement.
3) Site qui devient instable après un “nettoyage” rapide
Un site est réinstallé, mais il continue de bugger. Dans ce cas, j’examine les caches, la base et les modifications persistantes. Il arrive que le nettoyage ciblé ait supprimé un morceau nécessaire, ou que l’infection ait modifié une logique du thème. La solution consiste à revenir à une restauration fiable puis à appliquer un nettoyage plus méthodique.
Si vous ne pouvez pas faire le nettoyage vous-même
Il arrive que l’urgence, le manque d’accès, ou la complexité technique rendent la démarche trop risquée en interne. Dans ce cas, il faut être capable de piloter un prestataire, pas seulement de “donner le site”.
Vous pouvez demander un plan d’action qui couvre au minimum: sauvegardes vérifiées, périmètre investigué (fichiers et base), méthode de restauration ou nettoyage ciblé, preuve du point d’entrée corrigé, et surveillance après remise en ligne. Un prestataire sérieux peut aussi expliquer les choix techniques sans promettre une garantie absolue.
Ce que je retiens après chaque incident
Chaque nettoyage est différent, mais les mêmes principes reviennent. Le premier, c’est la prudence: sauvegarder, isoler, observer avant de supprimer. Le second, c’est la cohérence: ce que vous supprimez doit correspondre à ce que vous voyez, côté fichiers, côté base et côté front. Le troisième, c’est la durabilité: corriger le point d’entrée et réduire la surface d’attaque, sinon la rechute finit toujours par arriver.
Un site WordPress n’est pas “plus fragile” par nature, il devient fragile quand le maintien se relâche, que des plugins restent obsolètes ou que des mots de passe ne sont pas maîtrisés. La plupart des infections sont moins un mystère qu’un signal, parfois tardif, parfois évident.
Si vous venez juste de détecter un problème, démarrez par la sauvegarde et l’arrêt de l’activité suspecte. Ensuite, investiguez sérieusement. Le nettoyage virus WordPress n’est pas un acte unique, c’est une séquence qui se valide à chaque étape, avec des preuves concrètes.
