Un site WordPress infecté se manifeste rarement de la même façon d’un client à l’autre. Parfois, c’est silencieux, juste une dégradation du trafic et des pages qui “prennent” du poids sans explication. D’autres fois, c’est visible en quelques minutes: redirections vers des domaines inconnus, formulaires qui envoient autre chose que ce qui est affiché, ou requêtes anormales qui saturent le serveur. Dans les cas les plus pénibles, l’infection n’est même pas un “fichier pirate” unique, mais un enchevêtrement de traces, d’accès persistants et de contenus injectés de manière à passer sous le radar.
L’objectif de la remise en état n’est pas seulement de “supprimer ce qui est dangereux”. Il faut aussi empêcher le retour, vérifier que le site reste stable et rétablir une configuration saine. C’est là que la sécurité site WordPress professionnel fait la différence: une opération propre et rationnelle vaut mieux qu’une chasse au fichier au hasard.
Première urgence: contenir sans casser
La première erreur, celle que j’ai vue plusieurs fois sur des sites en production, consiste à nettoyer trop vite pendant que l’attaquant est encore actif. Tant que la porte reste ouverte, chaque suppression de fichier peut être suivie par une réécriture immédiate du même contenu, parfois avec une sophistication supérieure.
Le bon réflexe consiste à réduire l’exposition, puis à observer. Par exemple, si le site redirige des utilisateurs, le fait de désactiver temporairement certaines fonctions (ou de mettre le site en maintenance) peut limiter la propagation des clics “polluants” vers des destinations tierces. Sur un site que j’ai aidé à récupérer, la mise en maintenance a stoppé la vague de redirections pendant qu’on analysait le vecteur d’accès, et cela a réduit drastiquement les logs à exploiter.
Concrètement, la stratégie dépend de votre situation, mais dans l’esprit: limiter l’impact et garder des preuves.
Préparer l’enquête: sauvegardes, accès, preuves
Avant de toucher au code, on se donne les moyens d’être efficace. Une remise en état sérieuse commence par la préparation, pas par le “truc à supprimer”.
Voici ce que je fais systématiquement dans les premières minutes, parce que cela évite de perdre du temps sur la suite:
Créer une copie complète (fichiers + base de données) vers un dossier isolé, en gardant la trace du moment exact. Exporter la liste des utilisateurs WordPress et vérifier les rôles, en notant les dates de création si votre interface les affiche. Récupérer les logs disponibles (serveur web, PHP, éventuel pare-feu applicatif, logs d’hébergement). Identifier les points de persistance possibles (fichiers récemment modifiés, plugins et thèmes suspects, tâches planifiées, webhooks). Définir un canal de communication (maintenance, message aux visiteurs, accès administrateur limité) pour éviter que plusieurs personnes “réparent” en même temps.Cette étape n’a pas besoin d’être longue, mais elle doit être complète. Le pire scénario, c’est de commencer le nettoyage sans sauvegarde, puis de découvrir après coup que la base a été altérée plus profondément que prévu.
Comprendre les signes: ce qu’il faut observer tout de suite
Une infection WordPress peut viser différents objectifs: spam SEO via des pages injectées, exécution de code côté serveur, vol de sessions, redirections, ou ajout d’outils de surveillance. Sans diagnostic, on risque de supprimer un symptôme et de laisser l’infrastructure derrière.
Pendant l’analyse initiale, je cherche des signaux concrets. Par exemple:
- Modifications de fichiers hors des patterns attendus: fichiers créés récemment, permissions inhabituelles, présence de code obfusqué dans des emplacements où il n’y a pas de raison qu’il soit. Plugins ou thèmes “fantômes”: ajout d’un plugin dont on ne se souvient pas, thème modifié à la place du code source, extensions installées en dehors du processus normal. Anomalies dans la base: options WordPress modifiées, contenus qui apparaissent sans logique éditoriale, utilisateurs ajoutés avec des rôles élevés. Comportement réseau: redirection vers des domaines externes, récupération de scripts à distance, appels de requêtes depuis des fichiers normalement passifs. Indicateurs dans les formulaires: si un formulaire “marche”, mais que les résultats ne sont pas ceux attendus, il peut y avoir une altération du traitement PHP ou une injection côté JS.
Dans un cas réel, la redirection semblait venir du front, mais l’origine était un fichier dans un répertoire rarement surveillé. La personne avait remplacé le thème, sans toucher le reste. Le problème revenait en boucle parce que la persistance était ailleurs.
Nettoyer: méthode par couches, pas au hasard
Le nettoyage efficace suit une logique. D’abord, on élimine les éléments compromis de manière sûre. Ensuite, on restaure une base saine. Enfin, on réduit les possibilités de récidive.
1) Traiter les accès et la surface d’entrée
Avant de modifier des fichiers, je vérifie l’accès. Une infection qui persiste le fait souvent via:
- un utilisateur nouvellement créé, un compte admin dont le mot de passe a été changé, un mécanisme qui réactive un compte compromis, ou un accès FTP/Shell utilisé hors du processus habituel.
Sur WordPress, ça peut être déroutant: même si vous supprimez un plugin malveillant, l’attaquant peut réinstaller ce plugin plus tard. C’est pour cela qu’on commence par les comptes.
Étape clé: changer les mots de passe des comptes à privilèges, et idéalement forcer une réauthentification. Si votre hébergeur permet de révoquer des sessions, faites-le. En parallèle, vérifiez aussi https://gardewp.fr/securite-wordpress/ les accès au niveau de l’hébergement (FTP, SSH, accès panel) car l’infection peut venir d’une compromission plus large que WordPress.
2) Restaurer le cœur WordPress propre, si nécessaire
Sur certains sites, le “nettoyage du code” consiste à corriger un fichier ici, un autre là. C’est utile quand l’infection est localisée. Mais quand vous avez des doutes sur l’intégrité globale, une restauration du cœur WordPress devient plus rationnelle.
Le point d’arbitrage est simple: si vous êtes incapable d’identifier toutes les modifications, vous passez votre temps à courir après. Restaurer la base “wordpress core” propre, puis remettre thèmes et plugins contrôlés, évite bien des impasses.
À noter: la restauration du cœur ne supprime pas automatiquement un contenu injecté dans la base, ni un backdoor persistant créé via des options ou des données. Elle réduit surtout le risque côté structure du CMS.
3) Nettoyer thèmes et plugins avec une règle stricte
Pour les thèmes et plugins, je fonctionne avec une logique de responsabilité: soit vous contrôlez le code, soit vous le supprimez et vous remplacez.
Quand je vois un plugin modifié, des fichiers ajoutés, ou du code obfusqué, je ne tente pas forcément de “comprendre” immédiatement. Je fais plutôt: identification, élimination, restauration, puis vérification.
Trade-off important: si vous avez des modifications “légitimes” sur un thème (customisations), supprimer le thème complet peut casser des fonctionnalités. Dans ce cas, on doit distinguer ce qui est custom de ce qui a été injecté. Cela demande du temps, mais c’est ce qui évite d’effacer du travail réel.
Souvent, la meilleure approche consiste à comparer avec la version saine (celle fournie par le dépôt officiel ou votre build interne), puis à réinjecter les fichiers propres.
4) Vérifier la base de données au-delà des contenus
Une infection peut injecter du contenu via des tables et options. Certaines injections laissent des traces, d’autres sont plus discrètes, par exemple via des mécanismes de planification, des options chargées au runtime, ou des champs utilisés par le thème.
Ici, je me concentre sur:
- options anormales, contenus publiés sans logique éditoriale, tables liées aux formulaires, intégrations, ou métadonnées, utilisateurs inattendus.
Si la base a été touchée, effacer seulement quelques posts ne suffit pas. Parfois il faut réinitialiser des options ou supprimer des entrées ajoutées par l’attaquant, puis revalider la logique de rendu.
Sécuriser après nettoyage: empêcher le retour
Nettoyer est nécessaire, mais insuffisant. Une remise en état “terminée” n’existe que lorsque vous avez réduit les canaux d’accès et renforcé la gestion des mises à jour.
Mots de passe, rôles, et hygiène des comptes
Après incident, je recommande d’avoir une politique de comptes plus stricte:
- limiter le nombre de comptes admin, supprimer les comptes inutiles, imposer des mots de passe robustes, réviser les rôles (un rôle trop permissif est une porte ouverte).
Le point que je rappelle souvent: un site peut être “propre” en fichiers et rester compromis si un compte admin persiste et n’a pas été sécurisé au bon moment.
Durcir les mises à jour et le cycle de maintenance
Beaucoup d’infections profitent de deux choses: des plugins non maintenus et des cycles d’update irréguliers. Mettre un site à jour après nettoyage n’est pas juste une formalité.
Le piège classique: mettre à jour immédiatement pendant que vous n’avez pas fini de nettoyer. Cela peut vous compliquer la lecture des changements. La bonne séquence dépend du volume, mais en pratique: vous nettoyez, vous stabilisez, puis vous mettez à jour progressivement avec surveillance.
Contrôler les tâches et l’exécution planifiée
WordPress peut exécuter des actions planifiées, selon les plugins, les thèmes, et votre configuration. Si un attaquant a injecté une tâche, le site peut paraître “net” au moment de la vérification, puis se réinfecter plus tard.
Dans les outils disponibles (selon votre environnement), vérifiez les événements planifiés, les webhooks, et tout mécanisme qui déclenche du code ou des requêtes externes.
Signes que le nettoyage n’est pas terminé
Le vrai indicateur est rarement “le site redevient normal”. Il est plutôt “l’incident ne revient pas” dans un horizon suffisamment long pour être crédible.
Voici quelques signaux qui doivent vous alerter même si tout semble fonctionner:
- des redirections réapparaissent après un délai, des pics de requêtes reviennent dans les mêmes heures, des fichiers redeviennent modifiés, des utilisateurs réapparaissent, ou des rôles changent, les scans génèrent de nouveaux alertes sur des chemins qui devraient être propres.
Dans un projet précédent, la première ronde de nettoyage avait corrigé l’affichage. Les redirections avaient cessé, mais deux jours plus tard, on a constaté un retour via une réinstallation automatisée par un mécanisme externe. La cause venait d’un accès hébergeur resté actif.
Si vous n’avez pas la certitude sur l’accès initial, il faut considérer qu’une seconde phase de vérification sera probablement nécessaire.
Cas particuliers: multisite, CDN, et environnements complexes
Tous les sites WordPress ne se comportent pas comme un simple dossier wp-content sur un serveur unique.
WordPress multisite
En multisite, l’infection peut être propagée à travers le réseau, et certaines tables/options peuvent exister à plusieurs niveaux. Un nettoyage “local” peut sembler suffisant sur un sous-site, mais le réseau continue d’être l’exutoire de la persistance.
Dans ce cas, je traite d’abord la couche réseau, puis je vérifie chaque sous-site.
CDN et caches
Si vous utilisez un CDN ou un système de cache, le comportement observé côté navigateur peut mentir. Vous pouvez croire que le site est propre parce que les pages en cache n’affichent plus le contenu injecté, tout en gardant une exécution malveillante en arrière-plan.
Après nettoyage, prévoyez un contrôle avec cache neutralisé, ou via des accès différents, afin de vérifier le rendu réellement servi.
Hébergement avec restrictions
Certains hébergeurs limitent la lecture de fichiers ou compressent les logs. Cela peut compliquer la preuve. Dans ce scénario, je m’appuie davantage sur des comparaisons de fichiers, sur des signaux de modifications, et sur une restauration plus large des composants connus.
Le compromis est clair: quand les logs sont faibles, vous augmentez la part de restauration contrôlée et de vérification par intégrité.
Plan de remise en état réaliste, du jour même à la semaine suivante
Une remise en état crédible se déroule en phases. Le jour même, on limite l’impact, on stabilise et on supprime la persistance. Les jours suivants, on surveille, on durcit, et on confirme l’absence de retour.
Sur une fenêtre typique, je vise un minimum de surveillance sur quelques jours. Parfois, une infection a des déclencheurs différés. Un “net” validé en 30 minutes peut être un faux signal si le mécanisme attend une condition.
Pour structurer la suite, je me base sur ces repères:
Contrôle immédiat après nettoyage: comportement front, absence de redirection, absence de fichiers suspects. Vérification des comptes: utilisateurs présents, rôles, changements de mots de passe, sessions révoquées si possible. Contrôle base de données: options, contenus anormaux, entrées persistantes. Surveillance sur plusieurs jours: logs, pics de requêtes, erreurs PHP, tentatives d’accès. Mise à niveau des composants: plugins, thèmes, configuration, suppression de ce qui n’a plus d’utilité.Je sais que certains clients veulent tout boucler vite. C’est compréhensible, mais “terminé le jour même” peut signifier “incomplet”. L’enjeu est de gagner du temps à moyen terme.
Checklist de validation finale (avant de réouvrir au public)
Quand vous êtes prêt à considérer le site comme stable, il faut vérifier des points concrets. Voici ma petite liste de validation, courte, mais utile:
Aucun fichier récemment modifié suspect dans les emplacements critiques (wp-content, fichiers racine, scripts chargés). Aucun utilisateur inattendu et tous les comptes à privilèges ont des mots de passe changés et des rôles cohérents. Aucun code obfusqué ou chargement externe dans les thèmes et plugins actifs, hors scripts attendus. Comportement front normal sur plusieurs navigateurs et avec cache neutralisé si possible. Absence de symptômes dans les logs sur 48 à 72 heures, selon la fréquence habituelle de votre trafic.Si un seul point échoue, je ne “rouvre” pas vraiment, je continue les vérifications.
Prévenir la prochaine fois: ce qui marche vraiment en pratique
La prévention ne consiste pas à empiler dix outils. Elle consiste à créer des habitudes et à réduire la surface d’attaque. Sur des projets WordPress professionnels, je vois souvent les mêmes leviers revenir, parce qu’ils sont actionnables et mesurables.
La première approche est organisationnelle: procédure claire de déploiement, contrôle des plugins ajoutés, et revue des modifications de code. La deuxième approche est technique: mises à jour, sauvegardes testées, limitation des permissions, supervision.
Et il y a un point souvent négligé: la capacité à restaurer rapidement. Une sauvegarde que vous n’avez jamais testée ressemble à de la sécurité sur le papier, mais ne sert pas quand l’incident arrive.
Enfin, n’oubliez pas qu’une infection WordPress est souvent une conséquence, pas une cause unique. Un site compromis indique parfois une faiblesse ailleurs: mot de passe réutilisé, accès d’hébergement trop large, plugin ajouté sans vérification, ou machine interne infectée.
Quand faire appel à quelqu’un, et quand vous pouvez gérer seul
Le nettoyage peut être gérable en interne si vous avez de bonnes sauvegardes, de l’hygiène de code, et un accès clair aux environnements. Mais dès que le site est critique pour le business, ou que vous suspectez une compromission de l’hébergement, il vaut mieux externaliser l’analyse.
Voici une règle de tri rapide que j’utilise:
Vous pouvez traiter en interne si l’infection est localisée, documentée, et que vous avez un historique clair des changements. Vous devez solliciter si l’accès semble compromis au-delà de WordPress, ou si la persistance est difficile à expliquer. Vous engagez une remise en état complète si vous ne pouvez pas garantir l’intégrité de la base et du code après la première passe.Dans le doute, la décision dépend du temps perdu à “réparer” sans certitude. Souvent, une intervention plus structurée au départ évite deux semaines de yoyo.
Un mot sur la communication client et la réputation
Quand un site a été infecté, la communication compte, même si vous n’avez pas de fuite confirmée. Il est utile d’expliquer ce que vous avez fait, sans dramatiser. Les clients veulent surtout savoir trois choses: ce qui a été compromis, ce qui a été supprimé, et comment vous réduisez le risque de retour.
Si votre site affiche des contenus injectés, ou si des redirections ont existé, prévoyez un retour d’information après stabilisation, avec la liste des actions effectuées. Une approche factuelle rassure, et facilite la relation.
Un site WordPress infecté, ce n’est pas seulement une question de “suppression de fichiers”. C’est une remise en état avec une logique de cause, une méthode de validation, et une prévention pragmatique. Quand vous passez par des étapes claires, que vous conservez des preuves et que vous restaurez une base propre, vous transformez un événement anxiogène en projet maîtrisé, avec un résultat durable.