Nettoyage malware WordPress : vérifier les injections dans wp-config.php

Quand un site WordPress se met à faire des choses bizarres, on pense souvent aux plugins, aux thèmes, ou à un fichier PHP oublié dans l’arborescence. Pourtant, sur beaucoup d’installations compromises, la porte d’entrée la plus efficace n’est pas visible à l’œil nu dans wp-admin. Elle se niche parfois dans l’endroit le plus discret de toute la configuration: wp-config.php. Le fichier n’est pas fait pour “exécuter du code”, et c’est précisément pour ça qu’une injection y passe inaperçue plus longtemps que dans un plugin.

J’ai déjà vu des cas où le site avait l’air “normal” côté administration, mais où le front-end redirigeait vers des URLs douteuses, ou bien où des pages fraîchement publiées étaient remplacées quelques minutes après. Dans ces situations, la vérification de wp-config.php n’est pas un geste de routine. C’est souvent le moment où le doute devient concret, quand on repère une modification minuscule, cachée dans quelques lignes de condition ou dans un bloc au milieu du fichier.

Ce guide détaille comment aborder le nettoyage malware WordPress en visant en priorité les injections dans wp-config.php, avec des méthodes qui évitent les faux positifs et les erreurs classiques.

Pourquoi wp-config.php attire les pirates

Wp-config.php contient des variables de base: identifiants de base de données, clés de chiffrement, préfixes de tables, paramètres de debug, et parfois des réglages spécifiques. WordPress le lit très tôt, avant d’initialiser tout le reste. Donc, si quelqu’un parvient à y déposer un fragment PHP, il peut déclencher des actions avant même que le reste du site ne “se charge”.

Les scénarios typiques que j’ai rencontrés autour de ces injections:

redirections conditionnelles basées sur l’URL, le navigateur, ou même l’heure; chargement de fichiers distants via include, require, ou des fonctions qui récupèrent du contenu à la volée; écrasement de variables pour manipuler des paramètres, comme l’authentification ou des chemins; ajout discret de code qui enregistre des données (utilisateurs, cookies) ou qui modifie des options WordPress en arrière-plan.

Le plus trompeur, c’est que l’injection peut être courte. Une ou deux lignes suffisent si elles exploitent une fonction existante, ou si elles déclenchent un chargement différé.

Les symptômes qui pointent vers une injection

Avant d’ouvrir wp-config.php, je préfère relier le symptôme au suspect, ne serait-ce que pour gagner du temps. Beaucoup de compromissions déclenchent plusieurs signaux en même temps, et quand ceux-ci reviennent régulièrement, ça rend l’hypothèse crédible.

Sans établir une correspondance absolue, voici des indices qui font penser à une modification dans wp-config.php, ou à une manipulation de très bas niveau:

redirections vers des sites tiers, souvent uniquement sur certaines pages (par exemple /wp-login.php, /category/, ou des URLs correspondant à des mots clés); messages d’erreur intermittents, ou affichage d’un contenu qui disparaît après rechargement; fonctionnement “normal” dans l’administration, mais comportement corrompu sur le front, surtout à certaines heures; apparition de nouveaux utilisateurs WordPress inconnus, ou changement de rôles sans explication; consommation anormale de ressources côté serveur, pics CPU ou requêtes répétitives qui ressemblent à des scripts d’arrière-plan.

Dans plusieurs cas, le point commun était un comportement conditionnel, ce qui colle bien avec une injection placée dans wp-config.php. Les pirates adorent la discrétion, et un morceau de code “qui ne s’exécute que parfois” est difficile à repérer avec des tests superficiels.

Préparation avant d’éditer: éviter d’aggraver

Avant de toucher au fichier, il faut considérer un risque simple: si le code injecté lit ou modifie des éléments, une édition “à chaud” peut casser la logique, ou au contraire déclencher une nouvelle exécution si vous relancez le site dans un certain contexte.

Voici la méthode qui m’a le plus souvent évité des problèmes:

