Un site WordPress piraté crée toujours le même mélange de panique et de frustration. Le téléphone qui sonne, les clients qui ne peuvent plus commander, Google qui affiche un avertissement rouge, ou pire, l’hébergeur qui coupe le site pour « activité malveillante ». Dans ces moments où l’on cherche une urgence WordPress piraté sur Google en espérant un remède miracle, il y a un fichier qui peut faire une vraie différence si l’on sait quoi en faire : wp-config.php.
On ne nettoie pas une infection uniquement dans wp-config.php, loin de là. Mais c’est un point de contrôle critique pour reprendre la main, limiter les dégâts, durcir l’accès et préparer un nettoyage propre. J’ai vu trop de situations où quelques lignes bien posées dans ce fichier auraient évité 48 heures de chaos.
Ce texte part de ce vécu là. L’objectif est simple : vous montrer, concrètement, quoi changer dans wp-config.php quand votre site est compromis, dans quel ordre, avec quelles précautions, et ce qu’il ne faut surtout pas faire.
Avant de toucher à wp‑config : quelques minutes qui peuvent sauver le site
Quand un site vient de se faire pirater, la tentation est énorme d’ouvrir le premier fichier venu et de tout modifier. C’est humain. Pourtant, ce réflexe complique souvent l’analyse et le nettoyage.
La première chose à faire consiste à capturer l’état du site et à réduire la surface d’attaque sans casser davantage la production. Dans mon expérience, les cinq premières minutes bien utilisées changent la suite.
Voici un court checklist d’intervention immédiate, avant même de sauver wp-config.php :
- Sauvegarder tout le site tel quel : fichiers + base de données, même infectés Noter les symptômes observés : redirections, spam, formulaires détournés, fichiers inconnus Changer tous les accès techniques : FTP / SFTP, SSH, phpMyAdmin, compte admin WordPress Mettre le site derrière une page de maintenance si le business le permet Vérifier les mails de l’hébergeur : avis d’abus, logs, informations sur les fichiers suspects
Une fois ce minimum posé, on peut ouvrir wp-config.php avec un peu plus de sang‑froid et surtout un plan clair.
Comprendre le rôle stratégique de wp‑config dans une urgence
wp-config.php n’est ni un simple fichier de configuration ni un simple connecteur de base de données. Il joue trois rôles essentiels pendant un incident de sécurité.
D’abord, il concentre les accès critiques : identifiants de base de données, préfixe de tables, secrets de chiffrement. Si l’attaquant y a touché, il a probablement une porte d’entrée très profonde sur votre installation.
Ensuite, il contrôle certains comportements de WordPress souvent sous‑estimés : activation de l’éditeur de fichiers, gestion des mises à jour automatiques, débogage, connexions sécurisées, cron interne, etc. En situation de crise, ces options deviennent des leviers pour prendre du recul, enquêter ou limiter les dégâts.
Enfin, tout ce que contient wp-config.php s’exécute à chaque chargement de WordPress. C’est à la fois un avantage et un risque. Un pirate qui y ajoute une ligne de code a potentiellement la main sur chaque requête. De votre côté, une directive mal placée peut mettre le site à genoux.
C’est précisément pour cela que le premier réflexe, une fois la sauvegarde faite, consiste à vérifier si ce fichier n’a pas été détourné.
Première inspection de wp‑config : reconnaître les signaux inquiétants
Dans un cas classique d’intrusion, wp-config.php reste techniquement valide. Le site continue de fonctionner, mais quelques lignes toxiques se sont glissées au milieu du reste. Ce n’est pas toujours criant, surtout sur un fichier déjà commenté ou retravaillé par plusieurs personnes.
Les éléments suspects les plus fréquents que j’ai croisés sont les suivants.
Des lignes de code PHP étranges, souvent avant la ligne <?php ou tout en bas du fichier, après le commentaire qui mentionne « C’est tout, ne touchez pas à ce qui suit ». Par exemple un eval(base64_decode('...'));, parfois découpé sur plusieurs lignes, ou des include qui pointent vers un fichier aux noms aléatoires dans wp-includes ou wp-content.</p>
Des variables longues et illisibles, une sorte de soupe de caractères, rangées dans un $_POST, $_GET ou $_COOKIE, suivies d’un eval ou d’un assert. Ce type de code est presque toujours malveillant, surtout dans wp-config.php.
Une redéfinition étrange des constantes classiques de WordPress, ou de chemins système, qui détourne les inclusions vers un fichier infecté. Par exemple un ABSPATH qui pointe sur un sous‑dossier inhabituel ou un WP_CONTENT_DIR qui renvoie vers un répertoire masqué.
Dès que vous repérez des lignes de ce type, notez les chemins de fichiers mentionnés. D’expérience, un include malveillant dans wp-config.php pointe souvent vers un loader, qui lui‑même charge d’autres backdoors. Toucher au coeur de WordPress sans suivre ces traces fait perdre du temps.
Si vous avez une sauvegarde saine et récente du fichier, le plus rapide consiste à le comparer ligne par ligne, avec un outil de diff local ou directement dans le panneau d’administration de l’hébergeur. Toute différence non explicable par une mise à jour ou une modification connue doit être passée au crible.
Quand et comment changer les identifiants de la base de données
Lorsqu’un site est compromis, beaucoup de développeurs se ruent sur la base de données avant de vérifier si ces identifiants ont, eux aussi, fuité. Or un wp-config.php exposé (téléchargé via une faille de configuration serveur, par exemple) donne accès à tout le contenu de la base.
Changer le mot de passe du compte MySQL utilisé par WordPress figure dans le haut de la liste des gestes d’urgence.
Concrètement, il s’agit de créer un nouveau mot de passe fort pour l’utilisateur de base de données, ou carrément un nouveau compte si vous suspectez que l’ancien a été partagé, puis de le reporter dans les lignes DB_USER, DB_PASSWORD, éventuellement DB_HOST si vous en profitez pour adopter une configuration plus propre. Il est prudent de le faire en dehors des heures de pointe si le site est encore accessible, pour limiter l’impact d’une éventuelle erreur.
Une erreur fréquente consiste à modifier DB_NAME pour « repartir sur une base propre » sans préparation. Si vous changez de base de données sans sauvegarde et sans migration, vous risquez de perdre tout le contenu. En phase d’urgence, on touche au mot de passe, pas au nom de base, sauf stratégie de restauration bien définie.
Si l’on suspecte un accès prolongé à la base (injection de comptes admin cachés, création de tables pour spam, etc.), cette opération doit s’accompagner d’un audit SQL, mais ce travail dépasse le rôle direct de wp-config.php. Le simple fait de couper l’accès avec un nouveau mot de passe permet déjà de bloquer des scripts externes qui continuent à exploiter la faille.
Régénérer les clés de sécurité pour invalider toutes les sessions
Beaucoup de propriétaires de sites ignorent à quoi servent les fameuses constantes AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs équivalents en « salts ». Dans un contexte d’attaque, elles jouent pourtant un rôle clé : elles signent les cookies et les nonces. Les modifier invalide toutes les sessions existantes.
En d’autres termes, toute personne connectée à l’admin, y compris l’attaquant, est immédiatement déconnectée. Sur un site piraté, c’est exactement ce que l’on souhaite.
Concrètement, on se rend sur le générateur officiel de clés de sécurité WordPress (fourni par l’équipe du CMS), on copie les nouvelles lignes générées, puis on remplace dans wp-config.php l’intégralité des huit lignes de clés et de « salts », sans en oublier une seule. On enregistre, et dès la requête suivante, WordPress considère que tous les cookies de connexion existants sont obsolètes.
Deux points de vigilance issus du terrain. D’abord, prévenez l’équipe que tout le monde va être déconnecté, pour ne pas affoler les utilisateurs internes au milieu d’une intervention. Ensuite, ne modifiez pas ces clés dans l’urgence si vous n’avez pas la main sur le fichier via un accès fiable. Une mauvaise copie, un caractère manquant, et le site peut afficher une erreur fatale.
Mais bien utilisé, ce changement de clés fait partie du trio le plus utile en cas de piratage : modification des mots de passe d’accès, rotation des clés, et nettoyage des comptes admin dans l’interface.
Désactiver la modification de fichiers depuis l’admin
Une fois qu’un https://gardewp.fr/ pirate dispose d’un compte administrateur, même temporaire, l’éditeur de fichiers intégré à WordPress devient une arme redoutable. Il permet de modifier les fichiers de thème ou de plugins directement depuis l’interface, sans passer par FTP ni SSH, et souvent sans surveillance de l’hébergeur.
Dans un contexte d’urgence, il faut couper cette possibilité.
La constante à utiliser est relativement simple : on ajoute dans wp-config.php une directive DISALLOW_FILE_EDIT réglée sur true. À partir de ce moment, l’onglet « Éditeur de fichiers de thème » dans l’admin disparaît, de même que l’éditeur de plugins.
On peut aller plus loin avec DISALLOW_FILE_MODS qui interdit également les mises à jour et l’installation de plugins et thèmes depuis l’interface. Je le réserve aux situations où l’on soupçonne un usage intensif de l’interface par l’attaquant, ou quand on veut figer le site pendant le temps du diagnostic. Le revers de la médaille est simple : vous ne pouvez plus mettre à jour WordPress depuis le back‑office tant que cette constante reste active.
Sur des sites à fort enjeu, j’ai vu des équipes choisir de laisser DISALLOW_FILE_EDIT en permanence, piratage ou pas, juste pour réduire la surface d’attaque. En phase de crise, cette directive est presque toujours une bonne idée.
Forcer l’accès administrateur en HTTPS
Beaucoup de piratages ne viennent pas d’une faille logicielle, mais d’un vol d’identifiants sur un https://gardewp.fr/site-wordpress-pirate/ réseau peu sûr. Un admin qui se connecte à son WordPress en HTTP dans un café ou un hôtel, un pirate qui intercepte le cookie de session, et le compte est compromis sans la moindre vulnérabilité de plugin.
wp-config.php permet justement de forcer l’utilisation de HTTPS sur l’espace d’administration avec la constante FORCE_SSL_ADMIN. Ce réglage ne corrige pas un piratage en cours, mais il évite d’alimenter le feu pendant que vous nettoyez.
Sur un site déjà sous HTTPS, ajouter cette directive est presque toujours neutre : WordPress forcera la connexion et l’admin sur HTTPS, même si quelqu’un essaie de passer par un lien HTTP ancien. Sur un site mal configuré, en revanche, cela peut provoquer des boucles de redirection. Avant de l’activer, vérifiez que votre certificat SSL est valide et que l’URL de connexion fonctionne déjà en HTTPS.
En contexte d’urgence, ce réglage se combine bien avec la rotation des mots de passe et des clés de sécurité. On ferme la brèche logicielle, on coupe les sessions existantes, et on durcit les futures connexions.
Activer un mode diagnostic sans exposer du code aux visiteurs
L’un des réflexes les plus naturels face à un bug ou un comportement étrange consiste à activer WP_DEBUG et à regarder les messages d’erreur. Sur un site piraté, cette idée peut sembler utile, mais elle est à manier avec prudence.
Afficher les warnings et notices PHP sur le site public peut révéler des chemins de fichiers, des informations d’environnement, voire des requêtes SQL, autant de cadeaux pour un attaquant qui surveille encore le site.
La meilleure approche consiste à utiliser WP_DEBUG combinée à WP_DEBUG_LOG et éventuellement WP_DEBUG_DISPLAY mis sur false. De cette manière, les erreurs sont consignées dans un fichier de log, généralement dans wp-content/debug.log, sans être montrées aux visiteurs.
En phase de crise, ces logs peuvent révéler des inclusions de fichiers bizarres, des fonctions inconnues, des erreurs dans des scripts injectés. Ils deviennent un outil d’enquête plus qu’un simple outil de développement. À une condition : bien penser à les désactiver ou à les limiter une fois l’urgence passée, pour éviter de générer un fichier de log énorme qui masque les signaux utiles.
Dans certains cas, j’ai vu des attaquants laisser volontairement des erreurs en place pour brouiller les pistes et faire croire à un simple bug. Un regard sur les logs de debug permet parfois de distinguer ce qui est vraiment un dysfonctionnement applicatif de ce qui fait partie du plan du pirate.
Utiliser les constantes de maintenance pour contrôler les mises à jour
Quand un site est compromis, la tentation est grande de cliquer sur toutes les mises à jour possibles en espérant que la dernière version corrige la faille utilisée. C’est parfois vrai, mais pas toujours. Et lancer une mise à jour majeure en plein incident ajoute une variable difficile à maîtriser.
On peut utiliser certains réglages dans wp-config.php pour garder la main sur les mises à jour. Par exemple, limiter les mises à jour automatiques aux versions mineures, ou au contraire les désactiver temporairement si l’on veut figer l’environnement pendant l’analyse.
Sur des sites attaqués via une mise à jour mal contrôlée, j’ai parfois bloqué tout changement logiciel via DISALLOW_FILE_MODS, combiné à une politique de restauration depuis une sauvegarde saine, avant de remettre progressivement les mises à jour en marche, avec un suivi plus strict.
Le but, ici, n’est pas de transformer wp-config.php en tableau de bord complet de mise à jour, mais de s’en servir pour éviter les mauvaises surprises en pleine urgence.
Quelques constantes utiles en contexte d’urgence
De nombreuses constantes peuvent être ajoutées ou ajustées dans wp-config.php pour mieux gérer la phase de crise. Certaines servent à renforcer la sécurité, d’autres à contrôler des fonctionnalités de WordPress qui peuvent gêner le diagnostic.
Voici un second ensemble de réglages courants qui méritent d’être envisagés dans un contexte d’intrusion :
- AUTOSAVE_INTERVAL et WP_POST_REVISIONS pour limiter un peu le bruit en base pendant un audit intensif de contenu WP_MEMORY_LIMIT pour éviter que WordPress ne tombe au moindre scan ou script d’analyse un peu gourmand WP_CACHE pour désactiver temporairement certains cacheurs pendant le nettoyage si l’infection est servie depuis le cache WP_ALLOW_REPAIR pour réparer et optimiser les tables MySQL, à condition de n’activer cela que ponctuellement puis de le retirer ALTERNATE_WP_CRON ou la désactivation temporaire du cron interne si un script malveillant s’y accroche
L’idée n’est pas de tout activer d’un coup. En situation de stress, chaque changement doit être motivé et documenté, même grossièrement, dans un fichier texte ou un outil de suivi partagé. Les urgences WordPress qui dégénèrent le plus sont celles où plusieurs personnes modifient wp-config.php sans se coordonner, en laissant parfois des constantes contradictoires.
Faut‑il restaurer ou réécrire complètement wp‑config ?
Lorsque le fichier est manifestement corrompu, beaucoup se demandent s’il vaut mieux le restaurer depuis une sauvegarde ou repartir d’un wp-config.php tout neuf généré à partir du script d’installation WordPress.
Les deux approches ont leurs mérites. Restaurer depuis une sauvegarde a l’avantage de conserver toutes les particularités du site : préfixe de table éventuellement personnalisé, encodage, réglages spécifiques, etc. Mais il suppose que la sauvegarde soit saine. Or, dans pas mal de cas, l’infection est ancienne et les sauvegardes disponibles sont déjà contaminées.
Réécrire un wp-config.php propre à partir de zéro permet de repartir sur une base minimale. On copie les valeurs connues (nom de base, utilisateur, mot de passe, hôte), on colle des clés de sécurité nouvelles, on ajoute progressivement les constantes spécifiques que l’on sait nécessaires. On évite ainsi de réintroduire du code malveillant caché dans un commentaire ou une ligne anodine.
Une approche mixte fonctionne bien en pratique. On pose à côté de l’actuel un fichier temporaire, par exemple wp-config-clean.php, dans lequel on recopie manuellement uniquement ce qui est strictement nécessaire, après contrôle, puis on remplace l’ancien en renommant. Cette technique demande un peu plus de rigueur, mais elle a le mérite de casser la logique « copier ‑ coller aveugle » depuis une sauvegarde potentiellement infectée.
Gérer les edge cases : multisite, environnements de staging, préfixes exotiques
Tous les WordPress ne se ressemblent pas. Quelques cas particuliers compliquent légèrement l’usage de wp-config.php en situation de piratage.
Sur un multisite, certaines constantes comme DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE, SITE_ID_CURRENT_SITE ou BLOG_ID_CURRENT_SITE deviennent très sensibles. Les modifier sans comprendre la topologie du réseau de sites peut tout casser. En cas de piratage sur un multisite, je recommande de se concentrer d’abord sur la rotation des clés, les droits d’écriture, les accès FTP/SSH et l’audit des comptes super‑admin, plutôt que de tripoter ces constantes à chaud.
Sur des environnements avec staging ou préproduction, on trouve parfois plusieurs fichiers wp-config chaînés, ou des wp-config.local.php inclus conditionnellement. Si un pirate a touché à ces fichiers annexes, restaurer uniquement le wp-config.php principal ne suffit pas. Il faut inspecter tout ce qui est inclus, et vérifier les routes d’accès à la base et aux fichiers. C’est souvent dans ces environnements intermédiaires, moins protégés, que l’attaque commence.
Les préfixes de table exotiques, enfin, méritent un mot. Changer le préfixe par défaut wp_ est souvent présenté comme une mesure de sécurité. Cela ne suffit pas, mais cela complique certains scripts automatisés d’injection SQL. Lorsqu’un site piraté utilise déjà un préfixe original, n’y touchez surtout pas dans l’urgence. Changer de préfixe à chaud sans migration scriptée casse immédiatement tous les liens entre WordPress et sa base de données.
Après l’urgence : quoi laisser dans wp‑config et quoi retirer
Une fois le site propre, analysé, et les accès consolidés, vient la phase plus calme où l’on fait le bilan de ce que l’on a ajouté dans wp-config.php pendant la crise.
Certaines constantes gagnent à rester en place sur le long terme : DISALLOW_FILE_EDIT, forçage HTTPS pour l’admin, préfixe de table personnalisé si tout est stable. Elles augmentent la résilience du site à moindre coût.
D’autres doivent être désactivées ou ajustées. L’activation permanente du debug, par exemple, la réparation automatique de base via WP_ALLOW_REPAIR, la désactivation totale des mises à jour, ou une mémoire PHP démesurée juste pour faire tourner un script unique. Garder ces réglages en place revient à laisser les outils d’urgence ouverts en continu, avec tous les risques associés.
Le fichier wp-config.php doit idéalement retrouver un état simple, lisible, commenté avec sobriété. Dans une perspective de maintenance, quelques commentaires clairs sur les raisons de certaines constantes liées à l’incident peuvent aider les futurs intervenants. Un jour, quelqu’un tombera à nouveau sur ce fichier en pleine nuit, et ce petit contexte évitera peut‑être un faux pas.
Au final, wp-config.php n’est pas un antidote magique contre les piratages de WordPress. C’est un tableau électrique. Mal géré, il laisse des disjoncteurs inutiles enfoncés et des câbles nus. Bien utilisé, il coupe les circuits au bon endroit, sécurise l’accès, et fournit une base plus saine pour un nettoyage en profondeur.
Dans les urgences WordPress piraté que j’ai accompagnées, ceux qui connaissaient ce fichier et savaient quelles lignes modifier ont toujours gagné des heures précieuses. Non pas en effaçant l’attaque d’un coup de baguette, mais en reprenant le contrôle, méthodiquement, là où WordPress est le plus vulnérable ou le plus malléable. C’est exactement ce contrôle que vous cherchez à retrouver lorsque votre site commence à faire ce qu’il ne devrait jamais faire.