Quand un site WordPress se fait compromettre, on ne se retrouve pas simplement avec un problème technique. On hérite aussi d’un doute permanent: qu’est-ce qui a été modifié, à quel moment, et surtout, est-ce qu’on a vraiment éradiqué la cause ou juste “désactivé les symptômes” ? J’ai vu des sites “nettoyés” en apparence, puis réinfectés quelques jours après, parce qu’un plugin resté en place continuait d’exécuter du code malveillant, ou parce que la réinstallation n’avait pas touché les bons répertoires.
Ce qui suit décrit une approche pragmatique, orientée réduction du risque: réinstallation propre de WordPress, purge des traces évidentes, puis configuration neuve et durcie. L’objectif n’est pas seulement de “faire revenir le site”, mais de le rendre plus difficile à re-percer.
Les signes qui ne trompent pas vraiment
Un site infecté ne se résume pas à une page blanche. Les comportements peuvent être subtils, surtout si l’attaque vise le SEO, les redirections ou l’injection de scripts. Voici des signaux qui reviennent souvent lors d’incidents, et qui poussent à traiter le cas comme une compromission réelle, pas comme un “bug” :
- Une hausse soudaine des requêtes vers le serveur, des erreurs 403 ou 500, ou des pics CPU Des redirections depuis certaines pages (ou depuis le front seulement) vers d’autres domaines Des utilisateurs créés sans raison, ou des rôles admin qui apparaissent “magiquement” Des fichiers anormaux dans wp-content (même sans comprendre leur rôle) Des scripts injectés dans le header, le footer, ou via un thème qui “semble normal”
Dans les incidents sérieux, on observe aussi souvent des “portes” qui ne sont pas visibles depuis l’interface: un fichier dans un dossier inattendu, un job cron tordu, un appel à une URL externe depuis un plugin, ou un code base64 caché dans un fichier PHP apparemment banal.
Avant de toucher quoi que ce soit : sécuriser et documenter
Le réflexe d’urgence, c’est de réinstaller tout de suite. Par expérience, ça marche mieux quand on prend deux ou trois minutes pour cadrer. Sinon, on perd des éléments utiles pour confirmer l’origine et prévenir la re-création.
D’abord, mettez le site en mode d’urgence si c’est possible sans exposer davantage. Ensuite, sauvegardez ce que vous pouvez, pas pour “réutiliser”, mais pour analyser après coup. Une sauvegarde complète (fichiers + base de données) permet de comparer avant et après, et de comprendre ce qui a été modifié.
Enfin, notez les détails concrets: date et heure approximatives de découverte, comportement observé, plugins récents installés, thèmes mis à jour, changements d’identifiants, ou mises à jour WordPress. Si vous intervenez après quelqu’un d’autre, ce dossier mental aide à éviter de refaire un mauvais choix, par exemple garder un plugin suspect “parce qu’il semble important”.
Ce point est essentiel dans une démarche de nettoyer site WordPress infecté, car sans historique, on ne sait pas quoi couper en premier.
Pourquoi une “simple désinfection” ne suffit pas toujours
Le mécanisme d’une infection WordPress ressemble parfois à une invasion multi-étapes. Même si vous supprimez le fichier le plus visible, il peut rester :
1) un mécanisme persistant (cron, script caché, plugin malveillant)
2) une porte d’accès (compte admin ajouté, clé API modifiée, token stocké dans la base) 3) des traces dans la base (options modifiées, utilisateurs “fantômes”, scheduled actions) 4) une modification des thèmes ou fichiers PHP (qui réémergent après une mise à jour ou une restauration partielle)La désinfection “légère” consiste souvent à repérer des scripts injectés dans certains fichiers, puis supprimer ce qui paraît évident. C’est parfois suffisant, surtout sur des attaques massives, mais pas quand le vecteur est interne, par exemple après compromission de l’espace admin.
Réinstaller proprement, c’est couper le flux: repartir d’un WordPress sain, puis reconstruire l’environnement en validant chaque élément.
Réinstallation propre: le principe qui réduit le risque
Réinstaller proprement ne veut pas dire simplement “réinstaller WordPress” par dessus. L’approche robuste consiste à repartir d’une base de fichiers WordPress saine, en purgant les composants du système qui ont le plus de chances d’être altérés.
Dans un schéma typique, vous avez deux masses à traiter:
- les fichiers: wp-admin, wp-includes, fichiers PHP racine, et surtout wp-content la base de données: options, utilisateurs, tables liées aux thèmes et plugins, cron, et métadonnées
Mon critère de jugement est simple: si je ne suis pas capable de prouver que chaque composant est sain, je le remplace. Et dans la pratique, on remplace d’abord le “cœur” (WordPress), ensuite on réintroduit prudemment wp-content de façon limitée, ou on repart aussi de zéro quand c’est plus sûr.
Plan de travail réaliste, avec trade-offs
Avant de choisir votre variante, posez une question qui change tout: voulez-vous conserver votre contenu (articles, pages, médias) et vos réglages, ou pouvez-vous repartir d’un contenu restauré ?
- Si le contenu est critique (gros site éditorial), on tente de conserver la base, mais en contrôlant et en nettoyant ce qui a été modifié. Si le site est petit, ou si l’infection est très “sale” (beaucoup de traces, redirections partout), repartir quasi complètement peut être plus rapide à long terme.
Une erreur fréquente est de restaurer la base “comme elle est” puis de n’attaquer que les fichiers. Souvent, la base contient des options et des entrées qui continuent d’alimenter l’infection, même si vous remplacez WordPress.
Étape 1 - Assainir l’accès: comptes, clés, et sessions
Même si vous réinstallez, il faut neutraliser la persistance liée aux accès.
Créez d’abord un utilisateur admin propre, puis désactivez l’accès au besoin. Si vous suspectez un vol de mots de passe, changez-les tous, y compris l’utilisateur du serveur et les identifiants de base de données. Si vous utilisez un hébergement avec accès direct (SSH ou panneau), révoquez aussi les tokens associés.
À ce stade, je traite toujours l’hypothèse suivante comme vraie: un attaquant a probablement eu la main au moins une fois. Donc, je change tout ce qui peut donner accès. Le coût de 20 minutes de changement vaut beaucoup plus que la réinfection quelques jours plus tard.
Étape 2 - Sauvegarder puis repartir sur un WordPress sain
Une réinstallation propre repose sur un point: vous devez utiliser les fichiers WordPress officiels. Ça paraît évident, mais j’ai déjà vu des scénarios où l’hôte proposait un “one click” qui restaurait un état antérieur, ou une archive contenant encore wp-content infecté.
Dans la pratique, vous pouvez:
- supprimer wp-admin et wp-includes, et remplacer par une installation propre remplacer les fichiers PHP racine (index.php, wp-config.php en particulier si vous le recréez) traiter wp-content séparément, car c’est souvent là que vivent plugins, thèmes et médias
Le cœur sain n’est pas négociable. Pour wp-config.php, je conseille de le recréer avec vos paramètres, plutôt que de “garder l’ancien et prier”.
Étape 3 - Nettoyer wp-content sans hésitation sur les éléments à risque
Wp-content est le terrain le plus fréquent des infections. Mais il n’est pas uniforme. Les médias et uploads ne sont pas “du code exécutable” dans leur majorité, alors que les thèmes et plugins sont des zones à risque.
Mon approche en incident est plus tranchée:
- plugins: soit vous repartez de zéro, soit vous réintroduisez uniquement ceux dont vous êtes sûr, et vous validez qu’ils ne se sont pas modifiés thèmes: pareil, évitez de conserver un thème qui a déjà servi de vecteur uploads: souvent plus simple à conserver, mais on vérifie qu’ils n’ont pas hébergé de fichiers PHP ou de webshell, même s’ils sont rarement visibles
Pour détecter, je fais une comparaison avec les timestamps et je recherche les schémas typiques (fichiers PHP inattendus dans des sous-dossiers d’uploads, scripts obfusqués). Sans aller sur des “trucs magic”, la logique est de repérer ce qui ne colle pas à vos pratiques habituelles.
Checklist de contrôle avant de relancer le site
Cette petite liste m’évite les oublis qui coûtent cher. Elle ne prend que quelques minutes, mais elle change l’issue.
- Couper la possibilité de réexécution en désactivant les plugins au premier démarrage Vérifier que les fichiers PHP dans uploads ne contiennent rien de suspect ou d’inattendu Recréer wp-config.php à partir de paramètres maîtrisés Vérifier les utilisateurs WordPress et supprimer ceux qui ne correspondent à aucun compte attendu Contrôler les tâches planifiées (cron) et supprimer celles qui ne sont pas explicables
Étape 4 - Purger la base de données avec méthode
Nettoyer la base ne signifie pas “tout supprimer”. Le but est de retirer les entrées malveillantes tout en conservant le contenu légitime si vous le souhaitez.
Les zones qui posent le plus souvent problème:
- utilisateurs: comptes créés, rôles escaladés, métadonnées de connexion modifiées options: paramètres qui injectent du code ou des redirections hooks et références: certaines entrées gardent en mémoire le comportement du site scheduling: tâches planifiées qui réinstallent ou déclenchent un payload
Le point délicat, c’est que WordPress stocke beaucoup de configuration. Une purge trop agressive peut casser votre site, mais une purge trop faible laisse de la persistance. Quand je n’ai pas une visibilité suffisante, je préfère restaurer le contenu au sens éditorial (articles, pages, médias) et reconstruire les réglages, plutôt que de conserver une base “contaminée”.
Choisir: conserver la base complète ou restaurer uniquement le contenu
Dans une réinstallation propre, vous avez deux stratégies.
La première consiste à restaurer la base complète, puis nettoyer en profondeur. Elle marche quand l’attaque est “localisée” et que vous savez quels éléments ont été modifiés.
La seconde consiste à extraire le contenu (posts, pages, menus selon votre architecture) dans un environnement de travail, puis à reconstruire une base neuve. Cette approche prend plus de temps, mais elle réduit l’incertitude. Elle est particulièrement adaptée si vous observez des comportements difficiles à expliquer, par exemple redirections sporadiques ou injection récurrente.
Si vous devez prendre une décision rapidement, basez-vous sur ce que vous voyez dans l’accès admin: s’il y a des symptômes persistants, la base est probablement impliquée.
Étape 5 - Reconfigurer WordPress de façon “propre”, pas seulement “fonctionnelle”
Une infection change rarement que les fichiers. Elle modifie aussi l’environnement: paramètres de lecture, chemins, plugins actifs, et parfois des réglages de cache ou de sécurité.
Je procède souvent comme suit:
Démarrage avec thème par défaut, plugins minimaux. Ensuite seulement, je réintroduis les briques une par une. Cette méthode a un avantage concret: si un plugin réintroduit un comportement suspect, vous le repérez vite.
Je fais aussi une vérification de cohérence sur les URL et domaines, surtout si l’attaque provoque des redirections vers d’autres sites. Même une petite modification dans une option peut suffire.
Enfin, je revalide vos endpoints: XML-RPC, REST API, formulaires d’inscription, et tout ce qui peut offrir une voie d’entrée. WordPress n’est pas “fragile” par défaut, mais une configuration mal maîtrisée le rend plus attaquable.
Exemple concret de réinstallation efficace sur un site “qui revenait”
J’ai eu un cas où la suppression du fichier suspect semblait avoir réglé la page d’accueil. Le site restait stable pendant 48 heures, puis re-affichait des redirections sur une dizaine de pages. En investiguant après la réinstallation, on a trouvé que la base contenait une option qui réinjectait le script via un mécanisme de chargement au moment où certaines conditions étaient remplies (un user agent particulier, ou une requête vers une route précise).
Le piège a été de conserver la base “au complet” parce que le contenu était important. La correction a été de reconstruire la base propre, puis de réimporter le contenu. Après ça, plus de redirections. Ce genre de scénario illustre bien pourquoi la réinstallation propre, sans confiance aveugle dans la base, change la donne.
Éviter la réinfection: durcir sans casser
Une fois le site “remis”, c’est tentant de relâcher la vigilance. C’est exactement là que des attaques reviennent. La durabilité passe par des habitudes de configuration.
Quelques leviers généralement utiles, selon votre stack:
- Limiter les privilèges, surtout pour les comptes administrateurs Mettre à jour WordPress, thèmes et plugins avec une cadence réaliste Surveiller les changements de fichiers dans wp-content (au minimum par logs) Activer une protection de type pare-feu applicatif si vous l’avez déjà, ou au moins un filtrage WAF Réduire les surfaces d’attaque: désactiver des fonctions non utilisées (inscription publique, XML-RPC si inutile, etc.)
Je reste prudent, car certaines protections peuvent interférer avec des outils légitimes. obtenez plus d'info Le but n’est pas de tout verrouiller à l’aveugle, mais de réduire les chemins d’entrée.
Une seconde checklist après redémarrage (celle qui évite la fausse confiance)
Quand vous remettez le site en ligne, faites un contrôle rapide mais réel, comme un visiteur et comme un admin.
- Ouvrir le site sur mobile et desktop, vérifier l’absence de redirections Se connecter en admin, vérifier la liste des plugins actifs, et l’absence de nouveaux comptes Contrôler le header et footer pour détecter toute injection de script visible Tester le comportement des pages critiques (accueil, formulaires, routes sous lesquelles vous avez observé des symptômes) Vérifier les logs serveur et applicatifs pour voir si des tentatives continuent
Ce n’est pas du perfectionnisme. C’est le moyen le plus rapide de savoir si vous avez juste “gagné du temps” avant une deuxième vague.
Configuration WordPress post-nettoyage, étape par étape (sans excès)
Voici mon déroulé typique quand je dois rendre un site propre sans perdre trop de temps.
Remplacement du cœur WordPress par une version saine, fichiers vérifiés Recréation de wp-config.php et validation des accès base de données Désactivation de tous les plugins au départ, puis réintroduction contrôlée Revalidation des thèmes, en commençant par un thème de base si possible Nettoyage de la base, suppression des utilisateurs inconnus et revue des options sensibles
Cinq lignes, mais derrière il y a la discipline. On ne remet pas “le même état que d’habitude”, on reconstruit.
Et les plugins de sécurité, ils servent à quoi dans ce scénario ?
Ils servent à détecter, bloquer, et parfois restaurer des comportements. Mais ils ne remplacent pas une réinstallation propre quand l’infection est persistante ou quand des fichiers ont été altérés.
Dans mon expérience, un plugin de sécurité utile après incident doit surtout vous aider à:
- repérer les anomalies dans les fichiers surveiller les connexions suspectes limiter des vecteurs d’attaque (tentatives, brute force) faciliter une alerte si un plugin ou un fichier change
En revanche, si vous l’installez pendant que wp-content reste contaminé, vous aurez un faux sentiment de maîtrise. Le bon ordre, c’est d’abord assainir, puis sécuriser.
Cas particuliers: multisite, staging, et CDN
Si votre WordPress est en multisite, l’infection peut toucher plusieurs sites. La réinstallation doit tenir compte de la structure. Vous devez vérifier les composants communs et les plugins réseau.
Si vous avez un staging, ne restaurer que sur staging ne suffit pas si la contamination vient aussi du pipeline déploiement. J’ai vu des “staging propres” puis des “production qui retombe”, parce que la source (CI, dépôt, ou un plugin partagé) réintroduisait un élément déjà corrompu.
Pour les CDN et caches, attention aux perceptions. Un cache peut masquer une réinfection pendant quelques heures, puis la révéler après expiration. C’est une source de confusion courante. Quand vous testez, faites-le depuis un navigateur différent ou en désactivant le cache si possible.
Comment vérifier que vous êtes vraiment revenu à un état sain
La vérité, c’est qu’on ne “prouve” pas à 100% une absence de compromission sans audit approfondi. Mais on peut réduire le risque à un niveau raisonnable en combinant plusieurs signaux.
Si, après réinstallation propre, la réintroduction contrôlée des plugins ne redéclenche pas de symptômes, et que la base ne montre plus d’éléments inattendus (utilisateurs, options étranges, tâches planifiées), vous êtes sur une trajectoire crédible.
Je privilégie aussi des mesures externes: logs d’erreurs, logs d’accès, et surveillance. Quand une attaque persistante existe, elle laisse souvent des traces, même infimes. Une absence totale sur une période significative, combinée à un site stable, est un bon indicateur.
Ce qu’il ne faut pas faire, même si ça semble “plus rapide”
Il y a des raccourcis qui coûtent cher, parce qu’ils conservent la cause.
Je les cite ici en phrases directes, sans en faire une liste, car l’idée n’est pas d’alourdir, mais de prévenir:
Ne restaurez pas une base “au hasard” après avoir remplacé les fichiers, si vous avez déjà observé des injections ou des redirections. Ne gardez pas un thème qui a possiblement servi de vecteur, surtout s’il a été modifié récemment. Ne gardez pas des plugins “parce qu’ils fonctionnent”, quand ils ont été installés ou mis à jour autour du moment de l’incident. Et ne re-mettez pas en ligne tant que vous n’avez pas vérifié au moins les pages symptomatiques.
Récapitulatif utile pour démarrer demain matin
Si vous devez nettoyer site WordPress infecté en mode réaliste, la logique tient en quelques principes:
Réinstaller proprement WordPress pour couper le cœur potentiellement altéré, traiter wp-content avec une discipline stricte, nettoyer ou reconstruire la base selon le niveau d’incertitude, puis configurer et réintroduire les composants un par un.
Ce n’est pas la voie la plus “brillante” à court terme, mais c’est celle qui limite les retours de flamme.
Si vous me donnez votre contexte, je peux vous aider à choisir la variante la plus adaptée (reconstruction base complète ou rétablissement avec purge ciblée). Par exemple: vous avez un site mono ou multisite, vous avez des redirections, et l’infection a été détectée après quelle mise à jour ou quel changement ?