créer une copie de wp-config.php (sur le serveur et, si possible, en local); 2) relever la version du serveur (PHP) et la taille actuelle du fichier; 3) vérifier si wp-config.php a été modifié récemment, via l’historique de modification du système de fichiers ou les logs d’accès/écriture (quand c’est disponible).

Le but n’est pas seulement la sécurité. C’est aussi la capacité à comparer et à reconstruire. Si vous devez revenir en arrière, vous voulez pouvoir le faire vite.

Si votre site est en production sensible, une mise en quarantaine temporaire peut valoir le coup: désactiver le trafic, ou au moins bloquer l’accès au front pendant que vous examinez le fichier. Je ne donne pas de recette universelle ici, mais l’idée est de réduire les exécutions pendant votre diagnostic.

Ce qu’il faut chercher dans wp-config.php

On ne peut pas “trouver la signature” unique, parce que chaque injection est bricolée. En revanche, il existe des motifs récurrents qui, ensemble, deviennent très parlants.

Typiquement, une injection dans wp-config.php se voit souvent par:

des appels à des fonctions peu attendues dans un fichier de configuration, comme base64 _decode, str_rot13, preg_replace avec du code, ou des fonctions de lecture distante; des includes/requires vers des chemins bizarres, parfois construits dynamiquement; des blocs conditionnels ajoutés autour de $ _SERVER, $_GET, $ _POST, $_COOKIE, ou de constantes inhabituelles; du code “sale” inséré au milieu de structures attendues, comme entre deux définitions de constantes; une présence de chaîne de caractères qui ressemble à une URL, un nom de fichier, ou un token, surtout si le reste de wp-config.php n’en contient pas.

Un détail important: wp-config.php d’une installation WordPress standard contient des commentaires et des constantes attendues. Les injections se logent souvent entre ces constantes, ou après la fin apparente du fichier. Donc, même si vous ne voyez “rien” dans la partie visible, scrollez et lisez tout, y compris les lignes ajoutées plus bas.

Cas fréquent: un bloc conditionnel caché

Un pattern que j’ai déjà vu plusieurs fois ressemble à ceci, conceptuellement: un if qui vérifie la requête, puis exécute du code qui charge un fichier distant ou redirige l’utilisateur. La variable de condition peut être un paramètre d’URL, un header, ou même une empreinte de requête.

Ce que vous voulez vérifier, ce n’est pas la logique en elle-même, c’est la nature des fonctions appelées dans le bloc. S’il y a du require/include, du curl, de file _get_contents vers une URL, ou des sorties directes (echo, header), ça devient suspect.

Cas fréquent: inclusion d’un “loader” externe

Parfois, wp-config.php ne contient pas toute la saleté, seulement un déclencheur. https://gardewp.fr/nettoyage-malware-wordpress/ Il appelle un fichier qu’on retrouve ensuite dans un sous-dossier ou dans un chemin temporaire. Cette approche est simple: le fichier loader peut être mis à jour par le pirate sans toucher de nouveau à wp-config.php.

Donc, quand vous repérez un “include” suspect dans wp-config.php, notez le chemin et inspectez aussi ce fichier, même s’il n’a pas l’air énorme ou très “malveillant” au premier regard.

Comparer wp-config.php à une version attendue

La meilleure manière de repérer une injection, c’est souvent de comparer. Idéalement, avec une version connue saine.

Si vous avez un backup récent, comparez. Si vous n’en avez pas, vous pouvez au moins comparer avec un wp-config.php “type” généré par WordPress et vérifier:

l’existence de seules constantes attendues; l’absence de code exécutable hors des sections de configuration classiques; la structure globale.

Je fais souvent une approche par tri: je commence par repérer les zones où il n’y a que des define(), des commentaires, et des paramètres. Dès que je tombe sur un bloc de code qui sort du cadre, j’isole le bloc et je cherche sa provenance. Un fichier injecté n’a généralement pas une cohérence avec le reste, même si l’auteur a pris le temps de masquer.

Quand le “diff” ment

Il y a un piège courant: certains sites ont des wp-config.php “sur mesure” (multisite, compatibilité serveur, configuration de cache, réglages de sécurité). Dans ces cas, on trouve parfois des blocs conditionnels raisonnables, par exemple liés à WP_DEBUG, à la résolution du chemin ABSPATH, ou à la définition de constantes. Le risque est d’étiqueter à tort.

