En bref : un fichier qui se contente d'appeler phpinfo() montre à chaque visiteur la version, les modules, les chemins et les réglages de PHP, souvent aussi des variables d'environnement contenant des identifiants. Pour la sécurité de phpinfo, la règle est donc : ne jamais laisser de tels fichiers durablement dans le webroot, les supprimer après usage et vérifier plutôt l'état de PHP via la gestion des paquets et la configuration. Une sortie phpinfo ne prouve de toute façon pas l'état du correctif contre PHP2Shell.
Le fichier de test qui reste
Depuis le 21 octobre 2026, des milliers d'administrateurs vérifient quelle version de PHP leurs sites diffusent. Le moyen le plus rapide est connu : créer un fichier info.php d'une seule ligne, l'appeler dans le navigateur, lire le résultat. Cela fonctionne. Le problème commence ensuite, quand le fichier est oublié.
De tels fichiers survivent étonnamment longtemps. Ils suivent lors des déménagements, atterrissent dans des sauvegardes et réapparaissent des années plus tard dans des répertoires que plus personne ne connaît. Des scanners automatisés interrogent en permanence les noms de fichiers typiques. Ce qui était un outil pour l'administrateur est pour un attaquant un plan de construction du serveur.
Les agences et les hébergeurs avec de nombreux sites clients sont particulièrement concernés. Qui vérifie des dizaines de sites au cours d'une semaine agitée crée vite des dizaines de fichiers de test. Un seul dossier oublié suffit pour que le fichier soit encore accessible des mois plus tard.
Ce que phpinfo() révèle et pourquoi cela compte pour la sécurité
Selon le manuel PHP, phpinfo() affiche l'état actuel de PHP. Des constantes permettent de contrôler quelles parties apparaissent ; sans indication, tout est affiché.
| Domaine (constante) | Contenu selon le manuel | Pourquoi c'est délicat |
|---|---|---|
INFO_GENERAL |
build, emplacement du php.ini, serveur web, système | révèle le système d'exploitation et les chemins |
INFO_CONFIGURATION |
valeurs locales et principales de toutes les directives | montre si disable_functions ou open_basedir sont actifs |
INFO_MODULES |
extensions chargées avec leurs réglages | les attaquants voient quelles fonctions sont disponibles |
INFO_ENVIRONMENT |
variables d'environnement | on y trouve souvent des identifiants de base de données ou d'API |
INFO_VARIABLES |
variables prédéfinies (Environment, GET, POST, Cookie, Server) | contient les en-têtes et cookies de la requête en cours |
Les deux dernières lignes sont les plus dangereuses. Les applications modernes chargent volontiers leurs identifiants depuis des variables d'environnement, par exemple depuis un fichier .env ou la configuration du conteneur. Ces valeurs apparaissent alors en clair dans la sortie. La façon de protéger ces secrets de manière générale est décrite dans l'article Bien protéger les identifiants et les fichiers .env.
S'y ajoute que la sortie montre les valeurs de la requête en cours, donc aussi les cookies et les en-têtes. Si un attaquant peut attirer un visiteur sur la page et lire la réponse, par exemple via une faille de cross-site scripting ailleurs, même des cookies marqués HttpOnly deviennent visibles.
Pourquoi phpinfo n'est pas une preuve contre PHP2Shell
Beaucoup viennent de créer le fichier pour vérifier l'état du correctif. C'est précisément à cela qu'il ne sert que partiellement. Les distributions et les hébergeurs appliquent souvent les corrections sous forme de backport ; selon des rapports, Ubuntu 24.04 affiche par exemple toujours 8.3.6 après la mise à jour. Le numéro affiché dit donc peu de choses. À l'inverse, un numéro récent ne prouve pas que tous les workers ont été redémarrés.
Ce qui est fiable, c'est l'état du paquet avec les numéros CVE dans le changelog, complété par le redémarrage de tous les processus PHP. La façon de procéder est expliquée dans l'article Bien vérifier la version de PHP et l'état du correctif.
Une sortie temporaire dans le contexte web a malgré tout sa place : elle montre quel php.ini et quelles valeurs s'appliquent réellement au site, car la ligne de commande lit souvent une autre configuration. Le contexte sur les niveaux et la priorité est expliqué dans Le php.ini expliqué. Si vous en avez besoin, alors avec un accès protégé, un nom de fichier aléatoire et seulement pour quelques minutes.
Pour la plupart des questions, il existe de toute façon de meilleures voies. La version de PHP d'un pool FPM figure dans sa configuration et dans la liste des processus. Des valeurs isolées peuvent être interrogées avec ini_get() dans un script situé en dehors du webroot, sans tout dévoiler. Et dans les panneaux d'hébergement, l'interface affiche la version attribuée à chaque site, quoique sans information sur les backports.
Trouver les fichiers oubliés : étapes de vérification concrètes
Voici comment détecter les vestiges sur un serveur Linux. Les commandes sont en lecture seule et ne modifient rien.
- Rechercher les fichiers contenant un appel phpinfo (adapter le chemin) :
grep -rlE "phpinfo[[:space:]]*\(" /var/www --include="*.php" 2>/dev/null
- Vérifier les noms de fichiers typiques, même sans occurrence dans le contenu :
find /var/www -type f \( -iname "info.php" -o -iname "phpinfo.php" -o -iname "test.php" -o -iname "i.php" \) 2>/dev/null
-
Évaluer les résultats : toutes les occurrences ne sont pas des fichiers de test. Des outils d'administration, des panneaux ou des frameworks peuvent utiliser
phpinfo()derrière une authentification. Ce qui compte, c'est de savoir si le fichier est accessible depuis Internet sans authentification. -
Consulter les accès dans le journal avant de supprimer :
grep -E "GET /(info|phpinfo|test|i)\.php" /var/log/nginx/access.log* 2>/dev/null | tail -n 50
- Supprimer et remplacer les secrets : si la sortie contenait un mot de passe ou une clé et que le fichier était public, la valeur est considérée comme connue. Changez-la.
Une occurrence dont la date de création est inconnue et au contenu inhabituel à côté de l'appel phpinfo peut aussi être une porte dérobée. Ne vous contentez alors pas de supprimer : sauvegardez et faites examiner, voir Reconnaître et supprimer les webshells.
Prévenir durablement plutôt que nettoyer
Trois mesures évitent que le sujet ne revienne. Premièrement : ajouter phpinfo à la liste disable_functions du php.ini pour le contexte web. Vérifiez au préalable si votre panneau a besoin de la fonction pour une page d'état. Comment le réglage agit et où sont ses limites est expliqué dans Bien utiliser disable_functions.
; php.ini pour FPM ou Apache, puis redémarrer tous les processus PHP
disable_functions = phpinfo
expose_php = Off
Deuxièmement : une mise à disposition uniquement par un processus défini, par exemple via Git ou un pipeline de build, afin qu'aucun fichier isolé n'arrive à la main dans le webroot. Troisièmement : les informations d'état relèvent de la supervision ou de l'inventaire, pas d'une page publique.
expose_php = Off supprime en plus l'en-tête par lequel PHP indique sa version dans chaque réponse. Cela ne remplace pas une mise à jour, mais retire aux scanners automatisés une information pratique. Si plusieurs personnes disposent d'un accès au serveur, il convient en outre de convenir d'une règle simple : les fichiers de test sont supprimés à l'étape même où ils ont été créés, et non « plus tard ».
Comment PHP SOS aide-t-il concrètement ?
- Nous parcourons vos webroots à la recherche de fichiers phpinfo, de scripts de test et d'autres vestiges, et évaluons chaque occurrence.
- Nous analysons les accès aux fichiers trouvés et vous indiquons quels secrets remplacer.
- Nous attestons l'état du correctif contre PHP2Shell via le changelog des paquets et le redémarrage des processus plutôt que par un affichage de version.
- Nous mettons en place durablement
disable_functions,expose_phpet d'autres durcissements dans le cadre du durcissement du serveur.
Conclusion : un fichier phpinfo se crée en quelques secondes et s'oublie tout aussi vite. Qui le cherche et le supprime maintenant ferme une fuite de données inutile et s'appuie, pour l'état du correctif, sur des preuves fiables.
Questions fréquentes
Un fichier phpinfo est-il en soi une faille de sécurité ?
Il n'ouvre aucun accès, mais fournit aux attaquants une description détaillée du serveur : version, modules, chemins, réglages et, selon l'environnement, aussi les variables d'environnement. Cela facilite les attaques ciblées et peut dévoiler des identifiants.
Le numéro de version dans phpinfo prouve-t-il que PHP2Shell est corrigé ?
Non. Les distributions et les hébergeurs appliquent souvent les corrections sous forme de backport ; le numéro affiché reste alors le même. L'état du correctif est attesté par le changelog du paquet et la confirmation du fournisseur, ainsi que par le redémarrage de tous les processus PHP.
Que faire si un fichier phpinfo est resté public longtemps ?
Supprimer le fichier, regarder dans le journal d'accès qui l'a appelé et remplacer tous les secrets qui figuraient dans la sortie, par exemple les mots de passe de base de données ou les clés d'API issus des variables d'environnement.
Puis-je désactiver complètement phpinfo() ?
Oui, via disable_functions dans le php.ini du contexte web. Vérifiez au préalable si un panneau ou une application utilise la fonction pour des pages d'état, puis redémarrez ensuite les processus PHP.