Quand une intrusion touche WordPress, on pense souvent au site “visible”, au thème, aux pages déformées, aux redirections ou aux messages d’admin impossibles à modifier. Pourtant, dans beaucoup d’incidents que j’ai vus, le nœud du problème se trouve ailleurs: la configuration. Plus précisément, le fichier wp-config.php. C’est lui qui tient les clés, littéralement. Si un attaquant a pu lire ou modifier ce fichier, il ne s’est pas contenté de déposer un malware, il a souvent tenté de garder un accès durable, de récupérer des identifiants, ou d’ouvrir des portes invisibles.
L’objectif de cette lecture est simple et très concret: comprendre ce qu’il faut vérifier après une intrusion, comment mener une désinfection propre, puis comment sécuriser wp-config.php pour que l’attaquant ne revienne pas par la même entrée. Ce n’est pas un guide “magique” qui fait disparaître tous les risques en une commande, c’est une démarche de terrain, avec des choix, des compromis, et des pièges récurrents.
Pourquoi wp-config.php devient le point faible après une intrusion
wp-config.php contient des éléments que WordPress n’a aucune raison de partager avec le monde. On y trouve notamment la base de données (nom, identifiants), parfois des clés et saltes d’authentification, ainsi que d’autres directives qui influencent l’exécution. En clair, si un attaquant a compromis ce fichier, il peut:
- se connecter à la base de données et modifier des options, des comptes, ou des règles d’accès, injecter du code qui s’exécute à chaque chargement d’une page, manipuler l’authentification en changeant des constantes de sécurité, mettre en place une persistance en modifiant aussi des fichiers connexes, comme des fichiers dans le répertoire des plugins ou dans certaines zones d’upload.
Le détail le plus trompeur, c’est que le site peut avoir l’air “normal” après coup. Vous supprimez le plugin malveillant, vous réinitialisez le mot de passe admin, et quelques heures plus tard, un compte réapparaît, ou bien des redirections se déclenchent sur certaines pages. Dans ces cas-là, wp-config.php est souvent une pièce centrale du puzzle.
Les premiers signaux à prendre au sérieux, avant de toucher aux fichiers
Avant d’éditer quoi que ce soit, il faut stabiliser la situation. Sur un site compromis, chaque action peut aggraver l’exécution du code malveillant. J’ai déjà vu des cas où des “nettoyages” en panique ont déclenché des scripts de persistance, parce que l’attaquant surveillait justement les moments où l’on modifiait certains fichiers.
Les signaux typiques incluent:
La présence de lignes inhabituelles dans wp-config.php (par exemple des inclusions de fichiers PHP externes, des eval, des appels à des fonctions de chargement dynamique, ou des chemins vers des scripts dans des répertoires d’upload).
Des modifications d’horodatage récentes sur plusieurs fichiers en même temps, au-delà de ce que vous avez fait.
Des événements dans les logs d’accès web montrant des requêtes répétées vers des endpoints bizarres, ou des tentatives de chargement de fichiers non liés à votre fonctionnement.
Des comptes WordPress ou des rôles inattendus dans l’interface d’administration, même après changement de mots de passe.
À ce stade, la bonne approche consiste à basculer vers un mode “enquête”. On fige l’environnement si possible (sauvegardes, copie des fichiers, relevé d’éléments), puis on passe à la désinfection.
Mettre le site en sécurité pendant la désinfection
La plupart des hébergeurs permettent un mode maintenance, mais ce n’est pas uniquement pour l’expérience utilisateur. C’est aussi pour réduire le trafic pendant que vous analysez.
Deux décisions pratiques reviennent souvent:
Première décision: isolez l’accès à l’administration. Si vous pouvez limiter l’accès à wp-admin et wp-login par IP ou par un mécanisme de filtrage temporaire au niveau serveur, faites-le. Si ce n’est pas possible, au moins limitez l’accès via des identifiants spécifiques et évitez de vous reconnecter en continu.
Deuxième décision: gardez un état de référence. Copiez wp-config.php, puis copiez aussi les fichiers modifiés ou suspects. Si vous devez comparer, c’est bien plus efficace avec des copies datées qu’avec un dossier “en cours de nettoyage”.
Je recommande de travailler sur une copie du site quand c’est envisageable, sinon de procéder par étapes très contrôlées.
Désinfection WordPress: démarche pragmatique, centrée sur la configuration
Une désinfection sérieuse ne se limite pas à remplacer des fichiers. Elle consiste à remettre WordPress dans un état cohérent, puis à renforcer ce qui a été compromis, surtout la chaîne d’identification.
Voici le fil conducteur que j’utilise en production:
1) Vérifier l’intégrité de WordPress “core” 2) Repérer les modifications sur wp-config.php 3) Rechercher la persistance probable dans plugins et uploads 4) Restaurer des comptes et secrets de manière sûre 5) Durcir et surveiller
Cette logique évite un piège classique: nettoyer “en surface” et oublier que l’attaquant s’appuie sur un point unique pour revenir.
Analyser wp-config.php: quoi chercher quand vous soupçonnez une intrusion
Le plus utile, c’est de ne pas se contenter de “regarder” le fichier. Il faut le comprendre: chaque constante ou directive explique ce que WordPress fera, à chaque chargement.
Lors d’une analyse, je cherche en priorité:
Des lignes ajoutées sans raison évidente, souvent en dehors des blocs attendus.
Des injections qui chargent d’autres fichiers PHP, par exemple un require ou include vers un chemin non standard, parfois dans un répertoire d’uploads, wp-content, ou un dossier nommé de manière trompeuse.
Des fonctions ou appels inattendus, comme des exécutions dynamiques, des comportements qui ressemblent à un webshell, ou des mécanismes de récupération d’informations.
Des changements dans les clés et saltes d’authentification. Même si l’interface semble fonctionner, des clés modifiées peuvent invalider votre contrôle ou favoriser des sessions créées “avant” que vous corrigiez le reste.
Un point qui revient très souvent: l’attaquant peut modifier uniquement une petite partie de wp-config.php, juste assez pour que le reste du site “réponde” à ses conditions. Parfois ce n’est pas visible en surface, mais dans la façon dont l’erreur, la redirection ou l’accès s’enchaîne.
Si vous avez une copie “saine” de wp-config.php (ancienne sauvegarde ou fichier connu à partir d’avant l’incident), comparez strictement. Sinon, cherchez un wp-config.php standard de votre version WordPress, mais gardez à l’esprit que des variables peuvent varier selon votre configuration.
Restaurer wp-config.php de manière fiable: remplacer plutôt que corriger au hasard
Quand une intrusion est confirmée, corriger à la main un fichier potentiellement compromis, en espérant avoir retiré tout le code malveillant, est souvent une mauvaise idée. Le risque est de laisser une portion cachée, une condition, ou un morceau de logique de persistance.
La méthode la plus robuste consiste à restaurer wp-config.php à partir d’un gabarit “clean”, puis à réinjecter uniquement les valeurs légitimes.
Concrètement, la partie délicate n’est pas le fichier en soi, c’est la base de données et les accès. Si les identifiants SQL ont été exposés, changer juste le code de wp-config.php ne suffit pas. Il faut aussi gérer les identifiants et révoquer ce qui a été compromis.
C’est là que la décision “remplacer” devient rationnelle: vous repartez d’une base saine et vous réduisez la probabilité d’un résidu.
Ce que vous devez absolument vérifier dans la base et les identifiants
Même si vous remplacez wp-config.php, la base de données peut porter des modifications internes. Les attaquants ont plusieurs leviers:
Modifier des options WordPress pour changer des comportements (y compris des contenus de redirection).
Créer des comptes administrateur ou modifier les rôles d’utilisateurs.
Changer des paramètres de plugins et de thèmes.
Insérer du contenu dans des tables liées aux pages, aux thèmes ou à des mécanismes d’exécution.
En pratique, le minimum est d’inspecter les éléments suivants sur la base de données, selon votre contexte:
Les utilisateurs: vérifiez la liste, les dates d’inscription, et les identifiants suspects.
Les options: repérez des clés qui ne correspondent pas à votre site (certaines options sont stables, d’autres supprimer malware WordPress évoluent avec les plugins).
Les tables liées aux formulaires ou aux intégrations, si vous en utilisez.
Concernant les identifiants SQL, si votre wp-config.php a été lisible par l’attaquant, considérez que ces identifiants doivent être changés. Sinon, l’attaquant peut continuer à modifier à distance la base, même si le fichier PHP est “propre”.
Révoquer les sessions et forcer une réauthentification saine
Quand wp-config.php est compromis, l’attaquant peut avoir créé des sessions avant votre correction, ou modifié des clés qui influencent l’authentification.
Dans une approche prudente, après restauration de wp-config.php et correction de la configuration de sécurité, forcez la déconnexion de toutes les sessions et assurez-vous que les clés d’authentification sont au bon niveau.
Une façon pratique de raisonner: toute modification de la sécurité doit s’accompagner d’une réinitialisation des secrets qui contrôlent l’auth WordPress. C’est aussi une étape de “nettoyage psychologique” pour éviter de croire que le site est sécurisé parce que vous avez changé votre mot de passe, alors que l’attaque persiste via une session déjà active.
Durcir wp-config.php après intrusion: verrouiller le fichier et réduire les chances de retour
Sécuriser wp-config.php après une intrusion, ce n’est pas juste “mettre des droits”. C’est un ensemble de protections à plusieurs niveaux: permissions, accès HTTP, cohérence des valeurs, et surveillance.
Permissions et droits: éviter les écritures non nécessaires
Le standard de durcissement consiste à limiter les permissions au niveau système de fichiers. Sur un serveur Linux, l’idée est simple: WordPress a besoin de lire wp-config.php, pas de l’écrire en continu. Et en cas de compromis d’un plugin, un attaquant ne doit pas pouvoir modifier le fichier facilement.
Je reste prudent sur les chiffres exacts, car chaque environnement et configuration peut varier. Mais le principe demeure: vous voulez des permissions compatibles avec la lecture par le processus PHP, tout en excluant autant que possible l’écriture pour les autres comptes, et vous évitez les permissions larges.
Après mise à jour ou restauration, recontrôlez aussi l’horodatage. Un fichier wp-config.php qui change alors que vous ne touchez à rien est un drapeau rouge.
Limiter l’accès direct au fichier côté web
Un autre point crucial: empêcher l’accès direct via HTTP. Selon le serveur, il peut exister des règles permettant d’interdire l’affichage ou le téléchargement du fichier wp-config.php. Si votre hébergeur gère déjà cela, tant mieux. Si vous devez le faire via une configuration serveur (par exemple règles de sécurité, directives de réécriture ou de blocage), vérifiez le mécanisme en place. Un malentendu ici arrive plus souvent qu’on ne l’imagine.
Vérifier les emplacements “dangereux” liés aux includes
Même avec des permissions correctes, si votre wp-config.php contient une inclusion non standard, un attaquant peut ré-exploiter ce comportement. Il faut donc valider que le fichier ne fait rien d’inattendu au démarrage.
Je recommande de garder wp-config.php aussi minimal que possible. Les “ajouts” qui servent uniquement à des scripts ou à des bricolages personnels deviennent des surfaces d’attaque. Si un ajout existait avant l’incident et qu’il est justifié, documentez-le. Si c’est récent, doutez-en.
Isoler les identifiants SQL
Si l’attaquant a eu accès à la base de données via wp-config.php, vous devez revoir le niveau de privilèges du compte SQL. Un compte avec des droits excessifs multiplie les dégâts. Idéalement, un compte SQL pour WordPress n’a que ce qui est nécessaire pour que WordPress fonctionne, pas plus.
Là encore, l’objectif est de réduire la portée d’une future erreur. Si demain un plugin est compromis, l’impact ne doit pas devenir “toute la base”.
Un piège subtil: croire que “ça marche” signifie “c’est propre”
Le piège le plus coûteux que j’ai vu tient en deux mots: reprise trop rapide. Une fois la page d’accueil revenue, on relâche les contrôles. Or la persistance peut être conditionnelle. Par exemple, du code dans un plugin peut déclencher la redirection uniquement sur certains navigateurs, ou après un certain délai.
Pour wp-config.php, le même piège existe: le fichier peut sembler correct, mais un petit morceau de logique caché peut rester dans la configuration, ou bien une copie de fichier malveillant peut exister ailleurs et être incluse dynamiquement.
C’est pour cela que je conseille une vérification plus structurée que “je clique et ça charge”.
Contrôles post-désinfection: ce que je fais avant de rouvrir au trafic normal
Une fois wp-config.php restauré et les secrets remis à plat, je passe par des contrôles simples mais efficaces.
Je commence par surveiller les journaux d’accès web pendant une période courte, pour repérer si des URL anormales continuent d’être demandées. Si vous voyez les mêmes patterns qu’avant, ce n’est pas forcément un signe que le site est encore compromis, mais c’est une indication que quelqu’un tente encore quelque chose.
Ensuite, je vérifie l’intégrité côté WordPress. Si certains plugins ne correspondent pas à votre catalogue habituel, je les mets de côté et je reconstruis progressivement.
Enfin, je valide l’état des comptes, notamment l’utilisateur principal. La logique est simple: si un compte réapparaît, ou si des rôles changent sans action de votre part, vous avez une persistance encore active.
Exemples concrets de modifications typiques sur wp-config.php en cas d’intrusion
Sans entrer dans des détails exploitables, voici des catégories de modifications qui reviennent dans les incidents:
Des “lignes de secours” ajoutées à la fin du fichier, souvent avec des conditions, qui chargent un contenu externe.
Des constantes de sécurité modifiées. Dans certains cas, elles servent à rendre l’auth plus permissive pour des sessions déjà présentes.
Des instructions qui changent la manière dont WordPress détecte des répertoires ou qui modifient le chargement d’éléments.
Parfois, ce n’est pas le fichier lui-même, c’est une combinaison. Par exemple, wp-config.php n’a l’air que légèrement touché, mais il pointe vers un répertoire où un fichier PHP est déposé, ou il active une option qui permet à un plugin de s’exécuter hors de son mode normal. Dans ces cas-là, la “clé” ne réside pas seulement dans le contenu, mais dans le comportement.
Plan d’action après intrusion: séquence recommandée
Je résume ici une séquence d’intervention qui a tendance à bien fonctionner, surtout quand il y a un doute sur l’étendue de la compromission.
Le principe est de réduire la fenêtre pendant laquelle l’attaquant peut rejouer, puis d’éliminer les dépendances invisibles (fichiers inclus, identifiants exposés, sessions actives).
1) Mettre le site en maintenance et limiter l’accès admin 2) Copier wp-config.php et tous les fichiers suspects, garder des preuves 3) Restaurer wp-config.php propre, reconstruire avec des valeurs sûres 4) Changer les identifiants SQL si vous suspectez une exposition 5) Réinitialiser les secrets et invalider les sessions
Notez que la partie “réinitialiser les secrets” ne se limite pas au mot de passe de l’admin. C’est la combinaison qui fait la différence.
Surveiller après correction: éviter la récidive plutôt que seulement “guérir”
La désinfection ne doit pas être une action ponctuelle. Une fois que vous avez verrouillé wp-config.php, vous devez aussi empêcher la prochaine intrusion.
Concrètement, je recommande de:
Mettre en place une surveillance des changements de fichiers. L’objectif n’est pas de “tout alerter”, mais d’avoir un signal quand wp-config.php ou des fichiers PHP critiques changent.
Vérifier que les plugins et thèmes sont gérés proprement. Les plugins non maintenus, surtout ceux qui s’exécutent côté front, sont des portes fréquentes.
Limiter les uploads si votre activité ne nécessite pas d’imports fréquents. Les compromis passent souvent par le stockage de fichiers.
Rester attentif aux tentatives d’accès répétées. Une attaque qui revient souvent peut être le même acteur ou le même bot, et elle cherchera toujours la prochaine faille.
Gérer l’après, côté organisation: qui a accès à quoi
Un site WordPress compromis n’est pas seulement un incident technique, c’est souvent un incident de processus. Qui a accès au serveur? Qui déploie des plugins? Quelle est la politique de mots de passe?
Quand wp-config.php est en jeu, je pense aussi au “pourquoi” de l’accès. Par exemple, si quelqu’un utilise un compte trop large, ou si des identifiants transitent par des canaux non sécurisés, la probabilité d’une récidive augmente.
Sans transformer cela en audit lourd, j’encadre simplement:
- retirer les accès inutiles, forcer des mots de passe robustes, documenter la procédure de mise à jour.
Cela réduit l’espace de manœuvre de l’attaquant et vous redonne de la clarté quand un incident arrive.
Ce que vous devez éviter: gestes fréquents qui empirent la situation
Après une intrusion, l’envie de “faire vite” est compréhensible. Le problème est que certaines actions déclenchent la persistance ou masquent l’analyse.
Je vois souvent des erreurs:
Remplacer wp-config.php sans vérifier la base de données, ce qui laisse des utilisateurs malveillants ou des options persistantes.
Nettoyer les plugins mais ignorer les fichiers dans les répertoires d’upload, où des scripts peuvent rester dormants.
Changer le mot de passe admin sans remettre en cause les secrets d’authentification, ce qui laisse une voie d’accès via sessions déjà créées.
Réouvrir le site au trafic normal dès que la page charge, avant de vérifier les journaux et l’intégrité.
Ces erreurs ne viennent pas d’une mauvaise intention. Elles viennent de la pression et du manque de méthode.
Quand faire appel à un spécialiste, même si vous êtes à l’aise techniquement
Il y a des situations où je conseille de ne pas tout porter seul, surtout si vous n’avez pas d’historique solide ou si la compromission est étendue. Par exemple:
Si vous voyez des signes d’exécution au-delà de WordPress, sur d’autres chemins du serveur.
Si vous ne pouvez pas accéder aux logs et que vous n’avez pas de sauvegarde fiable.
Si votre environnement est complexe (reverse proxy, multi domaines, environnement partagé), car une restauration “à l’aveugle” peut être risquée.
Le vrai critère n’est pas la taille du site, c’est l’incertitude. Si vous ne pouvez pas répondre à la question “qu’est-ce qui a été modifié et comment ça persiste”, il vaut mieux externaliser une partie de la vérification.
Checklist finale de sécurisation de wp-config.php après intrusion
- Restaurer wp-config.php depuis une version propre ou un gabarit fiable, sans conserver d’ajouts non justifiés. Revalider les constantes critiques, en particulier celles liées à l’authentification, puis invalider les sessions. Vérifier et durcir les permissions au niveau fichier, en vous assurant que le processus PHP peut lire mais pas écrire inutilement. Empêcher l’accès direct au fichier depuis le web avec des règles adaptées à votre serveur. Changer les identifiants SQL et réduire les privilèges du compte de base de données.
Cette dernière étape est celle qui transforme une désinfection “ponctuelle” en restauration “durable”.
Les bonnes décisions pour que l’attaquant ne revienne pas
La sécurisation de wp-config.php après intrusion n’est pas un acte isolé. C’est la jonction entre une désinfection du code, une remise à niveau de la configuration, et une gestion des droits et des secrets. Une fois que vous avez restauré la configuration, le travail consiste à prouver que le site ne peut plus être “ré-activé” par les mêmes mécanismes.
Si vous ne retenez qu’une idée, retenez celle-ci: wp-config.php n’est pas seulement un fichier technique, c’est un centre de contrôle. Après une intrusion, il faut le traiter comme tel, le remettre en état propre, puis le verrouiller assez fort pour que l’attaquant n’ait ni la place, ni le temps, ni les droits pour recommencer.