session.upload_progress.enabled

session.upload_progress.enabled = 0 arrête-t-il PHP2Shell ?

En partie. Cela bloque les chemins de session confirmés de l’une des deux CVE — et seulement si vous le définissez au bon endroit et redémarrez. C’est une solution d’attente, pas une correction.

Dernière vérification 2026-10-22

La réponse courte

php.net : « This blocks the confirmed session paths but not other variants. » Cela ne fait rien contre CVE-2026-109618. Ce contournement a largement circulé avant le correctif ; la publication a confirmé qu’il n’a jamais été complet. Mettez PHP à jour.

Ce que fait ce réglage

Avec la progression d’envoi activée (par défaut), PHP surveille un champ de formulaire spécial dans les envois multipart et écrit la progression dans la session de l’utilisateur pendant qu’il analyse encore la requête. C’est précisément dans ce traitement de session précoce, avant l’initialisation, que se trouvent le use-after-free et la fuite de mémoire de PHP2Shell liés aux sessions — y compris la fuite de mémoire du tas dans le cookie PHPSESSID, qui fonctionne même si votre application ne démarre jamais de session.

Ce que cela bloque et ce que cela ne bloque pas

Chemin d’attaque	Bloqué ?
Chemins confirmés de progression d’envoi en session (CVE-2026-109619)	Oui
Chemin des backtraces d’erreur fatale (PHP 8.5)	Non — définissez aussi `fatal_error_backtraces = 0`
Autres variantes d’état résiduel (CVE-2026-109619)	Non
Corruption en cas de mémoire épuisée (CVE-2026-109618)	Non — voir `memory_limit` / `post_max_size`

1. Vérifier la valeur actuelle

shell

# What php.ini says (CLI and FPM can differ — check both)
php -i | grep session.upload_progress.enabled
php-fpm8.3 -i | grep session.upload_progress.enabled    # adjust version

# Where the setting comes from
php --ini
grep -rn "upload_progress" /etc/php/ 2>/dev/null

# What the running site actually uses (FPM pool overrides are only visible here)
# <?php var_dump(ini_get('session.upload_progress.enabled'));

2. Le définir là où il s’applique vraiment

Emplacement	Efficace ?	Pourquoi
php.ini / fichier conf.d	Oui	S’applique avant l’analyse de la requête.
Pool FPM `php_admin_flag` / `php_admin_value`	Oui	Par pool ; l’application ne peut pas le surcharger.
VirtualHost Apache / configuration serveur (`php_admin_flag`)	Oui	Pour mod_php.
`.user.ini`	Non	php.net : ne pas s’y fier — il peut ne pas s’appliquer avant l’analyse de la requête.
`.htaccess` php_flag	Déconseillé	Par répertoire et surchargeable ; utilisez la configuration serveur.
`ini_set()` dans le code	Non	S’exécute après l’analyse de la requête.

config

; php.ini or conf.d drop-in, e.g. /etc/php/8.3/fpm/conf.d/99-php2shell.ini
session.upload_progress.enabled = 0

; or per FPM pool (/etc/php/8.3/fpm/pool.d/www.conf)
php_admin_flag[session.upload_progress.enabled] = off

; or Apache + mod_php (vhost or server config, not .htaccess)
php_admin_flag session.upload_progress.enabled off

3. Redémarrer chaque worker

Les workers en cours conservent leurs anciens réglages — et peut-être un état déjà corrompu — jusqu’à leur redémarrage.

shell

sudo systemctl restart php8.3-fpm      # every FPM version and pool you run
sudo systemctl restart apache2         # mod_php
sudo /scripts/restartsrv_apache_php_fpm   # cPanel
sudo systemctl restart plesk-php83-fpm # Plesk, per handler

Questions

session.upload_progress.enabled = 0 protège-t-il contre PHP2Shell ?+

En partie seulement. Selon php.net, cela « bloque les chemins de session confirmés, mais pas les autres variantes ». Cela ne fait rien contre CVE-2026-109618. Gina Peter Banyard, de l’équipe de développement du cœur de PHP : « the only mitigation is patching/upgrading PHP. »

Puis-je définir session.upload_progress.enabled dans .user.ini ou avec ini_set() ?+

Non. La progression d’envoi s’exécute pendant l’analyse de la requête, avant votre code. php.net recommande php.ini, un pool FPM ou une configuration serveur qui s’applique avant l’analyse, et exclut explicitement .user.ini et ini_set().

Désactiver la progression d’envoi va-t-il casser mon site ?+

Rarement. Cela ne concerne que les barres de progression construites sur la fonction de progression d’envoi en session de PHP. La plupart des interfaces modernes suivent la progression dans le navigateur.

Faut-il la réactiver après la mise à jour ?+

Seulement si vous l’utilisez. php.net conseille de la laisser désactivée si elle ne sert pas, même sur les versions corrigées.