Quand un site WordPress est infecté, on pense tout de suite à la porte d’entrée technique: un plugin compromis, un thème modifié, un script dans un fichier inattendu. Et c’est vrai. Mais dans beaucoup d’incidents que j’ai rencontrés sur le terrain, le vrai problème persiste après le nettoyage “visible”. Le site semble refonctionner, puis quelques jours plus tard, les mêmes pages changent, des redirections réapparaissent, ou de nouveaux comptes administrateurs apparaissent.
Dans ces cas-là, l’attaque n’a pas seulement laissé une trace dans les fichiers. Elle a souvent pris le contrôle des utilisateurs, en créant des accès discrets ou en escaladant des rôles. Corriger les rôles et les capacités, ce n’est pas un détail de “hardening”. C’est une partie centrale du nettoyage site WordPress infecté.
Pourquoi l’infection revient malgré “le reste est propre”
WordPress a deux concepts qui se mélangent facilement au début: les rôles (administrateur, éditeur, contributeur, auteur, participant, etc.) Et les capacités (les permissions concrètes, comme publier, gérer les options, installer des plugins, modifier des thèmes). Un pirate peut jouer sur l’un ou l’autre.
L’une des méthodes les plus fréquentes consiste à: 1) créer un utilisateur avec un rôle trop puissant mais pas forcément “admin” au sens où vous l’attendiez, 2) lui donner des capacités spécifiques via des métadonnées, 3) ou exploiter un plugin ou un thème qui ajoute des capacités et maintient ce “chemin” d’accès même après nettoyage des fichiers.
Autre scénario très réaliste: un compte administrateur n’est pas compromis directement. Mais le pirate a modifié le système de rôles, par exemple en altérant les définitions de capacités ou en injectant du code qui relie un rôle à des droits supplémentaires. Même si vous supprimez le fichier malveillant dans un dossier, le site peut continuer à “autoriser” des actions anormales via la base de données.
J’ai déjà vu une situation où l’on avait supprimé le plugin douteux, remis un thème depuis une version propre, changé les mots de passe… puis un utilisateur “éditeur” a commencé à pouvoir installer des plugins. Sur le moment, tout le monde a cherché dans l’interface, et le fait est qu’en apparence, le rôle n’avait pas changé. Le problème était dans la configuration des capacités et dans une couche de mapping liée au plugin compromis.
Ce que vous devez vérifier avant de toucher aux rôles
Avant de modifier quoi que ce soit sur la gestion des utilisateurs, prenez deux précautions. Elles évitent les “fausses bonnes idées” qui aggravent les choses.
D’abord, assurez-vous d’avoir une base stable: vos fichiers ont été nettoyés et les vecteurs d’exécution (plugins, thèmes, fichiers uploadés, scripts dans les répertoires) ne sont plus en place. Sinon, vous risquez de corriger les rôles sur une base qui va recevoir une nouvelle charge utile.
Ensuite, ne vous fiez pas uniquement à l’écran des rôles dans wp-admin. L’interface montre un aperçu, mais les capacités réelles peuvent être dérivées de filtres, de rôles personnalisés et de métadonnées. Un utilisateur peut afficher “auteur”, tout en ayant des capacités supplémentaires.
Si vous avez accès à la base de données, c’est souvent là que se trouvent les détails. Les tables et options typiques en jeu sont wp_users, wp_usermeta et quelques options liées aux rôles et capacités. Selon votre préfixe, les noms changent, mais la logique reste.
Identifier l’escalade de privilèges, sans tout casser
Dans un incident, la première question est souvent: “quels comptes ont des droits inhabituels ?”. Une deuxième question suit rapidement: “d’où viennent ces droits ?”. Les réponses ne sont pas toujours dans les fichiers, elles peuvent être dans la base.
Signaux concrets à surveiller
- Utilisateurs nouvellement créés sans action de votre part, surtout s’ils ont été créés récemment par rapport au moment de l’infection. Comptes qui ne “devraient pas” être capables de tâches d’administration, comme installer des plugins, modifier des thèmes, gérer des options, ou accéder à des zones sensibles. Rôles qui semblent cohérents dans l’interface mais qui ne collent pas au comportement réel (par exemple, quelqu’un peut éditer des fichiers ou exécuter des actions en admin). Plugins ou thèmes qui changent le modèle de capacités via des filtres. Un code “qui ajoute une capacité” peut être discret mais décisif.
Le point clé, c’est que l’infection peut manipuler les capacités de deux façons: soit directement en augmentant les droits d’un utilisateur, soit en changeant la manière dont WordPress associe des capacités à un rôle.
Un piège: confondre rôle affiché et capacités effectives
WordPress calcule les capacités d’un utilisateur en combinant le rôle principal et, potentiellement, des ajouts spécifiques en métadonnées. Donc un utilisateur peut:
- avoir un rôle “éditeur”, mais posséder des capacités supplémentaires via wp_usermeta. Inversement, un admin peut avoir des capacités retirées partiellement, ce qui rend le diagnostic plus difficile et donne une impression de dysfonctionnement “aléatoire”.
C’est pour ça que corriger les rôles et capacités ne se résume pas à remettre des rôles “standards” au hasard.
La stratégie propre: normaliser les rôles puis réduire au minimum
Le nettoyage efficace suit une logique simple: vous voulez revenir à un état cohérent et prévisible. Cela veut dire deux actions complémentaires: remettre l’existant en état sain, puis imposer le principe du moindre privilège.
Normaliser les rôles existants
WordPress utilise un jeu de rôles et de capacités. Les plugins peuvent en définir des personnalisés, et les sites ont parfois des rôles créés “à la main”. Mais dans un contexte d’infection, la prudence consiste à:
- identifier les rôles “sur-mesure” introduits après l’incident, vérifier s’ils sont nécessaires, sinon, les supprimer ou neutraliser leur influence.
Sachez aussi que remettre manuellement un rôle à zéro peut casser des fonctionnalités légitimes. Par exemple, un plugin de formulaire ou un outil de réservation peut compter sur une capacité spécifique pour un rôle custom. La différence, c’est que sur un site sain, vous savez pourquoi ce rôle existe, et vous l’assumez. Sur un site infecté, un rôle custom sans historique est un drapeau.
Réduire au minimum après normalisation
Une fois que vous êtes revenu à un modèle sain, vous réduisez les droits. Cela ne veut pas dire supprimer tous les droits aux éditeurs. Cela veut dire éliminer les capacités qui ne sont pas nécessaires à leur rôle réel.
J’ai une règle pratique: si quelqu’un n’a pas besoin d’installer des plugins ou de modifier des thèmes, il ne doit pas avoir ces capacités. Les infections qui réapparaissent le font souvent parce que les accès “administration” restent possibles pour un périmètre trop large.
injection base de données WordPressÉtapes concrètes pour corriger rôles et capacités après suppression
Voici une approche qui marche bien en intervention, parce qu’elle combine observation, vérification et correction graduelle.
1) Passer en “mode contrôlé” et verrouiller les comptes à risque
Avant toute manipulation, limitez l’exposition. Si vous pouvez:
- placez le site en maintenance, désactivez provisoirement les actions potentiellement exploitables, et changez les mots de passe des comptes qui ont un rôle élevé.
Je sais que ça ne corrige pas “les capacités”, mais ça arrête les actions pendant que vous inspectez la base. Pendant une phase d’analyse, c’est le genre de détail qui vous évite d’avoir à faire deux fois le même travail.
2) Révoquer les accès des comptes suspects, puis les remettre en service après audit
Sur un site infecté, un compte suspect ne se “nettoie” pas par changement de rôle seul. On commence par couper et réintroduire proprement.
Concrètement, vous cherchez les comptes:
- créés récemment, ayant des rôles ou capacités inattendus, ou ayant des traces dans le comportement (sessions, pages modifiées, redirections).
Une fois identifiés, vous réduisez leurs droits ou vous les désactivez temporairement, le temps de valider le modèle.
3) Vérifier et corriger les capacités stockées dans la base
Sans entrer dans des manipulations risquées “à la main” pour tous les cas, l’idée est claire: si un utilisateur a des capacités additionnelles non attendues, elles apparaissent dans ses métadonnées.
Dans l’infrastructure WordPress, ces métadonnées servent à exprimer des capacités ajoutées ou retirées. Quand un pirate a réussi une escalade, il peut y laisser des traces. Même si le rôle principal semble correct, les capacités “override” peuvent rester.
Le point important, c’est la méthode. La meilleure approche consiste à:
- comparer les capacités effectives des utilisateurs “sains” et “suspects”, repérer les différences, puis corriger en réappliquant un ensemble cohérent de capacités basé sur les rôles standard ou sur votre politique interne.
Si vous utilisez un plugin de gestion des rôles, vérifiez aussi qu’il ne réintroduit pas ces capacités. Dans certains incidents, c’est le plugin qui re-propage un mapping corrompu.
4) Réinitialiser les comptes administrateurs à un état maîtrisé
Souvent, la correction la plus robuste consiste à reconstruire le périmètre admin à partir d’un ensemble de comptes que vous contrôlez réellement. Oui, c’est plus “lourd”, mais c’est plus sûr.
Dans la pratique, vous gardez un petit nombre d’administrateurs strictement nécessaires, avec des mots de passe nouveaux. Vous supprimez ou désactivez les autres comptes que vous ne pouvez pas justifier.
On voit souvent des sites où il y a plusieurs comptes admin historiques, utilisés pour des missions ponctuelles. En contexte d’infection, ces comptes deviennent un risque parce que leur historique et leurs usages ne sont plus clairs.
Voici une checklist courte que j’utilise lors d’un incident, avant de déclarer “le nettoyage terminé” sur la partie utilisateurs.
- Vérifier les utilisateurs créés dans la fenêtre temporelle de l’infection (par exemple, depuis 7 à 30 jours selon votre journal). Contrôler que chaque compte admin a un besoin réel et des mots de passe changés. Repérer les rôles inhabituels ou personnalisés non documentés. Comparer les capacités effectives des comptes “équivalents” (un éditeur normal vs un éditeur suspect). Vérifier que vos plugins de rôles, si vous en avez, n’appliquent pas une configuration anormale.
Comment savoir si un rôle est “infecté” ou simplement “différent”
C’est une question qui revient tout le temps: “comment distinguer un rôle légitime custom de celui injecté pendant l’incident ?”.
Le bon réflexe est de raisonner avec l’outillage et le contexte.
Si votre site utilise des plugins d’authentification, de gestion d’offres, ou des workflows éditoriaux, il est normal d’avoir des rôles supplémentaires. Ces rôles ont généralement:
- une origine claire (plugin précis), une date d’apparition cohérente avec l’installation du plugin, des capacités cohérentes avec l’usage.
À l’inverse, des rôles apparaissent parfois sans installation évidente, ou après une mise à jour. Ils peuvent avoir des capacités “bizarres” comme la capacité de gérer des options ou d’installer des plugins. Sur un site “normal”, ces capacités ne devraient pas être alignées sur un rôle non administratif.
Autre indice: la logique du site. Si vous ne voyez pas de feature censée utiliser ce rôle, c’est un signal. Sur un site où tout le monde écrit des articles, un rôle “manager” avec la capacité d’installer des thèmes n’a pas de sens sans raison.
Cas fréquents et corrections adaptées
1) Un utilisateur “éditeur” peut installer des plugins
Ce cas arrive quand:
- des capacités ont été ajoutées à un rôle non administratif, ou qu’un plugin a élargi les droits de façon inattendue.
Correction raisonnable: revenir aux capacités standard du rôle éditeur dans WordPress, puis réappliquer uniquement ce qui est nécessaire. Si l’éditeur doit gérer des contenus, il n’a pas besoin d’installer des plugins. Si vous avez un workflow où un éditeur “déploie” des plugins, le besoin existe peut-être, mais il doit être explicite et documenté.
2) Des comptes admins réapparaissent
Si vous voyez des comptes administrateurs réapparaître, ce n’est pas un simple problème de rôle. Cela signifie que le vecteur d’infection a gardé une porte ouverte. Les rôles et capacités corrigés sont alors un traitement temporaire.
Dans ce cas, traitez en parallèle:
- l’exécution malveillante dans les fichiers, la persistance dans la base (par exemple, un élément qui crée des comptes ou modifie des rôles à l’avenir), les accès (mots de passe, sessions, clés d’API ou tokens).
Corriger les capacités ne suffit pas si un mécanisme continue à agir.
3) Les rôles “fonctionnent”, mais des capacités “disparaissent” après correction
Parfois, vous corrigez trop agressivement. Un plugin de galerie, un outil SEO, ou un workflow éditorial peut dépendre d’une capacité spécifique.
La bonne approche consiste à:
- corriger par étapes, valider fonctionnalité après chaque réduction, et conserver un plan de repli (par exemple, un export de la base ou au minimum une sauvegarde des tables concernées).
Ce n’est pas de la paranoïa. Sur un incident, on manque souvent de temps, et c’est facile de faire une réduction qui “casse un peu tout”. Un diagnostic plus fin évite de se retrouver à réparer des relations de capacités pendant que la compromission se poursuit.
La vérification finale: prouver que les droits sont cohérents
Une fois les rôles et capacités corrigés, vous voulez confirmer avec des tests simples. L’idée n’est pas de tout reproduire en préprod, mais de valider les points sensibles.
Concrètement, connectez-vous avec les comptes dont les droits ont été corrigés, et testez des actions:
- publication, édition de contenu, accès aux menus d’administration liés aux rôles, installation et mise à jour de plugins, modification de thèmes.
Si un compte non admin peut accéder aux écrans d’installation, ou si vous observez des actions sensibles disponibles sans justification, vous n’êtes pas au bout. Le nettoyage sur WordPress est souvent gagnant quand il est vérifié à l’interface, pas seulement dans la base.
J’ajoute cette deuxième petite liste de vérifications, parce qu’elle évite les “surprises” que j’ai déjà vues en production.
- Se connecter avec chaque rôle critique (admin, éditeur, rôle custom si existant) et vérifier les menus liés à la gestion de plugins et thèmes. Tester les actions d’administration “haut risque” (modifier des options, installer des plugins) avec un compte non autorisé. Vérifier que les utilisateurs suspects ne peuvent plus créer de nouveaux comptes ou modifier des rôles. Contrôler qu’aucun plugin de gestion des rôles n’applique une configuration persistante corrompue. Surveiller pendant quelques jours la création de nouveaux comptes et les modifications de rôles.
Rôle custom, plugin de rôles, et arbitrage de sécurité
Beaucoup de sites ont une couche supplémentaire, un plugin qui gère des rôles custom, ou qui étend l’authentification. Ces outils sont utiles, mais en incident, ils compliquent le diagnostic.
Mon conseil pratique: pendant la phase de correction, gardez une règle de décision. Si un plugin de rôles:
- est essentiel à votre site et vous comprenez ses responsabilités, et vous pouvez vérifier sa configuration, Alors vous l’intégrez dans le diagnostic.
Si au contraire il a été installé récemment, ou si sa configuration n’est pas expliquée, traitez-le comme un point suspect. Parfois, le plus rapide est de le désactiver, de remettre l’environnement standard WordPress, puis de le réactiver après audit. Oui, ça prend du temps, mais c’est plus direct que de corriger des capacités “à l’aveugle” alors que le plugin continue d’écrire une politique.
Ce qu’il faut faire le jour où tout semble réglé
Le nettoyage site WordPress infecté se termine rarement le jour même. Mais vous pouvez réduire fortement le risque de récidive en imposant une discipline.
Changez les mots de passe avec une méthode rigoureuse, évitez les comptes partagés, limitez le nombre de personnes ayant des droits d’installation ou de modification de thèmes, et surveillez les événements qui comptent. Les rôles et capacités corrigés ne seront réellement “stables” que si vous empêchez la persistance.
Enfin, documentez. Si vous avez dû réaffecter des capacités ou supprimer un rôle, notez qui a besoin de quoi, et pourquoi. Lors d’une prochaine intervention, vous gagnerez des heures, et vous saurez distinguer ce qui est légitime de ce qui est un retour de flamme.