TL;DRCVE-2026-109619 est la seconde faille critique de PHP annoncée le 20 octobre 2026, dans la série surnommée « php2shell ». En attendant le correctif officiel, une mesure circule partout : désactiver la fonction session.upload_progress. Voici comment l'appliquer selon votre hébergement, comment vérifier qu'elle est active, et pourquoi elle ne remplace pas la mise à jour.
Article publié le 21 octobre 2026 au matin, avant la publication officielle. PHP a promis de publier « les détails complets, les versions concernées et les versions corrigées » avec ses correctifs, prévus le 21 octobre 2026 à 14:00 UTC (16:00 à Paris). Ce qui suit distingue ce que PHP a confirmé de ce qui circule encore à l'état de fuite. Vérifiez toujours l'annonce sur php.net avant d'agir.
CVE-2026-109619 en bref#
Le 20 octobre 2026, l'équipe de sécurité de PHP a annoncé une publication de sécurité pour le 21 octobre à 14:00 UTC, corrigeant « deux vulnérabilités critiques, toutes deux notées CVSS v4.0 9.2 ». Les chercheurs leur ont attribué les identifiants CVE-2026-109618 et CVE-2026-109619, et le surnom de php2shell. Nous avons consacré un article à la première faille, CVE-2026-109618, avec le calendrier et les versions concernées.
Soyons clairs : à l'heure où nous écrivons, aucune source publique fiable ne décrit séparément CVE-2026-109619. Les fiches de Tenable pour les deux numéros portent le même texte, et Qualys rappelle que PHP n'a pas encore repris ces identifiants. Plutôt que de recopier des rumeurs, cet article se concentre sur ce que vous pouvez faire dès maintenant, sans attendre les détails.
Le lien avec session.upload_progress#
Plusieurs chercheurs indépendants rattachent au moins une des deux failles à la fonction session.upload_progress du module de sessions de PHP. Ils évoquent une corruption de la mémoire (un « use-after-free », c'est-à-dire l'utilisation d'une zone mémoire déjà libérée) dans le code qui suit la progression d'un envoi de fichier. Un chercheur situe la seconde faille dans l'analyse des formulaires multipart, indépendamment de ce réglage. Rien de cela n'est confirmé par PHP.
À quoi sert cette fonction ? D'après le manuel de PHP, elle enregistre en session l'avancement d'un fichier en cours d'envoi, pour afficher une barre de progression. Elle est activée par défaut et se déclenche lorsqu'une requête POST contient un champ portant le nom défini par session.upload_progress.name (par défaut PHP_SESSION_UPLOAD_PROGRESS). Dans les faits, très peu de sites s'en servent : les barres de progression modernes sont calculées par le navigateur, en JavaScript.
| Réglage | Valeur par défaut | Valeur recommandée en attendant |
|---|---|---|
session.upload_progress.enabled | On (1) | Off (0) |
session.upload_progress.name | PHP_SESSION_UPLOAD_PROGRESS | Inchangé |
| Niveau de modification | PHP_INI_PERDIR : php.ini, pool PHP-FPM, .user.ini ou .htaccess, mais pas ini_set() | |
Bon à savoir. Désactiver cette fonction ne casse pas l'envoi de fichiers : seul le suivi de progression côté serveur disparaît. Si une page de votre site affiche une barre de progression d'envoi qui interroge le serveur, testez-la après le changement.
Comment désactiver session.upload_progress#
La bonne méthode dépend de la façon dont PHP tourne sur votre serveur. Un point commun : la modification doit être lue par le processus PHP qui sert vos pages, ce qui impose souvent un redémarrage ou un rechargement.
Sur un serveur dédié ou un VPS (php.ini)#
C'est la méthode la plus sûre, car elle couvre tous les sites servis par cette version de PHP. Sur Debian et Ubuntu, il existe un fichier php.ini par version et par mode d'exécution (fpm, apache2, cli). Plutôt que de modifier ces fichiers, ajoutez un petit fichier de configuration dédié :
# Pour PHP-FPM 8.4 (répétez pour chaque version installée)
echo 'session.upload_progress.enabled = Off' | sudo tee /etc/php/8.4/fpm/conf.d/99-php2shell.ini
# Si PHP tourne aussi en module Apache (mod_php)
echo 'session.upload_progress.enabled = Off' | sudo tee /etc/php/8.4/apache2/conf.d/99-php2shell.ini
# Tester la configuration avant de redémarrer
sudo php-fpm8.4 -t
sudo systemctl restart php8.4-fpmPensez aux anciennes versions de PHP restées installées sur le serveur : ce sont justement celles qui ne seront pas corrigées. Listez-les avec ls /etc/php/ et traitez chacune.
Dans un pool PHP-FPM précis#
Si vous ne voulez agir que sur certains sites, ajoutez cette ligne dans le fichier du pool concerné (par exemple /etc/php/8.4/fpm/pool.d/monsite.conf). Avec php_admin_flag, le réglage ne peut plus être modifié par le site lui-même.
; Désactive le suivi de progression d'envoi pour ce pool
php_admin_flag[session.upload_progress.enabled] = offSur un hébergement mutualisé#
Sans accès à php.ini, deux options existent selon le mode d'exécution de PHP :
- PHP en CGI ou FastCGI (cas le plus courant) : créez ou complétez un fichier
.user.inià la racine du site avec la lignesession.upload_progress.enabled = Off. PHP relit ce fichier périodiquement (par défaut toutes les 300 secondes), le changement n'est donc pas immédiat. - PHP en module Apache (mod_php) : ajoutez
php_flag session.upload_progress.enabled offdans le fichier.htaccess. Attention, cette directive provoque une erreur 500 si PHP ne tourne pas en module Apache : testez immédiatement le site.
Le plus simple reste de demander à votre hébergeur s'il a appliqué la mesure au niveau du serveur.
Vérifier que la mesure est bien active#
La commande php -i ne lit que la configuration de PHP en ligne de commande, pas celle de PHP-FPM ou d'Apache. Pour vérifier ce que voit réellement votre site :
- Créez un fichier temporaire à la racine du site contenant
<?php var_dump(ini_get('session.upload_progress.enabled')); - Ouvrez-le dans le navigateur : vous devez lire
string(1) "0"oustring(0) "". - Supprimez le fichier immédiatement après.
# Vérifier la configuration chargée par PHP-FPM 8.4 (Debian / Ubuntu)
sudo php-fpm8.4 -i | grep session.upload_progress.enabled
# Résultat attendu : session.upload_progress.enabled => Off => OffLes limites de cette mesure#
Désactiver session.upload_progress est une mesure de réduction du risque, rien de plus. Les avis divergent sur son efficacité :
| Source | Position |
|---|---|
| PHP | Ne mentionne pas cette mesure ; recommande de mettre à jour dès la publication |
| Flatt Security | Devrait aider « avec une certaine probabilité », sans garantie à 100 % |
| Chercheur à l'origine d'une reproduction | Ne bloque qu'une des deux failles |
| Huntress | Recommande inventaire, isolement des versions en fin de vie et surveillance |
Autrement dit, même avec ce réglage, un serveur non mis à jour reste potentiellement exposé à l'autre faille. La seule correction complète est l'installation de la version corrigée de PHP.
Surveiller les signes d'attaque#
Une exploitation réussie de php2shell se traduirait par l'exécution de commandes sur le serveur. Huntress conseille de surveiller :
- les processus PHP (
php-fpm,php-cgi,apache2,httpd) qui lancent un shell, un interpréteur ou un outil de téléchargement (sh,bash,curl,wget) ; - les connexions sortantes inhabituelles depuis le serveur web, typiques d'un accès à distance ouvert par un attaquant ;
- l'apparition de fichiers PHP récents dans les dossiers d'envoi (uploads, images, cache).
# Processus enfants des workers PHP-FPM (un shell ici est anormal)
ps -eo pid,ppid,user,cmd --forest | grep -A3 'php-fpm: pool'
# Fichiers PHP modifiés depuis 2 jours dans la racine web
find /var/www -name '*.php' -mtime -2 -not -path '*/var/cache/*' | head -50Si vous découvrez un fichier suspect, ne vous contentez pas de le supprimer : conservez-en une copie hors du site, cherchez comment il est arrivé là, changez les mots de passe et les clés d'accès, puis installez la version corrigée de PHP.
Vous êtes hébergé chez Websource ?#
Websource héberge un grand nombre de sites PHP (WordPress, PrestaShop, Symfony, Drupal, Joomla…) et suit cette publication de sécurité. Si votre site tourne sur une ancienne version de PHP, ou si vous voulez savoir où en est votre hébergement, écrivez-nous : nous vous aidons à évaluer votre exposition et à préparer la montée de version, que vous soyez hébergé chez nous ou ailleurs. Pour un nouveau projet, nos offres d'hébergement web incluent des versions de PHP maintenues.
Questions fréquentes#
Quelle différence entre CVE-2026-109619 et CVE-2026-109618 ?#
Au matin du 21 octobre 2026, aucune source publique fiable ne les distingue techniquement. Ce sont les deux failles critiques annoncées par PHP, corrigées par la même publication. Les détails propres à chacune sont attendus avec le correctif.
Désactiver session.upload_progress peut-il casser mon site ?#
Très rarement. Les envois de fichiers continuent de fonctionner ; seul le suivi de progression enregistré en session côté serveur disparaît. Testez simplement vos formulaires d'envoi après le changement.
Puis-je désactiver ce réglage avec ini_set() dans mon code ?#
Non. Ce réglage est de niveau PHP_INI_PERDIR : il se modifie dans php.ini, dans le pool PHP-FPM, dans .user.ini ou dans .htaccess avec mod_php, mais pas pendant l'exécution du script.
Faut-il garder ce réglage après la mise à jour ?#
Vous pouvez le garder si votre site n'utilise pas cette fonction : cela réduit la surface d'attaque. Il ne dispense pas de mettre à jour PHP, qui reste la seule correction complète.
Mon hébergeur s'en occupe-t-il ?#
Sur un hébergement mutualisé ou infogéré, c'est en principe l'hébergeur qui met à jour PHP. Demandez-lui s'il a appliqué la mesure temporaire et quand il installera la version corrigée.
Article publié le 21/10/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.
