WP_DEBUG laissé à true après (ou avant) un piratage

Ce que le visiteur n'aurait jamais dû voir

Un bandeau d'erreurs PHP en haut de la home, un chemin `/home/clients/…/wp-content/plugins/…`, le nom d'une base, un warning qui cite une clé. `WP_DEBUG` et `WP_DEBUG_DISPLAY` en production transforment votre vitrine en notice board. L'attaquant n'a pas toujours besoin d'un `phpinfo` : vous avez déjà allumé la lampe.

Après un piratage, ces notices aident parfois à voir un plugin cassé. Elles aident aussi le suivant à viser la bonne version. On les coupe pour le public, on les lit ailleurs.

Ce n'est pas l'alerte Chrome « site trompeur ». C'est plus discret, plus fréquent, et ça précède souvent l'incident : un prestataire a « débogué en live » et n'a pas refermé. phpinfo encore en ligne est le cousin plus bruyant.

Debug n'est pas un nettoyage

Activer le debug « pour trouver le malware » noie le HTML et ne compare aucun fichier à son zip. Désactiver le debug « pour que ça ait l'air propre » cache un thème encore injecté. Les deux gestes se font, dans cet ordre : constater (copie, fichiers), puis éteindre l'affichage public si ce n'est déjà fait.

Un stack trace n'est pas une backdoor. Une backdoor n'a pas besoin d'un stack trace. Ne confondez pas bruit PHP et payload.

Les premiers gestes n'incluent pas « passer debug à true ». Ils incluent une copie. Le debug, s'il était déjà on, fait partie de l'état à figer (captures).

Couper l'affichage, garder le journal

Le couple utile en prod, quand on doit encore diagnostiquer : debug écrit dans un fichier, affichage à `false`. Le fichier hors webroot, ou protégé, pas un `debug.log` téléchargeable dans `wp-content`. Les bots cherchent précisément ce chemin.

Si `debug.log` est déjà public, considérez qu'il a été lu : chemins, plugins, parfois des requêtes. Retirez-le du web, tournez ce qui a pu fuir, comme pour un `.env` en plus léger.

L'hébergeur a souvent des journaux d'erreur PHP dans le panel, hors site. Préférez-les. Moins de fichiers à oublier dans `wp-content`.

• Pas d'erreurs dans le HTML visiteur.
• Pas de `debug.log` en HTTP 200.
• Journaux panel ou fichier hors racine web.

Où ça se règle vraiment

`wp-config.php` : `WP_DEBUG`, `WP_DEBUG_DISPLAY`, `WP_DEBUG_LOG`. Un plugin « debug » peut les forcer. Un hébergeur peut injecter un `php.ini` `display_errors=On`. Vérifiez les trois. Couper seulement la constante WordPress alors que PHP affiche encore, ça laisse les warnings.

Un must-use ou un `sunrise.php` (multisite) peut redéfinir. Après incident, relisez ces fichiers comme le reste.

Ne « réparez pas » un `wp-config` au jugé si vous n'êtes pas à l'aise : une quote oubliée fait une 500. Copie, puis édition. Même prudence que pour DISALLOW_FILE_EDIT.

Ce que les notices ont déjà montré

Si le debug était on pendant des mois, des chemins et des versions ont pu être collectés. Ce n'est généralement pas une fuite clients. C'est un renseignement d'infrastructure. On le note. On ne tourne pas tous les mots de passe clients pour ça.

Si une notice citait un mot de passe ou une clé (plugin mal écrit), là on tourne ce secret. Rare, assez grave pour le chercher dans les captures et le `debug.log`.

Googlebot a pu indexer une page d'erreur verbeuse. Après coupure, une réindexation des gabarits suffit souvent. Ce n'est pas un générateur de spam.

Plugins « debug / query monitor » en prod

Query Monitor, Debug Bar, des barres d'admin trop bavardes : utiles en staging, trop riches en prod si un rôle trop bas les voit. Après incident, restreignez-les aux admins, ou retirez-les de la prod. Ils ne sont pas des portes par eux-mêmes ; ils sont des lampes.

Un plugin debug abandonné est une extension de plus. Extensions abandonnées.

Ne les installez pas le soir J « pour voir les hooks du malware ». Vous ajoutez du bruit. Copie, comparaison.

Après l'incident : un mode, pas deux

Prod : affichage off, log off sauf fenêtre de debug courte et maîtrisée. Staging : ce que vous voulez, mais le staging n'est pas public, et pas sur le même secret que la prod. Staging oublié.

Documentez dans le constat : debug public trouvé / coupé, `debug.log` exposé ou non. Petite ligne, utile.

Surveillance : un `debug.log` qui réapparaît dans `wp-content`, c'est un signal (quelqu'un a rallumé). Surveillance.

Décider sans tout éteindre au hasard

Coupez l'affichage. Ne « désactivez pas PHP » , ne passez pas le site en 500 pour cacher les notices. Ne jetez pas `wp-config`.

Si une 500 persiste une fois le debug off, lisez le journal panel : un fichier encore cassé, pas « le debug qui manquait ».

Déclarer : une capture de la home avec les notices aide à dater et à voir les chemins. C'est une preuve d'exposition, pas le malware lui-même.