Quand un site WordPress commence à distribuer des redirections bizarres, à afficher du contenu sans rapport, ou à envoyer des requêtes vers des domaines inconnus, on pense souvent au thème, aux plugins, voire à une compromission plus large. Dans certains cas, le point de départ est plus discret et plus fréquent que ce qu’on imagine: une injection dans le fichier wp-config.php.
Sur le papier, wp-config.php sert à configurer WordPress, notamment la base de données, les clés de sécurité et quelques options. En pratique, c’est aussi un endroit idéal pour un malware, car ce fichier est chargé très tôt par WordPress. Une petite ligne malveillante suffit pour déclencher du code à chaque requête, avant même que vous ayez le temps de charger l’interface d’administration.
Je vais vous montrer comment reconnaître ce scénario, quoi faire concrètement pour supprimer le malware WordPress via wp-config.php, et surtout comment éviter de casser le site pendant la réparation. L’objectif n’est pas seulement de “supprimer” quelque chose, mais de rétablir un état fiable, vérifiable, et reproductible.
Pourquoi une injection dans wp-config.php est un scénario qui revient
La raison pour laquelle cette technique marche tient en quelques mots: WordPress exécute le PHP au moment où il lit le fichier. Si l’attaquant arrive à modifier wp-config.php, il peut:
- injecter une logique qui modifie des paramètres, charge un fichier distant, ou contourne des vérifications; activer un comportement conditionnel, par exemple seulement pour certains navigateurs, certaines URLs, ou seulement quand un utilisateur n’est pas connecté; rester discret, en ne laissant presque rien visible à un oeil pressé.
J’ai déjà vu des cas où l’ajout n’était pas une “fonction bizarre”, mais une condition très courte, qui faisait charger un contenu depuis un domaine compromis. Extérieurement, le site répondait “normalement” pendant des heures. Puis, quand l’attaquant mettait à jour la chaîne de chargement ou quand un cache expirait, tout devenait soudainement instable.
Le plus piégeux, c’est que l’on peut croire avoir “repéré” le problème alors qu’il se propage ailleurs. L’injection dans wp-config.php est parfois le mécanisme de démarrage, mais pas toujours la seule pièce du puzzle.
Premiers signaux: ce que vous pouvez observer sans toucher au code
Avant d’ouvrir le fichier et de modifier quoi que ce soit, observez. Pas dans l’esprit d’un enquêteur de fiction, plutôt pour gagner du temps et éviter une suppression incomplète.
Si vous avez accès aux logs d’accès web, regardez la cohérence entre l’heure, les URLs qui changent et les comportements. Sur un site infecté, vous verrez souvent:
- des tentatives de chargement externes récurrentes; des erreurs PHP, parfois très brèves, associées à wp-config.php ou à index.php; des pics de requêtes sur des endpoints inhabituels pour votre trafic normal.
Côté navigateur, certains symptômes sont assez caractéristiques: pages qui redirigent vers une URL qui n’a rien à voir avec votre contenu, contenu HTML injecté en plein milieu d’une page, ou scripts qui apparaissent dans le “Voir la source” alors qu’ils ne sont pas dans vos thèmes.
Cette étape d’observation ne remplace pas l’analyse du fichier, mais elle vous donne une idée de l’urgence et du périmètre.
Lire wp-config.php sans se tromper: repérer l’intrus
Un wp-config.php propre ressemble à un fichier homogène: des constantes, des définitions, éventuellement quelques lignes liées aux clés de sécurité, à l’environnement, et aux réglages de base.
Un wp-config.php injecté présente souvent des “ruptures” de style. Les attaquants ne savent pas toujours écrire du PHP propre, et même quand ils y arrivent, ils laissent des traces dans la structure.
Les indices les plus fréquents que j’ai rencontrés:
- présence de eval(, de base64_decode( ou de gzinflate(; inclusion de fichiers via require ou include avec des chemins bizarres, ou des URL au lieu de chemins locaux; définition dynamique de variables de type “commande” ou “action”, suivie d’une exécution; commentaires ajoutés à la fin du fichier, ou blocs PHP très denses qui n’ont rien à voir avec les constantes habituelles.
L’injection peut aussi être “conditionnelle”. Par exemple, le code ne s’exécute que si une variable d’environnement est absente, si l’IP correspond à une plage, ou si une requête contient un paramètre précis. Dans ce cas, l’intrus peut paraître minuscule dans le fichier, mais déclencher beaucoup derrière.
Un point important: avant de supprimer, prenez une sauvegarde de l’original. Pas une capture d’écran, une copie réelle. Et si vous le pouvez, gardez aussi une seconde sauvegarde si vous devez revenir en arrière.
Sauvegarder avant de toucher: le filet de sécurité qui évite la catastrophe
Pour supprimer malware WordPress via wp-config.php, vous allez probablement:
1) copier des valeurs importantes (base de données, identifiants, clés); 2) modifier ou remplacer le fichier; 3) redémarrer la couche WordPress; 4) ensuite vérifier que la fonctionnalité et la sécurité reviennent à la normale.
Si vous perdez une information, par exemple le nom de la base ou un préfixe de tables, WordPress peut afficher “Erreur de connexion à la base de données”, ce qui vous fera perdre du temps.
Voici la partie pratique, qui m’a sauvé plusieurs fois la mise quand un client paniquait.
- Faites une copie du fichier wp-config.php actuel (nommez-la par exemple wp-config.php.bak-injection). Gardez vos paramètres de base de données: DB NAME, DBUSER, DB PASSWORD, DBHOST, et $table_prefix. Notez aussi les clés de sécurité (AUTH KEY, SECUREAUTH KEY, LOGGEDIN KEY, NONCEKEY et leurs variantes). Vérifiez si vous avez des réglages spécifiques dans le fichier (table prefix, mode debugging, ABSPATH, éventuellement configurations liées à un provider). Si le site est en production, planifiez une fenêtre courte, car chaque tentative peut provoquer des redirections ou des logs supplémentaires.
Cette liste tient en peu de lignes, mais elle évite les erreurs “bêtes” qui rendent l’incident plus long que nécessaire.
Méthode de correction fiable: restaurer puis durcir
Il y a deux approches principales. La première consiste à corriger “à la main” en supprimant uniquement les lignes injectées. La seconde consiste à remplacer le fichier par un fichier propre, puis à réinjecter uniquement les valeurs légitimes.
En cas d’injection dans wp-config.php, je préfère généralement la seconde approche, à condition de bien conserver les variables nécessaires. Pourquoi? Parce que retirer une ligne malveillante ne garantit pas que d’autres fragments ne subsistent pas, surtout si l’injection est obfusquée.
Étape 1: comparez et identifiez la zone suspecte
Ouvrez wp-config.php et cherchez les ruptures de logique: blocs d’exécution, décodeurs, imports exotiques. Dans un fichier standard, la plupart des lignes sont des définitions de constantes, structurées.
Si vous trouvez un bloc PHP qui ne correspond à rien d’attendu, marquez-le dans votre copie sauvegardée, sans le supprimer encore. La lecture attentive est utile, car un malware “propre” peut se contenter d’une modification de variable, puis agir ailleurs.
Étape 2: remplacez par un wp-config.php sain
Un wp-config.php “sain” vient de WordPress, typiquement via wp-config-sample.php, ou via un wp-config de confiance conservé par votre organisation. L’idée est simple:
- vous partez d’un fichier de base vierge; vous copiez vos valeurs nécessaires (base de données, clés de sécurité, préfixe de tables); vous éliminez totalement le contenu existant suspect.
Cela vous sort de l’incertitude “ai-je supprimé toutes les variations?”. Ce n’est pas seulement du nettoyage, c’est une reconstruction.
Étape 3: redémarrez WordPress et vérifiez le comportement
Une fois le fichier restauré, rechargez le site, testez l’accès admin, et surveillez les logs si vous le pouvez. Sur un site infecté, les symptômes peuvent se poursuivre un instant si vous avez un cache agressif, un reverse proxy, ou si des caches de page contiennent encore du contenu injecté.
En général, si l’injection était dans wp-config.php et constituait le déclencheur principal, le comportement malveillant disparaît rapidement après réparation. Si ce n’est pas le cas, c’est un signal important: il y a possiblement une persistance ailleurs.
Quoi faire si l’injection revient dès que vous changez wp-config.php
Quand un malware revient immédiatement, il y a presque toujours une raison technique ou organisationnelle derrière.
Les causes les plus courantes:
- des permissions trop larges sur le fichier (l’attaquant a laissé un mode qui permet d’écraser facilement); une compromission de compte administrateur qui modifie à nouveau le fichier; une autre porte d’entrée dans le site, par exemple un plugin vulnérable, un thème compromis, ou un fichier de type “web shell” ailleurs sur le serveur; une automatisation côté serveur, par exemple un job malveillant.
Dans ce cas, “supprimer malware WordPress” ne se limite pas au fichier. Il faut confirmer que le point de contrôle est sécurisé, sinon vous passerez votre temps à réparer ce que l’attaquant réinjecte.
Je recommande alors de traiter l’incident comme une compromission, même si vous avez un point de départ clair. Réinitialisez les mots de passe, vérifiez les utilisateurs, et inspectez les plugins et thèmes actifs. Souvent, le malware dans wp-config.php n’est qu’une facette d’un ensemble.
Vérifier qu’il ne reste pas de persistance ailleurs
Une correction propre de wp-config.php est une étape majeure, mais je n’ai jamais considéré un nettoyage complet tant que je n’avais pas vérifié trois zones: les fichiers PHP inhabituels, les thèmes et plugins, et les utilisateurs.
Voici un cadre de vérification utile, sans tomber dans une chasse infinie.
- Inspectez les dossiers wp-content/plugins et wp-content/themes pour repérer des fichiers récemment ajoutés ou des fichiers qui ne correspondent pas à la structure attendue. Cherchez des fichiers PHP aux noms non conventionnels, ou des scripts qui contiennent des fonctions typiques de chargement distant, d’obfuscation, ou d’exécution dynamique. Vérifiez les utilisateurs WordPress: nouveaux comptes, rôles élevés, noms d’utilisateur inattendus. Contrôlez vos crons: WordPress cron (via plugins et options) et cron système si vous y avez accès. Faites une passe sur les fichiers racine autres que wp-config.php: index.php, .htaccess, fichiers générés, éventuelles configurations de serveur.
Je sais que ça fait beaucoup, mais l’expérience montre que la persistance est rarement “une seule ligne”. Le gain, c’est de concentrer l’inspection sur les endroits qui servent de point d’ancrage.
Sécuriser le wp-config.php après suppression: les détails qui comptent
Une fois le fichier remis en état, il faut éviter que la situation se reproduise. Les protections ne demandent pas forcément des outils complexes. Souvent, de simples ajustements suffisent.
Sur le plan pratique, pensez à l’intégrité du fichier:
- évitez les permissions trop permissives (en particulier si votre hébergement autorise l’écriture facilement); limitez l’accès SSH/SFTP aux comptes nécessaires; surveillez les actions des utilisateurs (surtout si vous avez plusieurs administrateurs); mettez à jour les plugins et thèmes, et supprimez ce qui n’est plus utilisé.
Côté WordPress, activez aussi une approche de durcissement courante: limiter les droits, supprimer les comptes inutiles, forcer la rotation des mots de passe après un incident.
Cas particulier: clés de sécurité et sessions invalidées
Quand vous restaurez un wp-config.php, une question revient souvent: faut-il régénérer les clés de sécurité WordPress?
Si vous suspectez une compromission, la réponse pratique est généralement oui. Les clés de sécurité affectent la validité des cookies et des sessions. Les conserver peut laisser des sessions compromises encore valides, même après nettoyage du point d’entrée.
La bonne démarche consiste à régénérer les clés, remplacer les valeurs dans wp-config.php, puis forcer une déconnexion des utilisateurs. Concrètement, vos visiteurs peuvent se reconnecter, mais c’est un coût acceptable comparé au risque de garder une session “admin” compromise.
Exemple de trajectoire de correction (ce que j’ai vu en intervention)
Pour rendre tout ça concret, je vous décris un déroulé réel, sans noms de domaines ni détails qui permettraient de remonter à un cas précis.
Le site avait des redirections aléatoires vers des pages externes. L’équipe avait d’abord supprimé un plugin récemment installé, sans impact. Les redirections reprenaient au bout de quelques minutes.
En inspectant wp-config.php, on a trouvé en bas du fichier un bloc PHP qui ne ressemblait à aucune configuration standard. Il contenait un mécanisme de décodage et un chemin d’inclusion conditionnel. Le fichier “avait l’air normal” au premier coup d’oeil, mais la logique en bas expliquait le comportement.
La correction a consisté à remplacer wp-config.php par une version propre reconstruite à partir d’un échantillon, puis à recopier uniquement les paramètres de base de données et le préfixe. Après redémarrage, la redirection a disparu. Ensuite, en inspectant wp-content, on a trouvé un plugin avec des fichiers supplémentaires dans un dossier inattendu. La suppression de ces fichiers a complété la réparation.
Ce scénario illustre le point clé: attaquer via wp-config.php peut donner l’impression que tout est réglé, jusqu’au moment où la persistance se révèle ailleurs.
Si vous ne pouvez pas accéder à wp-config.php
Parfois, l’accès est bloqué, soit parce que l’hébergement est instable, soit parce que la compromission a modifié des permissions. Dans ce cas, ne forcez pas au hasard.
La voie la plus sûre est d’agir avec une approche “réinstallation contrôlée”:
- récupérez une sauvegarde propre si vous en avez une antérieure à l’incident; remplacez le fichier et tout le corpus WordPress par des versions officielles; réinjectez uniquement vos configurations (notamment wp-config.php et éventuellement des contenus médias), en conservant le moins possible de ce qui provient du système compromis.
Si vous n’avez pas de sauvegarde exploitable, l’analyse doit être plus prudente, car il est facile de casser la configuration de la base de données. L’idéal est d’obtenir les valeurs via votre hébergement (panel) ou via des backups automatiques.
Points de vigilance, pour éviter les erreurs fréquentes
Il y a trois erreurs que je vois souvent après coup:
D’abord, supprimer le code suspect sans restaurer un fichier sain. Une injection peut être obfusquée, et supprimer “la moitié” ne fait qu’ouvrir d’autres chemins.
Ensuite, oublier la rotation des identifiants. Si un compte admin a été utilisé, le risque ne s’arrête pas au fichier: l’accès persistant peut rester.
Enfin, croire qu’un nettoyage suffit tant que l’interface “semble ok”. Certains malwares n’agissent que sur des URL précises ou déclenchent du contenu uniquement quand un paramètre est présent. D’où l’importance de tester, pas seulement de recharger la homepage.
Quand demander de l’aide, et quoi fournir
Si vous devez externaliser l’intervention (hébergeur, prestataire sécurité, ou équipe interne), vous gagnerez du temps si vous livrez les éléments utiles:
- la version du WordPress et les plugins actifs; le contenu de wp-config.php actuel (en évitant de masquer les lignes nécessaires au diagnostic); les symptômes observés, avec un exemple d’URL redirigée ou d’action déclenchante; les dates approximatives d’apparition; un aperçu des accès: tentatives, logs si disponibles, ou au moins les erreurs PHP récurrentes.
Même sans expertise forensique lourde, ces informations permettent d’orienter rapidement la correction de l’injection et d’éviter une réparation à l’aveugle.
Ce que signifie vraiment “supprimer malware WordPress” dans ce scénario
Supprimer malware WordPress, quand le vecteur principal est wp-config.php, veut dire trois choses, pas une seule:
Premièrement, vous éliminez le déclencheur dans wp-config.php en le remplaçant par une version fiable reconstruite à partir de la configuration légitime.
Deuxièmement, vous vérifiez qu’il n’y a pas https://gardewp.fr/nettoyage-malware-wordpress/ d’autres mécanismes de persistance ailleurs dans wp-content ou dans les comptes.
Troisièmement, vous fermez la porte qui a permis l’injection. Sinon, l’attaque revient, et vous repassez dans le même cycle.
C’est souvent cette troisième étape qui distingue une “réparation rapide” d’une restauration durable. Le site redevient alors quelque chose sur lequel vous pouvez redémarrer sereinement, avec des mises à jour et une hygiène de configuration solides.
Liste rapide des actions prioritaires après correction
Remplacer wp-config.php par une version saine, en copiant uniquement DB NAME, DBUSER, DB PASSWORD, DBHOST et $table_prefix, plus les clés de sécurité si vous les régénérez. Vérifier la disparition du comportement malveillant sur plusieurs pages et sur des scénarios simples (navigation, connexion admin). Réinitialiser les mots de passe et vérifier la liste des utilisateurs et leurs rôles. Contrôler plugins et thèmes actifs pour détecter des fichiers ajoutés ou des modifications suspectes. Durcir l’accès au serveur (permissions, comptes SFTP/SSH, suppression des accès inutiles) pour empêcher la réinjection.Si vous suivez cet enchaînement, vous ne vous contentez pas de “faire disparaître le symptôme”. Vous corrigez la cause la plus probable, puis vous réduisez fortement les chances que l’incident se reproduise.