wp-config.php compromis : clés, préfixe et backdoor
Des clés AUTH réécrites, une ligne `include` ajoutée, un préfixe de tables changé : `wp-config.php` n'est pas un fichier « à restaurer depuis un tuto ». On le relit ligne à ligne, on régénère les clés, on change le mot de passe MySQL.
Des clés AUTH réécrites, une ligne include ajoutée, un préfixe changé. Régénérez les clés, changez les mots de passe de base, relisez le fichier ligne à ligne.
Ouvrir le fichier, pas le remplacer au hasard
`wp-config.php` contient le mot de passe de la base et les clés de session. Un modèle téléchargé sur un blog n'a pas vos identifiants. Un overwrite « vierge » = site cassé + vous recollez les secrets dans un chat. Copiez le fichier actuel hors serveur, puis éditez.
Comparez à un `wp-config-sample.php` de votre version : tout ce qui n'est pas une constante documentée mérite une phrase. Les blocs `if (!defined` ajoutés en bas sont le lieu habituel.
Copiez `wp-config.php` hors serveur, puis relisez-le contre `wp-config-sample.php`. Tout ce qui n'est pas une constante documentée mérite une phrase. Les `include` / `require` / `eval` en bas ou dans un `wp-config-extra.php` sont le lieu habituel. Un modèle téléchargé sur un blog n'a pas vos identifiants : ne l'écrasez pas. Changez le mot de passe MySQL dans le panel puis dans le fichier. Tant que le panel est l'ancien secret, quelqu'un réécrit ce fichier après vous.
Si vous ne pouvez pas lire le fichier (permissions, panel coupé), l'archive hébergeur est la voie. Ne le téléchargez pas depuis un gist. Un wp-config « modèle » recollé à la main oublie les constantes réseau (multisite) et casse le boot. Copie, puis édition.
L'include et le require discrets
`include('wp-content/uploads/cache/.ico');`, `require_once ABSPATH . 'wp-core.php';`, un `eval(gzinflate`. Une seule ligne. Grep `include`, `require`, `eval`, `assert`, `file_get_contents` dans ce fichier.
Parfois l'include est dans un second fichier appelé par le premier (`wp-config.php` n'a que `include 'wp-config-extra.php'`). Lisez la chaîne.
Les thèmes nulled ajoutent ça à l'activation. Thème nulled.
Clés AUTH et salts
Après un accès admin ou une fuite du fichier, régénérez les huit clés (générateur wordpress.org). Toutes les sessions tombent. C'est voulu. Les application passwords : révoquez-les dans l'admin une fois rentré.
Si les clés ont déjà été réécrites par l'attaquant, régénérez encore : vous ne savez pas à qui il les a données.
Identifiants base et préfixe
Changez le mot de passe MySQL dans le panel, puis dans `wp-config.php`. Un attaquant avec l'ancien secret lit `wp_options` demain. Le user MySQL ne doit pas être `root` partagé par vingt sites.
Un `$table_prefix` modifié peut pointer vers d'autres tables (un second WP dans la même base, déjà sale). Vérifiez que les tables existent et sont les vôtres. Ne « devinez » pas un préfixe.
Après changement du mot de passe MySQL, testez wp-cli `db check` ou une page. Un user MySQL trop large (tous les blogs du serveur) : restreignez. Vingt sites, vingt secrets, ou au moins pas root.
Debug, FS_METHOD, constantes pirates
`WP_DEBUG` true en prod après un hack : logs publics si `WP_DEBUG_LOG` écrit dans `wp-content/debug.log` (souvent accessible). Coupez, retirez le log du web. `DISALLOW_FILE_EDIT` true : bien, après. `FS_METHOD` ftpext avec des identifiants en clair : hors de ce fichier si possible.
Des `define('WP_HOME'` vers un domaine tiers : même famille que wp-admin redirige.
Permissions et copies
644, pas 777. Pas de `wp-config.php.bak`, `.old`, `.txt` à la racine : les bots les téléchargent. `installer.php` et les dumps `.sql` aussi. Duplicator.
Git public avec wp-config : révoquez tout, considérez les secrets lus. Ce n'est plus « un petit oubli ».
Après édition : sessions mortes
Reconnectez-vous. Vérifiez users. Si vous n'entrez plus : typo dans le mot de passe base, ou `siteurl` encore sale. WP-CLI / phpMyAdmin.
Chasse habituelle ensuite. Un wp-config propre avec un mu-plugin sale = théâtre. Backdoor.
Le panel plus fort que wp-config
Tant que le mot de passe o2switch / OVH / cPanel est l'ancien, quelqu'un réécrit wp-config après vous. Ordre des secrets : panel, FTP, puis ce fichier. Par où commencer.
WordPress piraté, créer un espace.
Régénérez les huit clés AUTH : toutes les sessions tombent, c'est voulu. Pas de `.bak` / `.old` à la racine. Permissions 644. La chasse continue : un wp-config propre avec un mu-plugin sale est du théâtre. Backdoor PHP. WordPress piraté, créer un espace.
Git public, debug.log, et préfixe de tables
Un dépôt git public avec wp-config : considérez les secrets lus, révoquez tout. Ce n'est plus un oubli. `WP_DEBUG` true + `debug.log` accessible : retirez le log du web. Changer le `$table_prefix` après un hack est cosmétique et casse des plugins : changez le mot de passe MySQL plutôt. Le user MySQL ne doit pas être `root` partagé par vingt sites.
Multisite : un wp-config, une ligne include, tout le réseau. Multisite. Un fichier disparu alors que le site marche : copie au-dessus du webroot, ou cache. Cherchez toutes les copies.
Panel d'abord, toujours. Par où commencer. Créer un espace.
Relecture ligne à ligne : quoi garder
Gardez : identifiants base (mot de passe déjà changé), préfixe vrai, clés tout juste régénérées, WP_DEBUG false, DISALLOW_FILE_EDIT true après, SSL si c'est vous, mémoire raisonnable. Jetez : include inconnus, eval, WP_HOME vers un tiers, FS_METHOD avec secrets FTP en clair, tout fichier extra appelé. Sample.php est la référence, pas un tuto de 2014.
Pas de .bak à la racine. 644. Git : secrets révoqués. Par où commencer. Créer un espace.