Quand un site WordPress est “infecté”, l’histoire ressemble souvent à la même séquence: pages qui renvoient vers un autre endroit, surcharge CPU due à de l’activité cachée, admin qui reçoit des mots de passe réinitialisés sans demande, ou des fichiers PHP qui apparaissent là où rien n’a été déployé. Le réflexe naturel, c’est de “supprimer ce qui est visible”. Le problème, c’est que même quand les fichiers malveillants sont retirés, les accès peuvent rester ouverts. Les attaquants adorent une chose: survivre à la phase de nettoyage.
C’est pour ça que, dans un plan de nettoyage virus WordPress sérieux, le durcissement de wp-config.php et le renouvellement des clés de sécurité ne sont pas une option “propre sur le papier”. C’est une mesure de réduction de risque très concrète. Dans beaucoup de cas réels, elle fait la différence entre un site qui semble revenu à la normale… et un site qui redonne accès à quelqu’un qu’on n’a jamais retrouvé.
Pourquoi wp-config.php est un point de bascule
Wp-config.php n’est pas un simple fichier de configuration. C’est le cœur logique qui dit à WordPress comment parler à sa base de données, comment appliquer certaines constantes, et comment gérer la sécurité des sessions. Les “clés de sécurité”, connues sous le nom de Authentication Unique Keys and Salts, servent à signer et à dériver des jetons de session.
Quand ces valeurs sont compromises, ou quand l’attaquant a eu le temps de provoquer des changements avant le nettoyage, renouveler ces clés oblige WordPress à invalider les sessions existantes et à repartir sur des jetons reconstruits. Concrètement, c’est une façon de couper la continuité de l’accès, même si quelqu’un a réussi à se glisser dans une période précédente.
J’ai vu un cas où le site avait été “nettoyé” en supprimant des fichiers suspects, sans toucher wp-config.php. Les pages étaient revenues, le trafic avait baissé, mais deux jours plus tard, un compte admin se mettait à recevoir des connexions depuis des pays éloignés. Le renouvellement des clés a stoppé le phénomène, sans qu’on ait eu besoin de retrouver chaque ligne malveillante. Le fait que la menace ait pu rester en mémoire via des sessions ou des mécanismes dérivés du système de clés, ça, on ne le voit pas toujours au premier coup d’œil.
Ce que tu dois vérifier avant de modifier quoi que ce soit
Avant de toucher au fichier, je recommande une approche très pragmatique. Ne modifie pas en “mode chirurgie esthétique”. Modifie en “mode contrôle”.
D’abord, fais un inventaire rapide de ce que le site est en train de faire. Si tu vois une montée de charge, commence par limiter: mets le site en maintenance si ton CMS est accessible, ou active une page de blocage au niveau du serveur le temps de passer à l’étape de nettoyage. Ensuite seulement, tu te concentres sur wp-config.php.
Ensuite, prends des sauvegardes, mais pas “une sauvegarde vague”. Fais une copie du fichier wp-config.php et idéalement une copie de l’ensemble du répertoire WordPress et de la base de données (même si tu sais que tu vas restaurer moins que prévu). Quand un incident est en cours, “j’ai sauvegardé quelque part” n’a jamais la même valeur que “j’ai un artefact que je peux reposer en cinq minutes”.
Enfin, si tu as des droits limités, réfléchis à l’impact. Certaines modifications dans wp-config.php peuvent casser des comportements attendus, notamment sur des environnements de staging. Les clés de sécurité et certains réglages n’ont pas ce genre d’effet négatif, mais la discipline reste la même: tu veux pouvoir revenir en arrière sans panique.
Renouveler les clés de sécurité: l’impact réel
Dans wp-config.php, tu trouveras des constantes de la forme:
- AUTH_KEY SECURE AUTHKEY LOGGED INKEY NONCE_KEY AUTH_SALT SECURE AUTHSALT LOGGED INSALT NONCE_SALT
WordPress propose un générateur pour ces valeurs. L’idée n’est pas “de choisir au hasard une chaîne de caractères”. L’idée est de produire des valeurs suffisamment longues et imprévisibles, pour que les jetons dérivés soient reconstruits, et que les sessions existantes ne restent plus valables.
Renouveler ces clés ne “désinfecte” pas un fichier PHP injecté. Par contre, ça réduit la fenêtre d’accès post-incident. Même si l’attaquant avait pu établir une session, si ta modification est faite correctement, WordPress ne lui proposera plus un mécanisme cohérent pour garder ce contexte.
L’approche que j’utilise sur les sites déjà “nets”
Sur un site où tu as déjà fait le gros du nettoyage (suppression des fichiers injectés, réactivation d’un thème propre, retrait de plugins douteux), tu es souvent tenté de “finir vite”. C’est là que je prends une minute de plus pour faire le renouvellement de clés et forcer la réinitialisation des sessions.
La logique est simple: à partir du moment où le code est redevenu sain, le point faible devient souvent l’accès déjà installé. Les clés de sécurité, c’est une coupure nette.
Durcir wp-config.php sans casser WordPress
Modifier wp-config.php, ce n’est pas seulement “changer des clés”. Il y a aussi des constantes qui rendent l’attaque plus difficile ou moins probable. Le but est de réduire les opportunités, pas de transformer ton fichier en usine à gaz.
Voici les axes qui reviennent le plus souvent quand je vois des compromissions:
Exposition de détails en cas d’erreur Gestion prudente de la table de préfixe Variables qui laissent des traces ou des informations utiles à l’attaquant Cohérence des réglages liés aux cookies et au protocole
Attention à un point important: tout le monde copie des snippets au hasard. Certains conseils sur Internet sont trop permissifs, d’autres ne sont pas adaptés à ton mode d’hébergement. Je préfère dire les choses de manière opérationnelle, avec un jugement.
Affichage des erreurs: calmer le site
Un site compromis n’a pas besoin d’afficher des erreurs détaillées au navigateur. Les erreurs PHP affichées peuvent divulguer des chemins serveur, des versions, ou des indices qui aideront à ajuster l’attaque.
Dans wp-config.php, la configuration standard consiste à limiter l’affichage côté production. Tu veux journaliser au serveur ou utiliser un mécanisme interne, mais éviter de renvoyer des détails à l’utilisateur public.
Sur un incident, ça te sert doublement. D’un côté, tu réduis le bruit et la surface d’information. De l’autre, tu limit es aussi les “cicatrices” côté navigation, parce que certains plugins de debug ou de cache peuvent relayer des détails.
Préfixe des tables: utile, mais pas une barrière magique
Le préfixe des tables WordPress, souvent “wp_” par défaut, n’est pas un secret au sens strict. Mais sur des attaques automatisées, un préfixe standard simplifie la vie des scripts. Si ton installation a un préfixe “par défaut”, ça mérite une attention.
Cela dit, changer le préfixe après coup n’est pas trivial. C’est faisable, mais ça implique des modifications dans la base de données et potentiellement https://gardewp.fr/nettoyage-malware-wordpress/ des ajustements WordPress. Je le traite comme un sujet à part entière, pas comme une action “pendant que tu es en train de nettoyer”.
Si tu es déjà dans l’urgence, commence par les changements à faible risque, comme le renouvellement des clés et la suppression des sessions existantes. Ensuite, tu peux décider si tu veux aller plus loin pour le préfixe.
Cookies et protocole: éviter les comportements bizarres
Quand un attaquant cherche à garder la main, il teste souvent des variantes de protocole, http au lieu de https, ou des réglages de domaine qui déclenchent des incohérences de cookies. Wp-config.php ne remplace pas une configuration serveur bien faite (redirects, TLS, en-têtes), mais une cohérence ici aide.
Si ton site est derrière un proxy ou un load balancer, il peut y avoir des cas où WordPress ne “voit” pas correctement le protocole réel. Dans ce scénario, les erreurs de redirection et les cookies peuvent provoquer des comportements qui ressemblent à une “instabilité” de sessions. Et quand tu vois une instabilité de sessions, tu comprends pourquoi l’attaquant peut en profiter.
Je n’entre pas dans une liste de constantes au hasard, parce que le bon réglage dépend de ton architecture. Mais retiens ceci: si tu as eu des manipulations de domaine, de proxy, ou de certificats au moment de l’incident, revalide la cohérence des réglages de cookies.
Étape par étape, mais sans se tromper d’objectif
On peut séparer l’action “nettoyage virus WordPress” en deux objectifs: enlever la partie visible et invalider la partie persistante. Le premier objectif vise les fichiers et les plugins. Le second objectif passe par les sessions, les clés et une mise à l’échelle de la confiance.
Voici comment j’organise la partie “wp-config.php et sessions” dans un incident.
La séquence que je fais sur wp-config.php
Sauvegarde wp-config.php et vérifie que tu sais le restaurer. Vérifie que les valeurs de clés de sécurité existent bien et qu’elles ne sont pas déjà remplacées par des constantes modifiées de manière suspecte. Regénère les Authentication Unique Keys and Salts, puis remplace les huit constantes dans wp-config.php. Vérifie que le site reste en état de fonctionner (au moins pages principales, connexion admin, pages de formulaire). Recontrôle les sessions après quelques minutes, et force une déconnexion généralisée si nécessaire en complément côté comptes.Cette liste est volontairement courte, parce que les incidents ne pardonnent pas les “bonus inutiles” pendant que tu es en pleine crise.
Ce que les clés ne font pas (et comment ne pas se tromper)
Il y a une tentation fréquente: croire que le renouvellement des clés de sécurité “efface le malware”. Ce n’est pas le cas.
Les clés changent surtout la validation des jetons, donc l’accès via sessions déjà établies. Si un plugin malveillant ou un script injecté est encore présent, il peut continuer à exécuter du code à chaque requête, à récupérer des données, ou à réinjecter des contenus.
C’est pour ça qu’un bon plan inclut toujours, en parallèle, une vérification du code.
Dans les cas où je vois les plus gros retours, c’est souvent pour deux raisons: La suppression a été partielle, par exemple seul un fichier a été retiré alors que le code d’amorçage reste ailleurs Ou des identifiants ont été réutilisés sur d’autres systèmes, et l’attaque repart par une réinitialisation de mots de passe ailleurs, pas sur le site lui même
Renouveler les clés aide à casser la continuité, mais ne remplace pas l’analyse du périmètre.
Forcer le “coupure d’accès” côté comptes après incident
Même si les clés invalident beaucoup de choses, tu ne veux pas compter sur un seul mécanisme. Les attaquants ciblent aussi les mots de passe, les rôles, les utilisateurs qui ont des capacités élevées, et parfois des comptes nouvellement créés.
Si tu n’as jamais vu de compte admin créé après coup, tu peux croire que c’est rare. Sur certains environnements partagés, ou quand des identifiants ont fuité, c’est plus fréquent qu’on ne l’imagine. On retrouve alors des utilisateurs “fantômes” ou des rôles anormaux.
Tu peux limiter la casse avec deux gestes qui vont ensemble: vérifier les utilisateurs et leurs rôles, puis forcer une rotation des mots de passe pour les comptes à privilèges. Selon ton niveau de risque et le temps disponible, tu peux aussi verrouiller temporairement les connexions ou appliquer des règles de rate limiting côté serveur.
Je préfère aussi supprimer les comptes superflus ou de test devenus inutiles. En incident, un compte “en trop” est souvent un point d’entrée oublié.
Les pièges courants pendant le durcissement
Certains problèmes arrivent après la modification de wp-config.php, pas avant. Ça vaut le coup de connaître les pièges pour garder ton sang froid.
Le premier piège, c’est la confusion entre WordPress et l’environnement d’hébergement. Si tu utilises un serveur cache agressif, ou un reverse proxy, des changements dans wp-config.php peuvent déclencher des redirections ou des comportements liés aux cookies. Le site peut avoir l’air cassé pendant quelques minutes, le temps que le cache se stabilise.
Le deuxième piège, c’est l’édition directe sans cohérence. Sur un incident, des gens copient et collent des extraits en oubliant des guillemets, des séparateurs, ou des lignes. Résultat: 500 interne ou écran blanc. La sauvegarde et la capacité à revenir en arrière deviennent alors une assurance psychologique.
Le troisième piège, c’est la confiance dans “une version du fichier” qui n’est pas celle réellement utilisée. Si tu as plusieurs WordPress, plusieurs répertoires, ou un fichier symlinké, tu peux modifier un wp-config.php qui n’est pas le bon. Sur des hébergements compliqués, j’ai déjà vu deux fichiers presque identiques, un en prod et un en build, et des heures de diagnostic perdues avant de comprendre.
Une mini check de fin de nettoyage, axée sécurité
Une fois que tu as retiré ce qui était injecté et que tu as régénéré les clés, il faut valider que le site se comporte comme attendu sur la partie accès.
Je termine souvent par une séquence de vérification rapide, pas forcément automatisée, mais cohérente.
Vérifier la liste des utilisateurs et supprimer ceux qui n’ont pas de raison d’exister. Contrôler que la connexion admin fonctionne et que les sessions ne sont plus valides depuis l’extérieur. Recontrôler la présence de fichiers suspects dans les répertoires qui chargent du PHP. Vérifier les plugins et thèmes installés, en supprimant ceux qui étaient actifs mais non nécessaires. Rechercher des changements inattendus dans wp-config.php après coup, et confirmer que le contenu correspond à ta version “propre”.Cette vérification est courte, mais elle couvre l’essentiel: accès, persistance, et cohérence du code.
Comment réduire le risque après un incident (sans surcharger)
Durer la sécurité, ce n’est pas empiler un maximum d’outils. C’est créer un environnement où l’attaque trouve peu de prise et où la détection arrive tôt.
Voici les mesures qui reviennent le plus, basées sur ce que j’ai vu marcher en maintenance:
- mettre à jour WordPress, plugins et thèmes quand c’est raisonnable, sans attendre des mois après une vulnérabilité limiter les droits des comptes et éviter les comptes “admin” utilisés quotidiennement renforcer l’accès à l’administration, par exemple via une combinaison de protection et d’authentification renforcée quand elle est compatible utiliser une politique de sauvegardes testées, où la restauration est une opération réelle, pas une promesse surveiller les changements de fichiers, surtout dans les chemins où un implant peut se cacher
Ce dernier point, sur la pratique, change la donne. Quand tu reçois une alerte le jour même, tu n’en arrives pas à réparer au hasard. Tu remets en état de manière plus propre.
Cas concrets: quand ça se joue sur la continuité des sessions
Je reviens sur l’idée centrale: le nettoyage “visible” est souvent nécessaire, mais insuffisant pour couper la continuité d’accès.
Dans une intervention précédente, l’attaquant avait laissé une porte discrète en ajoutant un petit code dans un fichier qui n’était pas dans le thème actif. Le code ne s’exécutait pas tout le temps, il réagissait à certains paramètres. On a supprimé le point visible, et tout semblait propre. Deux jours plus tard, une session admin “réapparaissait” pour un utilisateur qui n’avait pas modifié son mot de passe depuis longtemps.
En régénérant les clés de sécurité et en invalidant les sessions, l’utilisateur ne pouvait plus rester connecté. Le site est resté stable après suppression du reste du mécanisme. Ce qui m’a frappé, c’est que l’incident avait survécu non pas grâce à un fichier constamment actif, mais grâce à une forme de continuité au niveau des jetons.
C’est aussi pour ça que dans une démarche sérieuse, tu ne fais pas “nettoyage virus WordPress” en une seule passe, puis tu pars. Tu fais une passe, tu coupes l’accès, puis tu surveilles le comportement.
Conclusion pragmatique sur wp-config.php et la suite
Si tu veux retenir une méthode utile, retiens celle-ci: pendant un incident, wp-config.php devient un endroit où tu consolides une barrière. Les clés de sécurité, changées au bon moment, sont une façon de forcer WordPress à abandonner les contextes de session déjà construits. Ce n’est pas une baguette magique, mais c’est une étape qui a un rendement très élevé en comparaison du temps passé.
Le bon déroulé ressemble à un mélange de rigueur et d’urgence contrôlée: sauvegarder, nettoyer le code malveillant, régénérer les clés de sécurité, vérifier les comptes, puis confirmer que la menace ne revient pas. C’est moins “spectaculaire” que de supprimer des fichiers au marteau, mais c’est souvent plus efficace.
Si tu me dis ton contexte (hébergement avec proxy, présence de WAF, version WordPress, et ce que tu as déjà retiré), je peux te proposer une séquence plus adaptée pour sécuriser wp-config.php sans risquer de casser ton environnement.