phpinfo() ou un script de test encore en ligne
`phpinfo()`, `info.php`, `test.php`, `testdrive` : chemins, versions, parfois des variables. Supprimez-les. C'est souvent l'outil qui a servi à viser la bonne faille — un oubli de prestataire, pas un « virus ».
Chemins, versions, parfois des variables. Supprimez info.php, test.php, testdrive. C'est souvent l'outil qui a servi à l'attaquant pour viser la bonne faille.
Ce que la page raconte en une requête
Version de PHP, modules, chemins du serveur, parfois `DOCUMENT_ROOT`, des extraits de configuration. Assez pour choisir une faille connue, assez pour savoir où écrire. Ce n'est pas une backdoor. C'est une brochure. On ne laisse pas de brochure sur la serrure. Un prestataire qui « vérifie que PHP 8 est bien là » n'a pas besoin de cette page en public : le panel de l'hébergeur affiche la version, sans offrir les chemins au reste d'Internet.
Après un incident, on la trouve encore parce que personne n'ose « casser le test de l'hébergeur ». L'hébergeur n'a pas besoin de votre `info.php` à la racine du site client. Les journaux du panel suffisent.
Les bots la demandent en boucle, comme `/.env`. Un 200 aujourd'hui est un 200 pour tout le monde. `.env`. Une fois la page ôtée, on cherche encore l'entrée réelle (extension, compte, voisin) : retirer la brochure ne referme pas la porte.
Les noms que l'on retrouve encore
`info.php`, `phpinfo.php`, `test.php`, `testdrive`, `i.php`, `tmp.php`, `adminer.php` à côté (autre article). Des copies dans `/wp-admin/`, dans `/old/`. Cherchez le nom et le contenu `phpinfo(` si vous avez un accès fichiers — sans en créer un nouveau « pour vérifier ».
Un prestataire a pu en poser un par vhost. Listez les sous-domaines. Sous-domaine oublié.
Docker / images de démo : un phpinfo dans l'image « example ». Relisez ce qui est réellement exposé.
Supprimer, pas « protéger par robots.txt »
Les bots d'exploit ne respectent pas robots.txt. Un 403 sur le fichier encore présent : mieux, le fichier reste pour le FTP. Suppression, ou hors web. Vérifiez que l'URL fait 404.
Un WAF qui « bloque phpinfo » n'est pas une suppression. Le fichier attend le prochain trou de WAF.
Si vous en avez besoin un jour en diagnostic : machine hors prod, ou accès panel, puis suppression immédiate. Pas de bookmark `https://prod/info.php`.
Ce que ça n'est pas
Ce n'est pas le malware. Le retirer ne referme pas une extension. C'est une ligne de la checklist, obligatoire, pas suffisante. Les dossiers « on a enlevé info.php, c'est bon » reviennent : la brochure était un facilitateur, rarement la seule porte. On la sort, on continue la comparaison des fichiers et des comptes.
Ce n'est pas Safe Browsing. Chrome ne bloque pas pour un phpinfo. Ne déposez pas de réexamen pour ça.
Ce n'est généralement pas une fuite clients — sauf si des variables d'environnement (clés, DSN) s'affichent dans la page. Alors on tourne, comme un `.env`.
Variables d'environnement dans la sortie
Selon la config, `phpinfo` montre `$_ENV` / `$_SERVER` trop riches. Traitez alors comme une exposition de secrets : rotation. Capturez (pour le constat), puis supprimez, puis tournez. La capture ne se forward pas par Slack public.
Même si la page actuelle est « sobre », une version plus bavarde a pu être en ligne. En cas de doute sur les variables, tournez les clés d'app qui étaient sur ce vhost.
Debug WP : moins complet, même idée (chemins, plugins).
Après : plus de scripts de test en prod
Règle : pas de `test.php`, pas de seed, pas de `phpunit` web, pas de page « hello world » à la racine. Le staging existe pour ça, isolé, autre secret. Un « hello » qui affiche `phpversion()` est déjà trop : la version se lit ailleurs, sans URL publique. Inscrivez la règle dans le même inventaire que les accès prestataire : on ne pose pas de script de test sans date de fin.
Les installateurs (Duplicator, etc.) sont dans la même corbeille. Duplicator.
Surveillance : alerte si `info.php` réapparaît. Un prestataire « qui vérifie PHP » le repose. Accès : on ne laisse pas ce geste sans révocation.
Debug WordPress, le cousin poli
`WP_DEBUG_DISPLAY` en vitrine, `debug.log` public : même passe, même jour. Moins de modules listés, assez de chemins.
Query Monitor en prod pour tous les rôles : lampe. On restreint.
Ne les activez pas le soir J pour « voir le malware ». Copie, comparaison.
Passe fichiers du jour J
phpinfo, Adminer, `.env`, `.git`, zip, sql. Une liste. Le guide premiers gestes n'entre pas dans ces noms ; cet article, si. C'est le niveau d'après, encore avant la refonte.
Le constat : URL, si des ENV étaient visibles, suppression datée. Court.
Déclarer : une capture de phpinfo (une fois, puis on efface chez vous) aide à voir versions et chemins. Ne la laissez pas en ligne « pour nous ». Envoyez-la, retirez la page.