Quand un site WordPress est compromis, on a souvent l’impression de courir après quelque chose d’insaisissable. Le navigateur affiche une page étrange, la recherche Google commence à signaler des contenus non souhaités, des comptes utilisateurs tentent de se connecter depuis des adresses inconnues, et dans le back-office, tout semble “encore fonctionner”. Puis on découvre l’horreur habituelle: des fichiers modifiés, des extensions inutiles, parfois un hébergement détourné, et surtout, des sessions qui restent valides alors même que vous avez “nettoyé” le thème ou supprimé le plugin fautif.
Dans ce genre de situation, renforcer wp-config.php et refaire proprement les clés de sécurité n’est pas un détail. C’est un levier direct pour casser des sessions et invalider des mécanismes d’authentification basés sur des secrets. Dit autrement: même si vous supprimez la porte d’entrée, l’assaillant peut parfois rester “loggé” pendant un moment. Les bonnes clés changées au bon moment réduisent cette fenêtre.
Ce qui suit vise un objectif concret: vous aider à nettoyer site WordPress infecté, tout en rendant la prochaine phase de l’incident moins confortable pour l’attaquant.
Pourquoi wp-config.php devient le point de bascule
Le fichier wp-config.php est le cerveau minimal de WordPress. Il contient des identifiants de base de données, du préfixe de tables, des paramètres de mode (debug ou non), des choix de compatibilité, et, point crucial pour la sécurité, des clés et sels utilisés pour signer et sécuriser plusieurs étapes d’authentification.
Ces clés sont généralement définies sous forme de constantes, par exemple AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, et leurs équivalents “SECURE AUTHSALT”, “AUTH_SALT”, etc. Elles servent à empêcher des attaques de type falsification de session, et à rendre beaucoup plus difficile la réutilisation de valeurs interceptées.
Quand un site est infecté, il arrive que l’attaquant ne se contente pas de modifier des fichiers. Il peut aussi tenter de garder un accès persistant, via:
- une session active maintenue, un compte administrateur créé, un mécanisme d’authentification exploitant des secrets déjà en place, ou un plugin qui réécrit à chaque visite les “bons” fichiers, pour que vous perdiez du temps.
Changer les clés ne remplace pas un nettoyage complet, mais c’est un geste de “coupure” très efficace pour invalider l’existant.
Avant de toucher aux clés: le bon timing
Un piège courant consiste à modifier wp-config.php trop tôt, puis à se retrouver bloqué pendant la récupération, parce que l’on a simultanément supprimé des éléments qui assuraient le diagnostic.
En pratique, je conseille de raisonner en deux temps:
Réduire la surface d’attaque et confirmer ce qui a été modifié. Casser la persistance (sessions, nonces) via la rotation des clés, puis verrouiller les paramètres critiques.Le timing exact dépend de ce que vous observez. Si vous voyez des tentatives répétées d’accès au moment où vous travaillez, la rotation des clés après suppression des entrées évidentes vous offre un meilleur résultat. Si au contraire l’accès est déjà perdu, une restauration à partir d’une sauvegarde propre devient prioritaire.
Je garde aussi en tête un détail pragmatique: la rotation des clés peut vous faire déconnecter vous-même et vos utilisateurs. Dans un site d’équipe, ça peut générer des appels au support. Sur un site public, c’est acceptable. Sur un site avec un back-office très utilisé, prévenez les personnes concernées.
Étape de nettoyage: vérifier ce qui a été changé, pas seulement ce qui “semble” cassé
Nettoyer un WordPress infecté ne se résume pas à supprimer un plugin. Parfois, l’extension “coupable” n’est qu’un relais, parfois ce sont des thèmes ou des fichiers au mauvais endroit.
Sans transformer ça en mode “recette”, l’idée est simple: vous cherchez les modifications récentes, les fichiers ajoutés, et les endroits où WordPress relaye des comportements inattendus.
Concrètement, inspectez:
- les fichiers PHP du thème et des dossiers de plugins, le dossier des uploads (images, mais aussi scripts qui s’y glissent parfois), les fichiers racine et ceux autour de wp-config.php et de wp-admin/ et wp-includes/.
Un repère utile, sans être une règle absolue, est la cohérence des dates. Sur un site stable, les temps de modification des fichiers core devraient être identiques ou proches lors de déploiements. Si soudain vous voyez des fichiers PHP core ou des fichiers d’apparence standard modifiés “hier”, c’est un signal.
J’ai https://gardewp.fr/ déjà vu des cas où wp-config.php semblait intact visuellement, mais où un chemin d’inclusion avait été injecté via une petite modification de ligne. C’est souvent discret, et c’est précisément pour ça que vous devez comparer au contenu d’une version connue (sauvegarde saine, ou modèle de wp-config.php correspondant à votre installation).
Renforcer wp-config.php: les paramètres qui réduisent vraiment les marges
Une fois le diagnostic fait et les fichiers manifestement malveillants retirés (ou, si nécessaire, après restauration d’une sauvegarde propre), vous pouvez renforcer wp-config.php.
L’objectif n’est pas de “tout verrouiller” au risque de casser votre environnement. Il s’agit de limiter les vecteurs d’accès les plus fréquents, ceux qui transforment une compromission en persistance.
Garder wp-config.php le plus sobre possible
Le pire scénario est d’avoir un wp-config.php rempli de bricolages hérités d’anciens tutos, de snippets ajoutés sans justification, ou de modes debug oubliés. Un WP_DEBUG activé en production n’est pas une porte en soi, mais ça donne des informations utiles à un attaquant, notamment sur la structure interne.
Si vous avez le moindre doute, partez du principe suivant: en production, WP_DEBUG doit être désactivé. Si vous devez diagnostiquer, faites-le temporairement, le temps de capturer un problème précis, puis repassez en mode sécurisé.
Renforcer les restrictions sur l’édition depuis l’interface
WordPress permet, dans certaines configurations, de modifier des fichiers via l’interface d’administration. Même si l’attaque initiale passe par autre chose, une capacité de modification côté navigateur peut aider à maintenir le contrôle.
Dans wp-config.php, vous pouvez ajouter des constantes qui empêchent l’édition et la modification de certains éléments via l’admin. L’idée est de supprimer un levier utile, pas de “verrouiller tout WordPress”. Selon votre configuration et votre méthode de déploiement (FTP, SSH, pipeline CI/CD), vous devrez adapter.
Si vous avez une équipe qui modifie des fichiers directement depuis l’interface, vous devrez planifier une alternative. Sinon, vous réduisez un vecteur courant.
Vérifier le préfixe des tables
Le préfixe de tables ($table_prefix) n’est pas un secret absolu, mais un préfixe par défaut augmente le bruit dans certains traitements automatisés. Un préfixe unique aide à réduire les correspondances évidentes.
Si vous n’êtes pas sûr, comparez: sur une installation fraîche, vous avez souvent wp_, sur une installation “sûre”, vous avez un préfixe plus atypique. Attention, changer le préfixe en cours d’incident peut devenir délicat, surtout si vos scripts ou vos thèmes s’y réfèrent. C’est plutôt un changement de durcissement planifié qu’une manœuvre improvisée pendant la crise.
S’assurer que les valeurs sensibles ne sont pas visibles ou manipulées
Un bon wp-config.php ne doit pas être accessible publiquement. Selon votre hébergement, une règle de type blocage d’accès au fichier au niveau serveur doit exister. Même si ce point ne relève pas directement de wp-config.php, l’incident montre souvent des configurations trop permissives.
Autre point: si vous utilisez des variables d’environnement pour la base de données et que vous vous appuyez sur wp-config.php minimal, assurez-vous que ces valeurs ne sont pas contournées ou réécrites par un script.
Les clés de sécurité: changer, et surtout savoir ce que vous changez
Passons au cœur du sujet. Dans wp-config.php, les clés de sécurité ressemblent à ceci (noms de constantes typiques):
- AUTH_KEY SECURE_AUTH_KEY LOGGED_IN_KEY NONCE_KEY AUTH_SALT SECURE_AUTH_SALT LOGGED_IN_SALT NONCE_SALT
Le rôle est de fournir des secrets aléatoires. La qualité de la sécurité dépend directement de l’imprévisibilité de ces valeurs.
Pourquoi les changer après une infection
Si l’attaquant a eu accès à wp-config.php ou à des valeurs utiles pour générer des éléments d’authentification, garder vos anciennes clés revient à conserver un avantage involontaire. En modifiant ces clés, vous invalidez des éléments liés aux sessions et aux nonces.
Vous pouvez voir un effet immédiat: vous êtes déconnecté, le back-office demande une reconnexion, des utilisateurs doivent revalider. C’est une conséquence attendue et souhaitable après une compromission.
J’ai déjà vu des scénarios où, après suppression de plugins malveillants, l’attaquant continuait à publier du contenu car une session administrateur était toujours active. Le changement des clés a stoppé net cette persistance.
Comment choisir le moment exact de la rotation
En pratique, je fais la rotation des clés après:
- restauration d’une base saine ou au minimum suppression des fichiers modifiés, retrait des scripts qui pourraient réinjecter des valeurs, vérification rapide que wp-config.php n’est pas modifié au chargement.
Si un malware est encore en place et qu’il réécrit wp-config.php à la première minute, changer les clés peut donner l’impression d’avoir “réparé”, alors que le problème revient. Pour éviter ça, vous devez aussi comprendre ce qui modifie le fichier: script de déploiement compromis, tâche planifiée, plugin persistant, ou accès non bloqué au niveau hébergement.
Exemple concret d’incident et ce que les clés ont changé
Je me souviens d’un site vitrine qui “devenait” lent pendant certains créneaux. Le symptôme ne ressemblait pas à une redirection visible, plutôt à des chargements supplémentaires et à quelques incohérences dans les pages. En inspectant les plugins, on trouvait un ajout discret, pas forcément mal nommé.
Le nettoyage a été fait, et la plupart des pages ont retrouvé un comportement normal. Pourtant, un jour plus tard, un utilisateur admin recevait encore des tentatives de modification sur des articles qu’il n’avait pas touchés. Le back-office affichait “on dirait que quelqu’un s’est connecté”. Pas d’alerte de sécurité claire côté serveur, juste l’activité.
La rotation des clés de sécurité a eu un impact immédiatement visible: déconnexion forcée et blocage du comportement résiduel. Cela ne rend pas inutile la recherche de l’origine, mais ça a supprimé la persistance de session. Ensuite, on a pu corriger le point d’entrée, sans courir derrière un accès “fantôme”.
Ce genre de vécu explique pourquoi, dans ma procédure, les clés de sécurité ne sont pas un “bonus”. Elles sont une phase de récupération.
Modifier wp-config.php: méthode pratique sans se tirer une balle dans le pied
Selon votre accès, vous modifierez le fichier via un client FTP, via un accès SSH, ou via l’interface de votre hébergeur.
Quelques règles simples évitent 90 pour cent des erreurs:
- faites une sauvegarde du wp-config.php existant avant tout changement, modifiez les valeurs une seule fois, sans “aller et retour” pendant la même fenêtre de crise, gardez une version propre en local, surtout si vous devez revenir en arrière.
Une partie de la sécurité, c’est aussi la fiabilité de votre opération. Si vous devez corriger une faute de syntaxe PHP, un fichier illisible peut rendre tout le site injoignable, ce qui complique la suite.
Ce que vous devez viser pendant la rotation des clés
- Utiliser des valeurs aléatoires et longues. Ne pas réutiliser des valeurs vues ailleurs. Ne pas réintroduire des anciennes valeurs par erreur.
La bonne nouvelle, c’est que WordPress prévoit une génération dédiée des clés. L’idée n’est pas de “deviner” des secrets robustes, l’idée est d’obtenir des valeurs aléatoires solides.
Voici un mini cadre de décision, utile quand vous gérez une équipe ou un prestataire:
Faites la rotation après coupure des vecteurs évidents (fichiers malveillants supprimés, accès incriminés retirés). Testez l’accès admin et la connexion des utilisateurs clés. Surveillez les logs pendant quelques heures, puis à nouveau le lendemain. Si vous observez une réécriture de wp-config.php, cherchez le mécanisme qui persiste. Conservez votre ancienne version chiffrée ou protégée, le temps d’une vérification interne.(Et oui, vous pouvez rencontrer le cas où votre prestataire a “roté” les clés mais sans supprimer le vecteur, ce qui donne l’impression que “ça n’a rien changé”. Dans ce cas, il faut remonter un cran.)
Verrouiller après les clés: éviter que la même compromission se répète
Changer les clés est une action de récupération, mais ce n’est pas une stratégie de prévention complète. L’attaquant cherche ensuite une nouvelle porte: un autre plugin vulnérable, un thème qui accepte des entrées non contrôlées, un identifiant faible, une configuration de serveur trop permissive, ou une faille d’accès.
Côté wp-config.php, vous pouvez aussi réduire le champ des erreurs accidentelles:
- assurer que le mode debug est désactivé en production, éviter les options d’extension en production qui exposent trop, limiter les capacités d’édition depuis l’interface si vous ne l’utilisez pas.
Côté accès, je traite séparément la sécurité des comptes, car c’est souvent là que l’incident se prolonge. Un mot https://gardewp.fr/nettoyage-malware-wordpress/ de passe réutilisé, une session “admin” qui revient, ou une adresse email compromise dans une autre fuite, et vous êtes de nouveau en train de nettoyer.
Vous pouvez aussi activer une rotation des identifiants et forcer une reconnexion globale, mais le point clé ici reste la rotation des clés, car elle casse l’existant à un niveau bas.
Edge cases: quand changer les clés pose un problème
Il y a des situations où la rotation des clés n’est pas “gratuite”:
- Si vous avez un plugin de type “auth externe” ou un système d’auth custom qui stocke des valeurs dans la session, vous verrez parfois des erreurs le temps que les utilisateurs revalident. Si vous avez plusieurs environnements (staging et production) et que vos configurations sont copiées, vous risquez de confondre les clés entre environnements. Dans ce cas, vous dégradez la logique de récupération ou vous rendez le débogage plus pénible. Si le fichier wp-config.php est modifié automatiquement par un script (déploiement mal configuré), vos changements peuvent être écrasés.
Le remède est pragmatique: documenter votre procédure, vérifier le pipeline de déploiement, et garder des sauvegardes. Si vous gérez un staging, gardez des clés différentes entre staging et production.
Vérifications rapides après modification (sans perdre trop de temps)
Après modification de wp-config.php, vous voulez être sûr que le site fonctionne et que la sécurité a bien été “poussée” dans le bon sens.
Je fais généralement une série courte de contrôles:
- vérification de la page d’accueil et d’une page interne, connexion admin (un compte test, idéalement), vérification du comportement des formulaires critiques si votre site en a, observation des logs serveur et des logs applicatifs sur les heures qui suivent.
Si vous voyez des erreurs PHP immédiatement, c’est souvent une erreur de syntaxe ou un guillemet mal placé. Si vous voyez des tentatives de connexion incessantes, c’est qu’il faut traiter aussi le vecteur d’accès, pas uniquement la session.
Liste pratique: rotation des clés et sels, ce qu’il faut faire (et ne pas faire)
Voici une liste courte, orientée opération, parce que c’est là que les erreurs se produisent le plus souvent.
- Sauvegardez wp-config.php avant toute modification. Remplacez toutes les constantes de clés et sels, pas seulement une partie. Utilisez des valeurs générées de manière aléatoire, pas des “chaînes” faciles à deviner. Faites la rotation après avoir retiré le point de persistance principal. Surveillez la reconnexion des utilisateurs et les tentatives dans les logs pendant la période critique.
Cette séquence réduit la probabilité d’un “faux sentiment de sécurité”.
Et si wp-config.php a été modifié par l’attaquant?
C’est un scénario réel. Les attaquants cherchent parfois à détourner la logique. Ils peuvent modifier:
- des chemins, des constantes de configuration, ou introduire une inclusion silencieuse.
Si vous suspectez une modification malveillante, la bonne approche est de ne pas “corriger au feeling”. Comparez wp-config.php à une version saine, même approximative, puis vérifiez les écarts.
Si vous n’avez pas de version saine sous la main, restaurer à partir d’une sauvegarde propre est souvent plus rapide que de reconstruire manuellement un fichier fragile, surtout en pleine crise.
Renforcer la suite: décisions qui comptent plus que quelques lignes PHP
On peut passer deux heures à ajuster des constantes, et rater l’essentiel: un accès valide à un compte, une faille dans un plugin, ou un fichier réinjecté.
Une stratégie qui tient en conditions réelles ressemble à ceci:
- nettoyage et suppression du vecteur, rotation des clés, durcissement minimal, sécurisation des comptes, suivi dans le temps.
Ce dernier point est important. Un site “réparé” trop tôt peut se réinfecter le lendemain, pas forcément immédiatement.
Résumé opérationnel
Si vous êtes en train de nettoyer site WordPress infecté, pensez à wp-config.php comme à une bascule entre “il reste des traces exploitables” et “on coupe l’accès actuel”.
La rotation des clés de sécurité et des sels est un moyen direct de forcer une reconnexion et d’invalider des mécanismes liés aux sessions et aux nonces. Renforcer ensuite wp-config.php avec des paramètres prudents, désactiver le debug en production, et limiter les capacités inutiles depuis l’interface admin réduit les chances de persistance.
Le plus dur dans ce type d’incident n’est pas de trouver une ligne à changer. C’est d’aligner le bon ordre, pour que vos actions ne soient pas écrasées par un mécanisme encore actif.
Liste courte pour les prochaines actions
Si vous voulez une séquence immédiate à exécuter aujourd’hui, en restant réaliste, voici l’essentiel:
- Identifiez ce qui a été modifié dans les fichiers et retirez la persistance. Sauvegardez wp-config.php, puis mettez à jour les clés et sels. Vérifiez que le site et l’accès admin fonctionnent, avec surveillance dans les heures qui suivent. Vérifiez ensuite que rien ne réécrit wp-config.php automatiquement.
Si vous me décrivez votre contexte (hébergement, symptômes, ce que vous avez déjà supprimé, et si vous avez une sauvegarde propre), je peux vous proposer une stratégie de durcissement plus ciblée, avec les choix les plus prudents pour éviter les effets de bord.