Quand un site WordPress se fait compromettre, la première erreur est souvent de se concentrer uniquement sur “l’urgence visible”. On supprime un script dans un fichier, on désactive un plugin, puis on rétablit la page d’accueil. Deux jours plus tard, une URL étrange réapparaît, ou le même visiteur “reçoit” un https://gardewp.fr/nettoyage-malware-wordpress/ redoutable message d’erreur. Le problème, dans la majorité des cas que j’ai vus sur le terrain, n’était pas seulement le code malveillant, c’était l’accès qui permettait à l’attaque de revenir.
La désinfection WordPress devient alors un chantier plus large: comprendre comment le pirate est entré, nettoyer ce qui a été modifié, puis verrouiller les accès restants, en particulier FTP et la partie admin. Même quand on pense être “au calme”, une mauvaise configuration peut garder une porte entrouverte. Et WordPress, parce qu’il est très flexible, offre malheureusement plusieurs chemins pratiques à exploiter.
Les signes qui doivent orienter votre enquête
Avant de toucher à quoi que ce soit, je conseille de prendre quelques minutes pour observer. Pas pour “fignoler”, mais pour éviter de nettoyer au hasard.
Un site compromis montre souvent des symptômes récurrents: redirections vers des pages non liées, apparition de fichiers PHP dans des dossiers inattendus, comptes admin créés en douce, ou encore des modifications sur des fichiers noyau. Parfois, tout semble normal côté interface, mais le trafic et les erreurs serveur racontent autre chose. En pratique, j’ai déjà vu des sites où l’URL d’un plugin “inactif” déclenchait quand même du code, parce que quelqu’un l’avait transformé ou parce qu’un fichier chargé automatiquement avait été injecté.
Ce qui compte, c’est de relier les symptômes à une hypothèse d’accès. Si vous constatez des modifications de fichiers en dehors de vos déploiements habituels, il y a de fortes chances que l’attaquant ait eu la main sur le système de fichiers, donc via FTP, via une faille d’identification, via un outil de gestion exposé, ou via une autre mécanique d’escalade.
Comprendre l’attaque: la porte d’entrée et le “mécanisme de retour”
Dans les incidents WordPress, on pense souvent à une seule cause, par exemple un mot de passe trop faible. En réalité, il y a souvent une chaîne. Prenons un scénario fréquent: un compte admin a été pris, le pirate a modifié des réglages, puis il a modifié aussi des fichiers pour survivre. Même si vous changez le mot de passe du compte, la porte peut rester ouverte via FTP ou via un identifiant de service.
Le “retour” de l’attaque se produit quand l’attaquant conserve un accès persistant. Cela peut être un compte admin supplémentaire, un plugin ou un thème “inoculé”, un script caché, ou un simple identifiant FTP resté valable. FTP est un bon exemple parce que c’est à la fois banal et dangereux. Dès qu’un identifiant FTP est réutilisé, mal stocké, ou accessible via une mauvaise configuration (par exemple sans limitation d’IP, ou avec trop de droits), il suffit d’une fuite de mot de passe pour relancer le même scénario.
En désinfection WordPress, l’objectif n’est donc pas seulement de supprimer ce que vous voyez. C’est d’empêcher toute re-création automatique de la compromission.
Phase de désinfection: agir sans abîmer votre site
La désinfection WordPress doit être méthodique, sinon vous finissez par effacer des éléments utiles ou, pire, par “réparer” un symptôme au lieu de la cause.
Mon approche consiste à séparer le nettoyage en trois couches, sans tout casser d’un coup.
D’abord, sécuriser l’accès pour stopper le flux. Si vous avez la certitude qu’un compte FTP ou un compte admin est compromis, il faut couper l’accès de manière contrôlée, par exemple en désactivant le compte concerné, en changeant les identifiants, ou en mettant temporairement le site en maintenance. Ensuite seulement, vous passez au nettoyage logiciel.
Ensuite, vous nettoyez le contenu injecté. Si vous avez des logs d’erreurs ou de modifications, ils deviennent précieux. Vous cherchez les fichiers ajoutés, ceux qui ont des dates de modification inhabituelles, les fichiers PHP nouvellement présents, et les modifications sur des hooks WordPress. Une règle pratique: si un fichier ne devait pas être là, ou si son code est incohérent avec ce que vous installez habituellement, il sort du système.
Enfin, vous vérifiez l’intégrité des éléments. Pour WordPress, ça veut dire vérifier les dossiers de thèmes et de plugins, mais aussi surveiller les fichiers “à risque” souvent ciblés, comme ceux liés à la configuration et aux points d’exécution. Selon votre hébergeur, la restauration peut être plus rapide via une sauvegarde saine que via un nettoyage manuel complet, mais seulement si vous êtes certain que la sauvegarde ne contient pas déjà la persistance.
Un détail qui m’a déjà coûté du temps: parfois, la persistance se trouve dans une mise à jour de plugin “légitime”. Le pirate a remplacé le code dans le dossier du plugin. Si vous regardez uniquement les fichiers mal nommés, vous manquez la modification.
Le piège de la restauration: sauvegarde saine ne veut pas dire “source propre”
Beaucoup d’administrateurs ont le réflexe de restaurer une sauvegarde, puis de “changer le mot de passe”. C’est une bonne stratégie si la sauvegarde est antérieure à l’intrusion et si l’intrusion n’a pas laissé de trace dans des paramètres persistants qui auraient aussi été enregistrés avant la sauvegarde.
Il faut donc distinguer deux choses: les fichiers restaurés et la base de données. Une compromission peut toucher le système de fichiers, la base, ou les deux. La désinfection WordPress devient alors un débat: restaurez-vous tout, ou seulement une partie? Si vous restaurez uniquement la base mais pas les fichiers, vous gardez peut-être la porte FTP. Si vous restaurez les fichiers mais pas la base, vous pouvez conserver un compte admin ajouté à la volée ou une option WordPress modifiée.
À l’inverse, restaurer “tout” peut masquer le problème si vous restaurez une sauvegarde déjà contaminée. Je préfère, quand c’est possible, croiser les dates. Comparez quand le site a commencé à “agir” avec la date de vos sauvegardes. Si votre fenêtre d’infection est serrée, il faut chercher la trace avant de restaurer.
Sécuriser FTP: couper la persistance dès la première heure
Le FTP est souvent le point faible, pas forcément parce qu’il est mauvais en soi, mais parce qu’il est traité comme une simple commodité. En incident, c’est un levier immédiat. Si l’attaquant peut encore se connecter au serveur, il peut re-déposer les mêmes fichiers, ou déposer de nouveaux scripts.
Première décision: la priorité est de réduire l’exposition. Selon votre hébergeur, il faut regarder la gestion des comptes FTP, les droits attribués, et les options de connexion. Si vous avez plusieurs utilisateurs, commencez par ceux qui n’ont pas de raison d’exister. Les anciens comptes créés pour un développeur freelance, les comptes “tech” laissés après un départ, ou les identifiants partagés, c’est très souvent là que ça coince.
Ensuite, traitez le mot de passe comme un élément d’incident. Même si vous pensez qu’il n’a jamais été exposé, l’hypothèse la plus pragmatique en désinfection WordPress est de considérer l’identifiant comme compromis jusqu’à preuve du contraire.
Enfin, vérifiez les droits. Un compte FTP “trop large” peut faire plus de dégâts. Un pirate n’a pas besoin de tout; il a besoin de ce qui permet d’écrire dans les emplacements exécutables ou dans les fichiers de configuration.
Check rapide de durcissement FTP (avant de relancer)
Voici la partie la plus utile quand on veut réduire le risque immédiatement, sans s’enfermer dans un plan trop théorique.
- Changez tous les mots de passe FTP et supprimez les comptes inutilisés Réduisez les droits FTP au strict nécessaire pour le contenu à gérer Limitez la connexion aux IP autorisées si votre hébergeur propose l’option Désactivez l’accès FTP non requis pendant la désinfection, puis réactivez seulement ce qui sert Si possible, privilégiez une alternative sécurisée (par exemple SFTP) à FTP “classique”
Je sais que certains hébergeurs ne donnent pas autant d’options, mais dans ce cas, l’idée reste la même: réduire l’emprise et le nombre d’identifiants valables.
L’accès admin: ce que vous devez vérifier au-delà du mot de passe
WordPress a un avantage: si l’attaquant entre par un compte, il laisse souvent des traces dans les utilisateurs, les actions planifiées, et parfois des modifications de rôles. Le piège est de penser que changer le mot de passe règle le problème. Souvent, c’est nécessaire, mais rarement suffisant.
Après une désinfection WordPress, je vérifie systématiquement les utilisateurs. Il faut rechercher les comptes nouveaux, les comptes avec des rôles inhabituels, et les adresses qui ne correspondent pas à votre équipe. Les attaques persistent parfois via une création de compte admin, même si le code injecté a été retiré. Donc, même si les pages redeviennent normales, l’accès pourrait être encore là.
Ensuite, je regarde la sécurité de connexion. Des plugins “anti-brute force” aident, mais ils ne sont pas une preuve en soi. Ce que je préfère, c’est vérifier les réglages et l’environnement. Y a-t-il un profil public, des formulaires qui exposent des erreurs trop détaillées, des pages login accessibles depuis des plages d’IP non maîtrisées? Même avec une bonne politique de mots de passe, un site WordPress exposé à un bombardement de tentatives finit par donner à l’attaquant une opportunité, surtout si vous réutilisez des mots de passe ou si vos comptes sont trop “humains”.
Troisième point, souvent négligé: les sessions et les jetons. Si vous avez changé les mots de passe, mais que vous n’avez pas “déconnecté” les sessions, un accès déjà établi peut perdurer pendant un certain temps. Sur WordPress, selon vos outils, on peut forcer la déconnexion, invalider des sessions, ou repasser par des mécanismes de sécurité. L’approche varie, mais l’idée ne change pas: un incident doit être suivi par une invalidation des moyens d’accès existants.
Protéger les points d’entrée WordPress que les pirates ciblent
Les attaques WordPress ont des habitudes. Elles exploitent ce qui est exposé, ce qui est mal configuré, ou ce qui est simplement maintenu trop longtemps sans mise à jour.
Sans faire un inventaire de toutes les vulnérabilités possibles, je peux vous dire ce qui revient dans les cas sérieux que j’ai traités:
- plugins obsolètes ou non maintenus thèmes personnalisés qui ne sont pas gérés comme du code de production configuration de l’hébergement qui laisse trop d’accès aux fichiers mots de passe réutilisés, parfois même au sein de l’équipe erreurs de permission sur des dossiers, par exemple des autorisations trop ouvertes
Dans une désinfection WordPress, la difficulté est de ne pas casser votre site. Couper un plugin peut interrompre une fonctionnalité légitime. Mettre “en pause” un thème peut dégrader l’expérience. Il faut donc faire un tri.
Le tri le plus fiable est souvent contextuel. Si vous avez une liste de plugins installés et une description de leur usage, vous pouvez prioriser ceux qui ne servent plus, ceux qui sont plus “risqués” dans leur nature (plugins très proches d’exécution de code, gestion d’accès avancée, intégration de scripts), et ceux dont la mise à jour est en attente. Remplacer par une alternative maintenue est plus sain que de conserver un plugin que vous “supportez” sans le mettre à jour.
Une stratégie concrète de relance, sans laisser de trou
Une fois le nettoyage fait et les accès fermés, il reste une étape que je vois trop souvent expédiée: valider le système dans des conditions proches du réel.
Relancer, ce n’est pas seulement remettre la page d’accueil. C’est vérifier que:
- les fichiers et dossiers critiques sont cohérents les comptes admin sont propres les plugins actifs correspondent à vos besoins les redirections et injections ne reviennent pas les logs ne continuent pas à montrer des comportements anormaux
Le plus efficace est de surveiller dans les heures qui suivent la relance. Une compromission “réinjectable” montre souvent sa persistance rapidement, en particulier si l’attaquant a une habitude de re-déploiement via un accès encore valide, FTP ou autre.
Si votre hébergeur fournit des métriques et des logs, regardez aussi les pics de requêtes vers des endpoints suspects. Même sans voir de code malveillant, vous pouvez repérer des schémas. Dans certains cas, je commence par limiter temporairement l’exposition, puis j’élargis quand tout reste stable.
Points à surveiller pendant 24 à 48 heures
- Apparition de nouveaux fichiers dans wp-content et dans les dossiers de thèmes et plugins Création ou modification d’utilisateurs, y compris rôles et comptes “inconnus” Tentatives de connexion échouées ou répétées (login admin, accès sensibles) Changements d’options WordPress liés aux redirections, à la configuration, ou à l’exécution de code Comportements de navigation anormaux côté visiteurs, par exemple redirections récurrentes
Cette surveillance n’est pas une formalité. C’est un filet de sécurité, parce que votre désinfection WordPress initiale peut être correcte, mais qu’un accès oublié peut provoquer une reprise.
Cas particuliers: quand FTP semble “innocent”
Il arrive que vous changiez FTP, que vous supprimiez des comptes, et que malgré cela le site continue à être instable. Dans ce cas, le FTP n’était pas le seul chemin, ou bien il existait un autre moyen d’écriture.
Quelques scénarios qui expliquent ces situations:
- un script a modifié la base et la base continue à injecter du code au prochain affichage un plugin compromis reste actif et régénère du contenu injecté un compte admin compromis re-crée des fichiers dès qu’il revoit une tentative d’accès un identifiant d’un outil de déploiement (par exemple des clés SSH, des automatisations, ou un outil d’upload) a été exposé
Quand vous suspectez le scénario “base de données”, il faut alors regarder les options, les entrées liées à des actions planifiées, et tout ce qui peut déclencher du code. WordPress a des hooks, des cron, et des options sérialisées. Une désinfection qui ne nettoie que les fichiers est parfois insuffisante.
Dans la pratique, je traite ces cas avec prudence: je ne supprime pas tout ce qui ressemble à de la donnée, je compare avec une version saine ou avec un historique si vous l’avez. Sans quoi, vous risquez de casser un paramétrage légitime.
Les droits et la séparation des tâches: la sécurité qui évite le second incident
Le meilleur “cure” après désinfection, c’est d’éviter de refaire les mêmes erreurs.
La séparation des tâches fonctionne très bien dans les petites structures. Un compte FTP pour déposer des fichiers ne doit pas avoir le pouvoir d’agir comme un admin WordPress. Un développeur qui met à jour un thème ne devrait pas utiliser le même identifiant que l’administrateur qui modifie la stratégie de sécurité. Les habitudes humaines sont compréhensibles, mais elles sont coûteuses en cas d’attaque.
Même chose pour les droits sur les fichiers. Sur certains environnements, on peut trop faciliter l’écriture. Si les permissions permettent l’écriture dans des zones exécutables sans contrôle, un pirate n’a besoin que d’un seul point faible pour faire des ravages.
Je sais que sur certains hébergements mutualisés, on ne peut pas tout ajuster finement. Là encore, l’objectif n’est pas la perfection, c’est la réduction du risque. Limiter le nombre de comptes, limiter les droits, limiter les connexions, et supprimer ce qui n’est plus utilisé, ça fait une vraie différence.
Règles simples pour renforcer l’ensemble dès maintenant
Après un incident, on a parfois envie de “tout refaire” d’un coup. En réalité, une série de décisions simples apporte une amélioration durable.
Voici les principes que j’utilise, parce qu’ils sont applicables même quand le temps est compté:
- Mettre à jour WordPress, thèmes et plugins régulièrement, sans laisser des “mises à jour en attente” s’accumuler. Utiliser des mots de passe uniques, longs, et différents entre FTP et admin WordPress. Ne réutilisez jamais les mêmes secrets. Activer des mécanismes de protection contre les tentatives de connexion et surveiller les logs. Supprimer les identifiants et comptes qui n’ont plus de raison d’exister. Vérifier le niveau de permission des accès, et réduire ce qui n’est pas indispensable.
Une anecdote courte: sur un site d’une petite agence, le problème n’a pas été une vulnérabilité “spectaculaire”. Le coupable était un compte FTP attribué il y a des mois, avec un mot de passe réutilisé. Le nettoyage avait été fait, mais l’accès FTP dormait encore. Après relance, tout a recommencé, parce que le pirate pouvait republier la même injection. C’est le genre de situation qui donne l’impression d’avoir “réussi” puis de rechuter immédiatement, et ça vient presque toujours d’un accès non maîtrisé.
Checklist de remise en état: ce que je considère comme “terminé”
Je préfère finir une désinfection WordPress avec une validation explicite, sinon l’équipe se repose sur le ressenti. Le ressenti trompe rarement, mais il ne garantit pas.
Voici une dernière liste utile, très pragmatique, qui marque vraiment la fin des actions urgentes:
- Tous les comptes admin WordPress ont été vérifiés, aucun compte inconnu ne reste Les mots de passe admin et FTP ont été changés, les sessions à risque ont été invalidées si possible Les identifiants FTP inutiles ont été supprimés, les droits ont été réduits Les plugins et thèmes actifs ont été contrôlés, les éléments suspects ont été remplacés ou désactivés Une surveillance de 24 à 48 heures confirme qu’aucune réinfection ne se produit
Une fois ces points acquis, je recommande ensuite de passer à la phase prévention plus structurée, avec un calendrier de mises à jour et une discipline d’accès. Mais c’est une autre étape. D’abord, il faut être certain que le site n’est plus “réinjectable”.
Et si vous n’êtes pas sûr de l’étendue de la compromission ?
Parfois, on fait tout “bien”, mais on n’arrive pas à déterminer exactement ce qui a été modifié. Cela arrive surtout quand il n’y a pas de logs exploitables, pas de sauvegardes datées, ou des traces trop partielles.
Dans ce cas, il vaut mieux être conservateur. Une option est de reconstruire à partir d’une base saine, en réinjectant uniquement le contenu nécessaire. Une autre option consiste à demander une vérification approfondie, surtout si vous suspectez une persistance côté base de données ou une modification plus profonde. Le coût d’un traitement prudent est souvent inférieur au coût de la rechute, notamment en référencement, confiance, et charge technique.
WordPress peut être réparé, mais la stratégie doit être cohérente. La désinfection WordPress n’est pas qu’un nettoyage, c’est une reprise de contrôle, sur le code et sur les accès.
Si vous retenez une seule idée, retenez celle-ci: sécuriser l’accès FTP et l’accès admin, c’est ce qui évite que l’attaque ne revienne. Le code malveillant peut être supprimé en quelques heures. Un accès oublié peut suffire pour relancer le problème sur un délai surprenant.