En bref : pour la sécurité de php.ini, quatre domaines comptent surtout : aucun message d'erreur visible de l'extérieur, des cookies de session sûrs, des uploads limités et des valeurs verrouillées que les applications ne peuvent pas écraser. Après PHP2Shell s'ajoutent les mesures transitoires de php.net, surtout session.upload_progress.enabled=0. Une configuration sûre ne remplace toutefois jamais la mise à jour.
Pourquoi php.ini revient au premier plan après PHP2Shell
php.ini est le fichier de configuration central de PHP. Sur de nombreux serveurs, il a été configuré une fois puis à peine touché. Avec PHP2Shell, cela a changé : pour les deux failles CVE-2026-109618 et CVE-2026-109619, php.net indique des mesures transitoires qui agissent précisément ici.
Les failles elles-mêmes se trouvent dans l'interpréteur PHP. Elles sont corrigées dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35, publiées le 21 octobre 2026. Une bonne configuration aide néanmoins de deux façons : elle peut compliquer l'exploitation et elle limite les dégâts si quelque chose passe malgré tout.
De nombreux exploitants ne savent en outre pas exactement quels réglages s'appliquent sur leur serveur. C'est la première étape.
Quel php.ini s'applique sur votre serveur ?
Selon le mode d'exécution, PHP peut lire différents fichiers de configuration. La ligne de commande, PHP-FPM et Apache avec mod_php ont par exemple chacun leur propre dossier sous /etc/php/<version>/ sous Debian et Ubuntu. Qui ne modifie que le fichier de la CLI ne change rien pour le site web.
# Fichiers de configuration de la ligne de commande
php --ini
# Configuration de PHP-FPM (adapter le numéro de version)
php-fpm8.3 -i | grep -E "Loaded Configuration|Scan this dir"
# Vérifier des valeurs individuelles de PHP-FPM
php-fpm8.3 -i | grep -E "^(expose_php|display_errors|session.upload_progress.enabled) "
Des valeurs peuvent en outre figurer dans le pool FPM, dans la configuration d'Apache, dans .htaccess (mod_php uniquement) ou dans .user.ini (FPM et CGI). L'article Vérifier correctement la version de PHP et l'état du correctif explique quelle version tourne réellement sur le serveur et si un backport est inclus.
Réglages de base pour une meilleure sécurité de php.ini
Les valeurs suivantes sont judicieuses pour la plupart des serveurs de production. Avant de les utiliser, vérifiez dans un environnement de test que votre application s'accommode de toutes les valeurs.
; Aucune indication de version dans l'en-tête HTTP
expose_php = Off
; Journaliser les erreurs, mais ne jamais les afficher dans le navigateur
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/error.log
; Ne pas inclure de fichiers provenant d'adresses distantes
allow_url_include = Off
; Laisser allow_url_fopen actif seulement si l'application en a besoin
allow_url_fopen = Off
; Sessions : strictes, uniquement via HTTPS, illisibles par JavaScript
session.use_strict_mode = 1
session.use_only_cookies = 1
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
; Limiter la durée d'exécution et les entrées
max_execution_time = 30
max_input_time = 60
max_input_vars = 1000
Certaines applications ont besoin de allow_url_fopen pour les mises à jour ou les interfaces. Ne le désactivez qu'après l'avoir vérifié. Les fonctions qui exécutent des commandes système peuvent en outre être bloquées ; la manière d'y parvenir sans effets secondaires est expliquée dans le guide Utiliser correctement disable_functions.
Mesures transitoires de php.net pour PHP2Shell
Si vous ne pouvez pas appliquer le correctif immédiatement, php.net indique plusieurs réglages qui réduisent le risque. Ils ne constituent expressément pas une protection complète, mais un pont jusqu'à la mise à jour.
; Désactiver le suivi de progression de l'envoi en session (aussi pour CVE-2026-115560)
session.upload_progress.enabled = 0
; Limiter la taille des requêtes : 8M sans uploads, 32M avec uploads
post_max_size = 8M
upload_max_filesize = 6M
; PHP 8.5 uniquement : pas de backtraces lors des erreurs graves
fatal_error_backtraces = 0
php.net recommande en outre de définir memory_limit=-1 de façon que les applications ne puissent pas écraser la valeur, et de fixer la limite de mémoire plutôt via le conteneur ou cgroup, et non via RLIMIT_AS ou RLIMIT_DATA. Cette mesure relève du pool FPM ou de la configuration du serveur et devrait être combinée avec une limite cgroup fonctionnelle. Vous trouverez la vue d'ensemble complète sous Mesures d'urgence si vous ne pouvez pas encore appliquer le correctif.
session.upload_progress.enabled=0 ne fonctionne que depuis php.ini, le pool FPM ou la configuration du serveur. Défini via ini_set() ou .user.ini, la mesure n'a aucun effet. Redémarrez ensuite tous les workers.
Verrouiller les valeurs contre l'écrasement
De nombreuses applications définissent leurs propres valeurs, par exemple pour la mémoire ou les uploads. Avec php_admin_value et php_admin_flag, vous fixez des réglages que ni ini_set() ni .user.ini ne peuvent modifier. Dans le pool FPM, cela se présente ainsi :
; /etc/php/8.3/fpm/pool.d/meine-seite.conf (extrait)
php_admin_flag[display_errors] = off
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_value[error_log] = /var/log/php/meine-seite.error.log
Sous Apache avec mod_php, la même logique s'applique avec php_admin_value et php_admin_flag dans la configuration du VirtualHost. Rechargez ensuite le service et recoupez la valeur active :
sudo systemctl reload php8.3-fpm
# Heure de démarrage des processus : est-elle postérieure à la modification ?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Un rechargement redémarre les workers de PHP-FPM. Après une mise à jour de PHP, en revanche, un redémarrage complet de tous les processus PHP est nécessaire afin qu'aucun ancien processus ne continue de tourner en mémoire. Lorsque plusieurs sites tournent sur un serveur, un pool dédié par site vaut en outre la peine ; plus de détails dans le guide open_basedir et isolation par site web.
Erreurs fréquentes et courte liste de contrôle
La plupart des problèmes avec php.ini ne viennent pas de valeurs erronées, mais de valeurs au mauvais endroit. Un cas typique est le fichier de la CLI modifié alors que le site tourne via PHP-FPM. Il arrive tout aussi souvent que le redémarrage manque après une modification, ou qu'un panneau d'hébergement écrase votre propre réglage lors de la prochaine sauvegarde.
Un deuxième classique est celui des messages d'erreur visibles sur le site en production. Ils révèlent des chemins, des noms de base de données ou des versions et facilitent l'orientation des attaquants. Précisément après un déménagement ou une réinstallation, display_errors repasse souvent sur On.
Vérifiez ces points après chaque modification et après chaque mise à jour de PHP :
- Quel fichier de configuration le mode d'exécution web lit-il, et contient-il vos valeurs ?
display_errorsetexpose_phpsont-ils désactivés, le journal d'erreurs est-il accessible en écriture ?session.upload_progress.enabledest-il sur0, défini via php.ini ou le pool ?- Les tailles d'upload et de requête sont-elles limitées de façon adaptée à l'application ?
- Tous les processus PHP ont-ils une heure de démarrage postérieure à la dernière modification ?
Consignez le résultat avec la date. Cela permet de prouver plus tard quel réglage s'appliquait à quel moment.
Comment PHP SOS aide-t-il concrètement ?
- Nous déterminons quelle configuration est réellement active dans quel mode d'exécution.
- Nous mettons en place une configuration de base adaptée et les mesures transitoires PHP2Shell, testées avec votre application.
- Nous verrouillons les valeurs sensibles pour la sécurité contre l'écrasement et redémarrons tous les workers de façon contrôlée.
- Nous documentons les réglages et le résultat du contrôle afin que les modifications ultérieures restent traçables.
La prestation Renforcement de serveur pour serveurs web PHP décrit à quoi ressemble une sécurisation durable.
Questions fréquentes
Quel php.ini mon serveur web utilise-t-il réellement ?
Ce n'est souvent pas le même que sur la ligne de commande. PHP-FPM, Apache avec mod_php et la CLI ont généralement leurs propres dossiers de configuration. Vérifiez donc le fichier actif via le mode d'exécution concerné, par exemple avec php-fpm -i ou un fichier de test déposé brièvement.
Un php.ini sûr remplace-t-il la mise à jour de PHP ?
Non. Les réglages réduisent la surface d'attaque et compliquent l'exploitation, mais ne comblent aucune faille de l'interpréteur PHP. Les mesures transitoires de php.net pour PHP2Shell ne constituent expressément pas non plus une protection complète.
Quelle est la différence entre php_value et php_admin_value ?
Les valeurs définies avec php_value peuvent être modifiées de nouveau par l'application à l'exécution. Les valeurs définies via php_admin_value dans le pool FPM ou dans la configuration d'Apache sont en revanche verrouillées pour l'application, y compris pour ini_set() et .user.ini.
Dois-je redémarrer après une modification de php.ini ?
Oui. PHP-FPM et Apache avec mod_php ne lisent la configuration qu'au démarrage. Les nouvelles valeurs ne s'appliquent qu'après un redémarrage ou un rechargement de tous les services concernés.