En bref : définissez session.upload_progress.enabled=0 dans le php.ini, dans le pool PHP-FPM ou dans la configuration du serveur Apache, jamais via ini_set() ni .user.ini, puis redémarrez tous les workers PHP. La mesure ne devient durable que lorsque la valeur est verrouillée contre une réactivation, qu'elle s'applique dans chaque mode d'exploitation et chaque version de PHP installée, et qu'elle est revérifiée après les mises à jour.
Un petit paramètre à double effet
Rarement un seul paramètre PHP a reçu autant d'attention. Lorsque php.net a publié, le 21 octobre 2026, les correctifs contre PHP2Shell, session.upload_progress.enabled=0 figurait sur la liste des mesures transitoires. Deux jours plus tard est venu l'avis relatif à CVE-2026-115560, et le remède recommandé était le même paramètre.
Beaucoup d'administrateurs l'ont défini rapidement ces jours-là. Savoir s'il agit partout est une autre question. Les lacunes typiques sont vite énumérées : la valeur n'est que dans la configuration CLI, une deuxième version de PHP a été oubliée, ou un panneau d'hébergement a écrasé le fichier lors de l'enregistrement suivant. Cet article montre comment mettre en œuvre la mesure pour qu'elle s'applique encore dans trois mois.
Important au préalable : la désactivation ne remplace pas la mise à jour de PHP. Selon des rapports spécialisés, session.upload_progress.enabled=0 seul ne ferme pas les deux failles PHP2Shell. Ce que CVE-2026-115560 concerne exactement est expliqué sur la page CVE-2026-115560 : avis sur la progression d'upload de session.
Ce que fait la fonction et qui en a besoin
La progression d'upload de session écrit en continu l'avancement dans la session pendant un upload de fichier, afin qu'une application puisse afficher une barre de progression. Dans PHP, la fonction est activée par défaut. Le manuel PHP signale lui-même que les noms de fichiers et de champs fournis par l'expéditeur se retrouvent alors sans vérification dans le stockage de session, et recommande de désactiver la fonction si l'application ne l'utilise pas.
Une recherche purement en lecture dans le code permet de savoir si votre application l'utilise :
# Recherche les usages de la fonction de progression dans le code de l'application
grep -rn --include="*.php" -e "upload_progress" -e "PHP_SESSION_UPLOAD_PROGRESS" /var/www/
Si la recherche ne trouve rien, vous pouvez désactiver la fonction sans conséquence perceptible. S'il y a des résultats, l'application perd seulement l'affichage de la progression, pas l'upload. Les formulaires modernes mesurent de toute façon le plus souvent la progression dans le navigateur.
Définir session.upload_progress.enabled au bon endroit
Selon le manuel PHP, le paramètre a le mode INI_PERDIR. Cela signifie qu'il peut être défini dans le php.ini, dans la configuration du serveur, dans .htaccess (mod_php uniquement) et dans .user.ini (FPM et CGI uniquement), mais pas à l'exécution. php.net exclut expressément .user.ini comme emplacement pour la mesure. Le tableau suivant montre les emplacements pertinents selon le mode d'exploitation.
| Mode d'exploitation | Emplacement recommandé | Verrouille contre l'écrasement ? | Redémarrer ensuite |
|---|---|---|---|
| PHP-FPM | fichier de pool avec php_admin_flag |
oui | chaque service FPM |
| PHP-FPM | php.ini de la SAPI FPM | non, .user.ini pourrait l'écraser |
chaque service FPM |
| Apache avec mod_php | VirtualHost ou configuration du serveur avec php_admin_flag |
oui | Apache complètement |
| php-cgi, LiteSpeed, FrankenPHP | php.ini de l'environnement d'exécution concerné | à vérifier selon la structure | tous les processus de l'environnement |
| Image Docker | fichier dédié dans /usr/local/etc/php/conf.d/ lors de la construction |
oui, si aucun écrasement n'est autorisé | recréer le conteneur |
Les deux variantes robustes se présentent ainsi :
; PHP-FPM, par ex. /etc/php/8.3/fpm/pool.d/seite1.conf
php_admin_flag[session.upload_progress.enabled] = off
# Apache avec mod_php, dans le VirtualHost ou pour tout le serveur
<IfModule php_module>
php_admin_flag session.upload_progress.enabled off
</IfModule>
L'inscription supplémentaire dans le php.ini de chaque SAPI web comme valeur de base vaut la peine. Le paramètre s'applique alors aussi aux nouveaux pools que quelqu'un créera plus tard. Pourquoi php_admin_flag fait la différence est décrit dans l'article php_admin_value : verrouiller les paramètres contre l'écrasement.
Vérifier l'efficacité dans le contexte web
La ligne de commande lit souvent un autre php.ini que le serveur web. Un php -i prouve donc peu de choses. Même php-fpm8.3 -i ne montre que les valeurs du php.ini, pas les entrées des pools. Seule une requête qui passe réellement par le pool est fiable.
Procédez ainsi :
- Redémarrez tous les services PHP, par exemple
systemctl restart php8.3-fpmou Apache avec mod_php. Sans redémarrage, l'ancienne valeur continue de s'appliquer. - Placez dans la racine web un court fichier de test au nom aléatoire, qui affiche uniquement la valeur actuelle.
- Appelez le fichier une fois via le vrai domaine et notez le résultat.
- Supprimez aussitôt le fichier et répétez l'étape pour chaque site et chaque pool.
<?php
// Fichier de test : ne le laisser que brièvement, puis le supprimer aussitôt
header('Content-Type: text/plain');
echo 'session.upload_progress.enabled = ', var_export(ini_get('session.upload_progress.enabled'), true), "\n";
echo 'PHP ', PHP_VERSION, ' / SAPI ', PHP_SAPI, "\n";
On attend une valeur vide ou '0'. Si '1' s'affiche, votre paramètre ne s'applique pas dans ce pool. Après une mise à jour de PHP, vérifiez en plus que tous les workers ont été redémarrés, comme décrit dans Redémarrer PHP-FPM et tous les workers.
Ne laissez jamais de fichiers de test en place. Ils révèlent les versions et la configuration et sont une cible prisée des analyses automatisées.
Pour que le paramètre reste durablement
La plupart des retours en arrière ne viennent pas d'attaquants, mais de l'exploitation. Un nouveau pool est copié à partir d'un ancien modèle, une mise à jour de paquet crée un nouveau php.ini, ou quelqu'un change la version de PHP dans le panneau d'hébergement. Des habitudes fermes aident contre de tels retours en arrière.
- Couvrir toutes les versions : sur de nombreux serveurs, plusieurs versions de PHP tournent en parallèle. Chacune a ses propres dossiers de configuration et a besoin de l'entrée.
- Adapter les modèles : les modèles de pool, rôles Ansible, Dockerfiles et modèles de panneau contiennent la valeur, afin que les nouveaux sites en héritent automatiquement.
- Utiliser les paramètres du panneau : dans les panneaux d'hébergement, la valeur va dans les directives supplémentaires prévues par le panneau, sinon la prochaine modification écrase le travail manuel.
- Vérifier après les mises à jour : la vérification de la section précédente fait partie de la liste de contrôle de chaque mise à jour de PHP.
- Documenter : consigner la date, le serveur, les pools et le résultat. Cela aide plus tard face à la direction, à l'assureur ou aux auditeurs.
Qui n'utilise pas du tout .user.ini peut désactiver complètement la lecture de ces fichiers avec user_ini.filename = dans le php.ini. Cela concerne toutefois tous les paramètres que les applications y déposent. Testez donc cette étape au préalable, en particulier pour les CMS qui écrivent leurs propres fichiers .user.ini.
Les autres mesures transitoires de php.net, par exemple les limites pour post_max_size et la limite mémoire par cgroup, sont rassemblées dans Mesures immédiates si vous ne pouvez pas encore appliquer le correctif. La manière dont PHP ordonne ses niveaux de configuration est expliquée dans Le php.ini expliqué.
Comment PHP SOS aide-t-il concrètement ?
- Faire l'inventaire : nous déterminons toutes les versions de PHP, modes d'exploitation et pools de vos serveurs et lisons les valeurs effectives dans le contexte web.
- Régler proprement : nous inscrivons le paramètre, verrouillé, dans les pools et la configuration du serveur et redémarrons tous les workers de façon contrôlée.
- Tester le fonctionnement : nous vérifions les formulaires d'upload et la gestion des médias après le changement.
- Éviter les retours en arrière : nous adaptons modèles, déploiements et paramètres de panneau et documentons l'état dans le cadre du durcissement de serveur.
Questions fréquentes
Pourquoi session.upload_progress.enabled=0 n'agit-il pas via ini_set() ?
Selon le manuel PHP, ce paramètre relève du mode INI_PERDIR. Il ne peut donc pas du tout être modifié à l'exécution avec ini_set(). php.net cite comme bons emplacements le php.ini, le pool FPM ou la configuration du serveur, et exclut expressément .user.ini.
Les uploads de fichiers fonctionnent-ils encore après la désactivation ?
Oui. Seule est désactivée l'information de progression que PHP écrit dans la session pendant un upload. L'upload lui-même continue. Seules sont concernées les applications qui construisent leur barre de progression précisément avec cette fonction PHP.
Une application peut-elle réactiver la fonction ?
Via un fichier .htaccess avec mod_php ou un .user.ini avec PHP-FPM, c'est en principe possible tant que la valeur n'est pas verrouillée. Avec php_admin_flag dans le pool ou dans la configuration d'Apache, vous l'empêchez.
Dois-je rétablir la valeur après la prochaine mise à jour de PHP ?
Non, ce n'est pas nécessaire. La fonction n'est pas utilisée par la plupart des applications, et le manuel PHP conseille lui-même de la désactiver dans ce cas. Après chaque mise à jour, vérifiez seulement que la valeur s'applique toujours.