La règle pratique que j’utilise: la configuration standard peut contenir des defines, mais elle ne devrait pas contenir des fonctions de récupération distante, des redirections, ou de l’exécution de code dynamique. Les réglages légitimes peuvent être plus “visibles”, les injections plus “fonctionnelles”.

Procédure de vérification pratique sur wp-config.php

Je vous propose une démarche qui tient dans la réalité, sans supposer un niveau technique identique pour chaque lecteur.

D’abord, ouvrez wp-config.php dans un éditeur qui affiche clairement les caractères et évite de “réinterpréter” le fichier. Je conseille un outil qui montre la numérotation de lignes. Ensuite, cherchez des éléments anormaux:

toute mention de fonctions d’exécution ou de chargement (eval, assert, base64_decode avec exécution indirecte, include/require “dynamique”); toute sortie directe (header, exit, die, echo) dans un fichier censé être une configuration; toute récupération de contenu depuis l’extérieur, que ce soit via file _get_contents, curl, ou des libs internes.

Une bonne approche consiste aussi à regarder la fin du fichier. Beaucoup d’injections se placent vers la fin pour ne pas perturber la lecture des premières constantes.

Ensuite, vérifiez si le fichier contient des marqueurs inhabituels: des fragments encadrés par des commentaires obscurs, une structure d’obfuscation, ou des chaînes de base64. Même si le contenu ne fait “pas exploser” le site, ce sont des signaux forts.

Voici un mini-checklist, volontairement courte, pour orienter votre lecture. Elle n’est pas censée remplacer un examen attentif, mais elle aide à trier.

Trouver des includes/requires, surtout si le chemin est construit dynamiquement Chercher eval, assert, ou des exécutions indirectes via decode + include Relever toute redirection ou sortie (header, exit, die, echo) Repérer des appels à file _get_contents/curl vers une URL externe Vérifier la fin du fichier et les blocs conditionnels basés sur $ _GET, $_POST, $ _COOKIE ou $_SERVER

Si vous cochez plusieurs cases, il faut considérer que wp-config.php a probablement été modifié et que le nettoyage ne sera pas un simple “commenter une ligne”.

Que faire quand vous trouvez du code injecté

Une erreur classique consiste à supprimer “la ligne la plus bizarre” et à espérer que tout s’arrange. Parfois, l’injection est plus étendue, ou elle déclenche ailleurs. D’autres fois, le pirate a modifié des variables pour rendre le code difficile à repérer.

La stratégie la plus sûre consiste à combiner correction et validation.

Remplacer wp-config.php par une version saine, si vous en avez une. Si vous n’avez pas de version saine, reconstruire wp-config.php à partir de vos paramètres réels, en conservant uniquement les constantes nécessaires à la connexion base de données et aux clés de sécurité (ou celles que vous possédez déjà si elles n’ont pas été compromise). Ensuite, remettre en service le site sur un mode de test contrôlé.

Le trade-off ici est important: reconstruire wp-config.php peut réinitialiser certaines options si le fichier a été utilisé pour des réglages spécifiques. C’est pour ça que je recommande de noter précisément ce que vous allez récupérer avant de supprimer. Les erreurs de configuration peuvent provoquer un site inaccessible, ce qui complique le diagnostic.

Exemple concret de “nettoyage” qui marche, et pourquoi

J’ai eu un cas où wp-config.php semblait presque normal, avec juste une différence en fin de fichier. Une requête sur le front était parfois redirigée. Le code injecté ne faisait rien au chargement standard. Il vérifiait un paramètre d’URL et, seulement dans ce cas, appelait un fichier local situé dans un dossier rarement utilisé.

Le nettoyage a consisté à:

supprimer le bloc conditionnel dans wp-config.php; supprimer le fichier loader dans le dossier mentionné; vérifier ensuite si d’autres fichiers avaient été modifiés dans la même période.

La leçon: même quand wp-config.php est la source la plus visible, il faut contrôler ce qui a été appelé. Sinon, l’injection peut revenir via un autre point.

