Après un nettoyage WordPress, on a souvent un soulagement immédiat, puis une question plus difficile: et maintenant, qu’est-ce que l’attaquant a pu emporter, réutiliser, ou laisser derrière lui? Même quand vous avez supprimé le code malveillant, fermé les accès et corrigé la faille, il reste presque toujours une zone grise sur les secrets.
Dans WordPress, ces “secrets” ne sont pas seulement des mots de passe d’utilisateurs. Il y a aussi des jetons (tokens), des cookies de session, des clés et sels dans wp-config.php, des mots de passe d’applications, des identifiants d’API, des connexions vers des services tiers, et parfois des configurations stockées dans la base. La bonne stratégie consiste à changer ce qui peut donner un accès persistant, puis à invalider tout ce qui permet de revenir sans repasser par le contrôle initial.
Le but de cet article est de vous donner une méthode réaliste, avec des arbitrages concrets, pour changer identifiants et tokens après un nettoyage WordPress, sans casser inutilement votre site.
D’abord, clarifier ce que “changer” signifie dans WordPress
Quand on parle de changer des identifiants et tokens après un incident, il faut distinguer trois niveaux.
Le premier niveau, ce sont les identifiants humains. Les comptes WordPress (admins, éditeurs, auteurs) et leurs mots de passe. C’est le plus évident, mais aussi le plus incomplet si l’attaquant a utilisé des sessions déjà actives, des outils de persistance, ou des connexions à des services externes.
Le deuxième niveau, ce sont les secrets techniques côté WordPress. Le couple clé/salt (les “salts” dans wp-config.php) fait partie des mécanismes qui signent des cookies et jetons. Si un attaquant a pu voler des sessions ou générer des cookies, changer ces valeurs peut invalider des accès qui ne seraient plus valides autrement.
Le troisième niveau, ce sont les tokens et identifiants “hors WordPress”. API de paiement, webhooks, jetons OAuth, clés de plugins, clés de services d’hébergement, connexions à un CDN, identifiants utilisés par des scripts, ou des accès à l’administration du serveur.
Dans les incidents “classiques” de compromission, l’attaquant peut viser un ou plusieurs niveaux. D’où l’intérêt d’une approche progressive, et non d’une simple rotation du mot de passe admin.
Repartir sur une base saine: vérifier ce qui reste vraiment
Avant même de modifier des secrets, prenez deux minutes pour confirmer que le nettoyage a retiré https://gardewp.fr/nettoyage-malware-wordpress/ la cause, pas seulement le symptôme.
Si vous avez restauré à partir d’une sauvegarde saine, c’est déjà une bonne protection. Mais la rotation de secrets reste utile, car l’attaquant peut avoir laissé des traces ailleurs: dans les tables de la base, dans une configuration chargée dynamiquement, ou dans les paramètres d’intégration (webhooks, API keys) qui n’apparaissent pas en parcourant simplement le code des thèmes.
Concrètement, après nettoyage, j’aime faire trois contrôles avant de “casser” des sessions.
D’abord, vérifier que wp-config.php n’a pas été modifié, et que les clés/salts n’ont pas été remplacées par des valeurs suspectes ou exfiltrées. Ensuite, regarder la liste des utilisateurs: présence d’utilisateurs inattendus, rôles anormaux, dates de création. Enfin, vérifier les plugins actifs et leurs versions, surtout si vous avez eu une extension qui a créé des backdoors, ou un plugin de “secours” avec un nom banal.
Ces contrôles ne remplacent pas une analyse, mais ils évitent de tourner des secrets alors que le site n’est pas encore stable.
Changer les mots de passe WordPress: le minimum, mais pas le seul geste
Changer les mots de passe, c’est le premier levier. Dans une situation post-compromission, je conseille de changer les mots de passe de tous les utilisateurs ayant accès à l’administration, pas seulement l’admin principal.
Un piège fréquent: l’attaquant crée un compte “discret” avec un rôle équivalent, ou reprend un utilisateur existant. Si vous changez uniquement le mot de passe du compte principal, le compte secondaire peut rester opérationnel, via une session active ou via un jeton conservé ailleurs.
Selon vos contraintes, vous pouvez aussi envisager de révoquer temporairement les comptes non indispensables. Par exemple, si vous avez des auteurs qui publient rarement, vous pouvez les laisser de côté le temps de verrouiller l’accès et de vérifier les logs.
Ce qui mérite une rotation immédiate
La rotation doit inclure au moins les mots de passe de:
- les comptes WordPress au rôle élevé, les comptes techniques utilisés pour déployer des contenus ou accéder à l’interface, et, si vous avez une authentification “par application” ou des API, les clés associées.
Si vous utilisez l’authentification par navigateur (sessions web), le changement de mot de passe seul ne suffit pas toujours. Selon la façon dont la session a été établie, l’accès peut persister jusqu’à expiration, ou jusqu’à invalidation par les mécanismes de cookies. C’est là que le changement des salts et l’invalidation des sessions deviennent importants.
Modifier les clés et salts dans wp-config.php pour invalider des sessions
Dans WordPress, les clés secrètes (les “auth keys” et “secure auth keys”) et les sels associés servent à signer les cookies. Quand vous les changez, WordPress invalide les sessions existantes basées sur ces cookies.
Après un nettoyage, c’est souvent l’un des gestes les plus efficaces pour couper un accès persistant, même si l’attaquant avait utilisé un navigateur compromis, ou volé des cookies. Ce n’est pas une garantie universelle contre toutes les formes de persistance, mais c’est une mesure solide, peu risquée si elle est anticipée.
Le point d’attention est simple: comme ces cookies sont invalidés, vous allez déconnecter les utilisateurs connectés. Les administrateurs devront se reconnecter, et certains plugins peuvent demander une reconnexion si l’intégration dépend de sessions.
Procédure pratique
Vous modifiez les lignes de type AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs équivalents _SALT. Dans wp-config.php, vous remplacez l’ensemble par de nouvelles valeurs.
Pour éviter les erreurs, je recommande d’utiliser un générateur de clés prévu pour WordPress, puis de copier le bloc complet. Les valeurs ne doivent pas être réutilisées ailleurs, et elles doivent rester gardées secrètes.
Révoquer les sessions et nettoyer ce qui reste côté navigateur
Au-delà des salts, il peut exister des sessions dans des couches externes.
Si vous avez un pare-feu applicatif, un CDN, ou un cache dynamique, il peut y avoir des cookies conservés ou des sessions “collées” sur un chemin spécifique. Par exemple, Cloudflare ou un équivalent peut conserver des états de session côté navigateur, selon les paramètres de configuration.
Je fais en général deux choses dans les jours qui suivent la rotation: 1) je déconnecte tout le monde côté WordPress via les salts, 2) puis je purge les caches pertinents si le site en utilise, surtout les caches de pages qui contiennent potentiellement des variantes.
Si vous ne gérez pas vous-même le CDN ou le reverse proxy, demandez à l’hébergeur. La purge peut être simple, mais ce n’est pas toujours automatique.
Tokens et identifiants WordPress “non évidents”: ceux qu’on oublie
Beaucoup d’interventions post-infection se limitent à “changer le mot de passe admin et les plugins”. Or, dans WordPress moderne, des tokens se trouvent partout.
Les mots de passe d’applications (si utilisés)
Si vous utilisez des fonctionnalités qui génèrent des identifiants d’application, ils peuvent être compromis. Les mots de passe d’applications sont souvent créés pour des clients API, des outils de déploiement, ou des services de synchronisation. Après incident, l’approche raisonnable est de les supprimer puis de les recréer, car vous ne pouvez pas prouver que l’ancien secret n’a pas été intercepté.
Le risque n’est pas théorique. J’ai déjà vu des compromissions où la page de connexion avait été modifiée, mais où surtout un compte technique continuait à faire des appels API, ce qui donnait une persistance après la suppression du code visible.
Les jetons OAuth et webhooks
Si vous avez des plugins qui se connectent à des services via OAuth, ou qui utilisent des webhooks avec des signatures, ces tokens peuvent aussi avoir été exposés. Après nettoyage, il faut couper les accès côté fournisseur si possible, puis rebrancher.
Là, l’arbitrage dépend de votre budget opérationnel. Reconfigurer un intégrateur de paiement, une synchronisation SEO, un outil de marketing, ou un connecteur de formulaires peut prendre du temps. Mais laisser un token potentiellement compromis est souvent plus risqué que de refaire la configuration.
Dans la pratique, je traite en priorité les intégrations qui permettent:
- d’envoyer des requêtes depuis votre site vers l’extérieur, ou de récupérer des données sensibles depuis l’extérieur, ou de déclencher des actions à distance (création d’événements, publication, modifications).
Les clés de plugins et services
Certains plugins stockent des API keys, des secret tokens, ou des identifiants dans les options WordPress. Même si le plugin est “clean”, ces valeurs peuvent rester. Si vous avez suspecté un accès à la base, il faut considérer une rotation.
Un exemple concret: un plugin de cache externe ou un outil d’optimisation peut stocker des identifiants d’API. Si ces identifiants permettent de purger le cache ou modifier des pages, ils deviennent une surface d’attaque indirecte.
Mettre à jour les identifiants de base de données et les accès serveur
Quand l’attaque a touché le site, elle touche parfois aussi les accès d’administration au serveur. Même si vous n’avez pas de preuve, vous devez juger la probabilité.
Si votre hébergeur vous permet de modifier le mot de passe MySQL, c’est une rotation cohérente après nettoyage, surtout si l’attaquant a eu des possibilités d’exécution de commande ou de lecture des fichiers de configuration.
Le cas classique: l’attaquant injecte une petite portion de code qui affiche ou exfiltre des variables d’environnement, ou qui lit des fichiers locaux. Si ça a été possible, une rotation des identifiants DB devient logique.
Mais il faut aussi rester pragmatique: changer la base de données sans nécessité peut casser des scripts, des sauvegardes automatisées, ou des connecteurs. La règle que j’utilise est simple: si vous avez un accès de confiance pour la rotation, faites-le. Si vous n’avez pas de confirmation que l’attaquant a pu accéder à la configuration, vous pouvez limiter le risque en changeant au moins les secrets applicatifs côté WordPress (salts) et les mots de passe admin, puis en surveillant.
Une checklist ciblée juste après nettoyage
Plutôt que d’énumérer tout, je préfère vous donner une checklist courte, orientée “couper la persistance”. Si votre objectif est de répondre à “comment changer identifiants et tokens après un nettoyage WordPress”, voici les actions qui couvrent la majorité des scénarios.
- Changer les mots de passe de tous les comptes WordPress avec rôle admin ou accès à l’édition. Remplacer entièrement les clés et salts dans wp-config.php pour invalider les cookies et sessions. Révoquer et recréer les mots de passe d’application et tokens de plugins qui parlent à des API externes. Vérifier et supprimer les utilisateurs créés après la date du nettoyage ou avant que vous ayez commencé la purge.
Cette liste fait gagner du temps, mais elle n’est pas exhaustive pour les cas complexes.
Réparer le “chemin de retour” sans casser vos intégrations
Une fois que vous changez salts, mots de passe, tokens, vous risquez de casser des flux. Ce n’est pas un défaut, c’est souvent le but: forcer tous les accès à repasser par une configuration saine.
Le point délicat, c’est de ne pas réintroduire des secrets dans un état instable.
Par exemple, si vous changez les tokens de plusieurs services, faites-le de façon séquentielle:
- d’abord côté WordPress (salts, comptes), ensuite côté intégrations externes (webhooks, OAuth), puis enfin côté automatisations.
Sinon, si quelque chose casse, vous ne savez pas où chercher, et les logs deviennent difficiles à lire.
J’ai déjà vu des équipes changer cinq tokens la même journée, puis découvrir un incident de paiement ou une suppression de synchronisation. Elles ont fini par inverser les changements dans le désordre, ce qui a créé une “période de brouillard” de plusieurs heures. Dans une enquête, la clarté vaut presque autant que la sécurité.
Surveiller les logs après rotation, au lieu de supposer que tout est fini
Après rotation d’identifiants et tokens, la bonne attitude consiste à surveiller pendant quelques jours. Même si vous n’avez pas de métriques parfaites, regardez les indices.
Les signaux utiles sont:
- tentatives de connexion répétées, erreurs d’autorisation (403, 401) sur des endpoints, accès à des fichiers inhabituels, et activités de création ou modification d’articles après votre fenêtre de contrôle.
Selon votre configuration, vous pouvez avoir des logs côté WordPress, côté serveur, ou via un plugin de sécurité. Sans inventer de “meilleures pratiques” générales, je dirais simplement que vous avez besoin d’un endroit où lire “qui a tenté quoi, quand, et depuis où”.
Une approche pragmatique consiste à définir une petite période de surveillance active, puis à réduire après stabilisation.
Cas particuliers: cache, reverse proxy, et sessions qui semblent “revivre”
Il arrive qu’après avoir changé salts, un utilisateur se dise “je suis toujours connecté”. Souvent, ce n’est pas une erreur de WordPress, mais une illusion de cache.
Quelques raisons courantes:
- un navigateur conserve un cookie sur un sous-domaine séparé, un site utilise une URL différente (http versus https, ou variations de chemin) où les cookies se distinguent, un reverse proxy duplique des sessions ou applique des règles de cache qui masquent le comportement, ou le navigateur utilise un service de synchronisation de cookies.
Dans ces cas, j’agis comme suit: je teste avec une session “incognito” sur une autre machine. Si la reconnexion arrive correctement en incognito, le problème est surtout côté navigateur ou côté cookies partitionnés, pas côté WordPress.
Ce test simple est souvent plus rapide que de multiplier les hypothèses.
Réorganiser l’accès aux comptes et réduire la surface pendant la période de rétablissement
Après un incident, il est tentant de “remettre en ligne” sans trop de friction. Mais si vous avez l’occasion, vous pouvez réduire la surface d’attaque pendant une fenêtre de rétablissement.
Je ne parle pas d’une procédure lourde. Je parle de mesures de bon sens, alignées sur ce que les attaquants cherchent:
- retirer temporairement les comptes qui ne sont pas nécessaires, limiter le nombre de personnes avec accès admin, et exiger une MFA si vous en disposez (si ce n’est pas possible rapidement, au moins renforcissez la politique de mots de passe et le filtrage IP).
Cette étape n’est pas obligatoire dans tous les cas, mais elle réduit le risque de “recompromission” pendant que vous recâblez les tokens et que vous vérifiez les intégrations.
Savoir où chercher si des tokens semblent encore valides
Si vous avez changé salts et mots de passe, mais que des actions continuent à être effectuées, l’enquête doit être orientée sur la source.
Les pistes les plus fréquentes, sans prétendre à l’universalité, sont:
- un jeton resté actif côté service tiers (webhook ou API), un compte non identifié (utilisateur créé, rôle élevé), un script sur le serveur qui utilise un secret stocké quelque part, ou un plugin qui contient encore un mécanisme de persistance invisible, même si le thème a l’air propre.
Dans ce contexte, un retour en arrière complet n’est pas toujours la meilleure décision. Souvent, la rotation ciblée des tokens et la recherche d’actions automatiques sont plus efficaces que de “tout restaurer encore une fois”.
Mini plan de validation après changement
Une fois que vous avez remplacé les secrets et reconnecté les intégrations, il faut valider, sans tout tester pendant deux jours.
Voici une petite séquence qui m’aide à trier vite les problèmes:
- Ouvrir le back-office avec un navigateur “neuf” et vérifier que les sessions expirent correctement. Vérifier les plugins critiques qui utilisent des API (formulaires, paiement, newsletter, analytics) et confirmer qu’ils fonctionnent après reconnexion. Surveiller les tentatives de connexion et les erreurs de droits pendant 24 à 72 heures.
Si ces trois points sont propres, vous êtes généralement sur une trajectoire saine.
Gérer la complexité: quand changer trop casse votre exploitation
Il y a un moment où le “tout rotation” devient contre-productif. Par exemple, dans un site e-commerce avec beaucoup d’intégrations, la rotation de chaque token peut provoquer une cascade d’échecs.
Dans ces cas, je conseille de prioriser. Priorité aux secrets qui donnent la capacité d’action la plus directe:
- authentification vers WordPress, tokens d’édition ou de publication, webhooks capables de déclencher des modifications, identifiants API utilisés par des automatisations d’administration.
Ensuite seulement, vous faites la rotation du reste si vous avez des raisons de penser que la base de secrets a été exposée. Le bon jugement vient de la nature de l’incident et de votre niveau d’accès aux preuves.
Si vous avez seulement “nettoyer site WordPress infecté” au sens strict, sans compromission serveur documentée, l’effort doit viser d’abord WordPress et les intégrations où des tokens ont été utilisés depuis votre site.
Si au contraire vous suspectez une compromission plus profonde, alors la rotation DB et les secrets serveur devient plus pertinente.
Ne pas oublier l’après, les habitudes qui évitent de retomber dedans
Après un nettoyage, beaucoup d’équipes font les actions de sécurité une fois, puis se relâchent. Le problème, c’est que les erreurs initiales reviennent souvent: mot de passe faible, plugin non maintenu, intégration OAuth mal gérée, ou permissions trop larges.
Sans faire de “grand discours”, les habitudes qui protègent le plus à long terme sont celles qui rendent la compromission plus difficile et la détection plus rapide:
- garder WordPress, thèmes et plugins à jour, réduire les privilèges des comptes, limiter les plugins à ceux qui sont utiles, et surveiller les logs d’accès.
Ces mesures ne remplacent pas le nettoyage, elles évitent surtout de devoir recommencer.
Questions fréquentes qui reviennent après nettoyage
Beaucoup de lecteurs me demandent deux points.
Le premier: “Dois-je changer tous les mots de passe, même ceux des comptes qui ne se connectent jamais?” Si ces comptes ont un rôle élevé ou un accès admin, oui, dans une logique d’éradication des persistance. Si ce sont des comptes purement techniques qui ne servent pas à l’administration, le risque dépend des tokens qu’ils utilisent.
Le deuxième: “Changer les salts suffit-il?” Souvent, c’est un geste majeur, mais il n’élimine pas forcément un token externe, ni une intégration qui continue à agir. Si votre incident a impliqué des appels automatiques via plugins ou des webhooks, la rotation des tokens côté fournisseurs reste la vraie différence entre “on a stoppé le symptôme” et “on a réellement neutralisé l’accès”.
Si vous me donnez votre contexte (types d’intégrations, hébergeur ou présence d’un CDN, méthode de nettoyage utilisée, et si vous avez restauré une sauvegarde ou fait un nettoyage sur place), je peux vous proposer une stratégie de rotation plus ciblée, avec l’ordre des opérations le plus logique pour éviter les pannes de dernière minute.