Inspecter aussi ce que l’injection a pu toucher

Même si votre objectif principal est wp-config.php, un vrai nettoyage malware WordPress ne s’arrête pas au fichier. La plupart des infections ne se limitent pas à une seule touche. Wp-config.php peut être l’amorçage, tandis que le corps du malware est ailleurs.

En pratique, après remplacement de wp-config.php par une version saine, je vérifie:

l’existence de nouveaux fichiers PHP dans des dossiers inhabituels (pas seulement dans wp-content, mais aussi dans des racines secondaires); la modification d’anciens fichiers qui ne devraient pas bouger, par exemple ceux du thème actif; les utilisateurs WordPress nouveaux ou modifiés; les options WordPress modifiées, notamment celles liées à des redirections, des scripts, ou des champs custom.

Si vous ne pouvez pas tout investiguer, le minimum est au moins de vérifier les traces “visibles” dans wp-content et l’accès externe, mais l’idéal reste une inspection cohérente des fichiers modifiés.

Sécuriser après le nettoyage: éviter le retour

Nettoyer une injection sans traiter la cause, c’est comme réparer une serrure sans retrouver la clé d’une personne entrée. Un pirate qui a accès au serveur revient souvent, parce que la porte n’a pas été vraiment fermée.

Après correction de wp-config.php, je traite les causes probables une par une:

identifiants compromis (mots de passe faibles, réutilisés, brute force); plugin vulnérable ou obsolète; thème obsolète; permissions trop ouvertes sur des dossiers sensibles; absence de durcissement sur l’écriture de fichiers.

Je sais que tout le monde veut “un correctif rapide”, mais sur des infections persistant après correction, la cause revient très souvent à un point d’accès. Et wp-config.php est alors un symptôme, pas la racine.

Un point délicat: clés de sécurité et “relog”

Si wp-config.php a été modifié avec les clés de sécurité WordPress, il faudra probablement les régénérer après nettoyage. C’est une action légitime, mais elle a un impact: les utilisateurs se déconnectent, et la session change. Dans une équipe, ça peut être gênant, mais c’est préférable à garder une configuration corrompue.

Si les clés ne sont pas modifiées et que vous remettez un fichier sain conforme, vous pouvez éviter des déconnexions inutiles. Le bon jugement vient de l’examen initial.

Travailler avec des backups sans tomber dans le piège

Un backup est votre allié, mais il peut aussi contaminer votre solution si la copie inclut déjà le malware. J’ai vu des récupérations où wp-config.php provenait d’un backup, et le malware restait intact, juste moins visible.

Avant de restaurer, vérifiez au moins:

la date du backup; sa cohérence avec le symptôme (si le problème a commencé après, le backup est probablement sain); le contenu de wp-config.php dans le backup, en particulier la présence de code suspect.

Même si vous restaurez l’ensemble du site, gardez l’œil sur wp-config.php. C’est souvent le fichier qui raconte l’histoire, parce qu’il est directement lié à l’amorçage.

Recommandations de méthode pour réussir du premier coup

Pour que le nettoyage malware WordPress soit efficace, j’ai pris l’habitude de travailler en “boucles courtes” plutôt qu’en grand chantier. Une vérification, une correction, un test. Vous limitez ainsi l’inconnu.

Quand vous êtes dans une phase d’incertitude, un test contrôlé est précieux. Si le malware déclenche uniquement sous certaines conditions, vous pouvez le rater si vous testez trop “en surface”.

Une approche pragmatique consiste à:

tester l’accès aux pages suspectes juste après modification; surveiller les logs d’erreurs et, si vous avez accès, les logs d’accès; confirmer que le comportement revient à la normale sur une période courte (quelques minutes suffisent souvent quand la redirection est immédiate).

Si le problème revient rapidement après remplacement de wp-config.php, ce n’est pas forcément que le fichier n’est pas corrigé. Ça peut signifier qu’un autre composant régénère wp-config.php, ou que le pirate a mis en place une mécanique de persistance. Dans ce cas, le diagnostic doit s’élargir vers l’infrastructure: scripts planifiés, changements de permissions, ou exécution automatique côté serveur.

Exemple de “lecture” d’un wp-config.php suspect (sans vous faire perdre du temps)

Sans coller un code exact, je vous donne la logique d’analyse que j’applique. Imaginons un fichier où tout est standard au début, puis vous voyez un bloc qui ressemble à ceci sur le plan conceptuel: un if vérifie une donnée de requête, puis exécute une fonction liée au chargement de contenu, et enfin redirige.

Votre examen doit répondre à trois questions:

Le bloc est-il “normal” pour une configuration WordPress? En général, non. 2) Le bloc dépend-il d’une donnée utilisateur? Si oui, ça sent le malware orienté visiteurs. 3) Le bloc appelle-t-il quelque chose qui n’est pas nécessaire à la configuration? Include, require, decode, redirection, récupération externe. Ce sont des drapeaux rouges.

Ensuite, vous supprimez ce bloc, vous remplacez le fichier par une version propre, et vous inspectez la cible appelée (fichier distant ou local). Si vous ne suivez pas cette chaîne, vous nettoyez la façade, pas le mécanisme.

Ce que j’éviterais pendant un nettoyage

Il y a des gestes qui donnent l’illusion d’avancer mais compliquent la suite:

remplacer wp-config.php par un “copier-coller” trouvé sur internet sans ajuster vos identifiants et vos paramètres réels; supprimer au hasard des fichiers PHP sans vérifier ce qui les appelle; nettoyer uniquement côté WordPress si le serveur a des scripts persistants au niveau système (tâches planifiées, cron, webshell non WordPress); laisser le site en ligne pendant que vous testez différentes versions de wp-config.php sans surveillance.

Chaque infection a ses nuances, mais ces erreurs reviennent assez souvent pour être mentionnées.

Petite démarche de validation après correction

Une fois wp-config.php corrigé, je fais une validation simple mais rigoureuse. Je veux être sûr que:

le fichier ne contient plus de code exécutable suspect; les pages qui posaient problème ne redirigent plus; l’administration n’affiche pas de comportements étranges; aucun nouveau fichier inattendu n’apparaît, du moins pas dans une fenêtre courte.

Si le comportement redevient erratique, je reviens en arrière et je vérifie deux choses, souvent oubliées: l’état exact du fichier sur le disque après vos modifications, et la possibilité que quelque chose régénère wp-config.php.

Dans certains hébergements, un outil de déploiement, un mode “hardening” mal configuré, ou un plugin de sécurité agressif peut aussi toucher aux fichiers. Ça arrive. Le diagnostic doit rester factuel, pas émotionnel.

Quand faire appel à un support ou à un expert

Si vous n’avez pas de sauvegardes exploitables, si wp-config.php est vraiment très modifié, ou si vous suspectez une compromission plus large du serveur, mieux vaut demander de l’aide. L’enjeu n’est pas seulement de “supprimer une injection”, mais de garantir que le site ne reviendra pas compromis.

Un signe d’alerte, par exemple: vous remplacez wp-config.php et, peu de temps après, il se retrouve à nouveau modifié. Dans ce cas, la cause n’est pas “résolue”, elle est en train de se reproduire. C’est le moment d’investiguer en profondeur, idéalement avec des accès aux logs et à l’environnement.

Résumé de l’approche

Le nettoyage malware WordPress passe souvent par un chantier méthodique. Wp-config.php est un point d’entrée privilégié parce qu’il se charge très tôt et parce qu’il peut orchestrer des actions discrètes.

Si vous voulez garder une méthode simple: copiez, comparez, cherchez les motifs d’exécution et les chargements suspects, remplacez par un fichier sain, puis vérifiez la persistance et les autres modifications possibles dans l’arborescence.

La différence entre un “nettoyage partiel” et une vraie remise à niveau tient rarement à une technique magique. Elle tient à la qualité de l’analyse, au fait de suivre la chaîne d’appel, et à la vérification après correction. C’est moins glamour que certains scripts, mais c’est ce qui fait la stabilité quand le site est remis en production.