Faille de sécurité PHP CVE-2026-109619 (php2shell) : corrigée, que faire maintenant

TL;DRCVE-2026-109619 est la seconde faille critique « php2shell » de PHP, corrigée le 21 octobre 2026 dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elle permet d'exécuter du code à distance en réutilisant un état interne qui a survécu à une requête précédente. La seule protection complète est la mise à jour. Si vous devez attendre, voici comment désactiver session.upload_progress au bon endroit, comment le vérifier, et comment rechercher des traces d'attaque.

Mise à jour du 22 octobre 2026. PHP a publié les correctifs le 21 octobre 2026 à 14:00 UTC (16:00 à Paris) : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. L'avis officiel confirme les numéros CVE-2026-109618 et CVE-2026-109619 et décrit les deux failles. Des tentatives d'exploitation sont signalées par plusieurs éditeurs de sécurité. Cet article, publié le 21 au matin avant l'annonce, a été mis à jour avec ces informations : la seule protection complète est désormais d'installer la version corrigée.

📌 CVE-2026-109619 en bref#

Le 20 octobre 2026, l'équipe de sécurité de PHP a annoncé une publication de sécurité, intervenue le 21 octobre à 14:00 UTC, corrigeant « deux vulnérabilités critiques, toutes deux notées CVSS v4.0 9.2 ». Les chercheurs ont surnommé l'ensemble php2shell. Nous avons consacré un article à la première faille, CVE-2026-109618, avec les versions corrigées et la marche à suivre.

L'avis officiel de PHP (GHSA-6wmf-4rv5-p3rp) décrit CVE-2026-109619 comme une exécution de code à distance par « état global périmé » : un état interne appartenant à une requête peut survivre après la libération de la mémoire qui le porte. Une requête suivante traitée par le même processus PHP peut alors utiliser cet état avant que l'initialisation normale ne le remette à zéro. Les données de progression d'envoi en session font partie des chemins confirmés pour y parvenir.

📌 Le lien avec session.upload_progress#

Avant la publication, plusieurs chercheurs rattachaient l'une des failles à la fonction session.upload_progress du module de sessions, en évoquant l'utilisation d'une zone mémoire déjà libérée. L'avis officiel le confirme pour CVE-2026-109619 : désactiver cette fonction bloque les chemins d'attaque confirmés passant par les sessions, sans couvrir d'autres variantes.

À 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.

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-fpm

Pensez aux anciennes versions de PHP restées installées sur le serveur : ce sont celles pour lesquelles une version corrigée est le moins souvent disponible. 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] = off

🌐 Sur un hébergement mutualisé#

PHP précise de ne pas compter sur .user.ini pour ce réglage : il est lu trop tard, après l'analyse de la requête. Sans accès à php.ini ou au pool PHP-FPM, vous ne pouvez donc pas appliquer cette mesure vous-même de façon fiable. Demandez à votre hébergeur s'il a installé la version corrigée de PHP ; c'est la seule réponse qui compte.

📌 Sur PHP 8.5#

PHP recommande en plus de régler fatal_error_backtraces=0 puis de redémarrer tous les processus PHP : cela bloque un autre chemin d'attaque confirmé, propre à cette version.

📌 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 :

1. Créez un fichier temporaire à la racine du site contenant <?php var_dump(ini_get('session.upload_progress.enabled'));
2. Ouvrez-le dans le navigateur : vous devez lire string(1) "0" ou string(0) "".
3. 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 => Off

📌 Les limites de cette mesure#

Désactiver session.upload_progress réduit le risque, rien de plus. L'avis officiel de PHP est explicite :

• la mesure bloque les chemins d'attaque confirmés passant par les sessions, pas les autres variantes de CVE-2026-109619 ;
• elle ne fait rien contre CVE-2026-109618, qui repose sur un autre mécanisme (voir notre article sur cette faille) ;
• PHP recommande aussi de supprimer les réglages invalides ou obsolètes appliqués par requête qui affichent des avertissements avant l'initialisation, et de corriger les erreurs fatales et dépassements de temps qu'un attaquant peut déclencher. Masquer les erreurs (error_reporting, display_errors, @) n'aide pas.

Un serveur non mis à jour reste donc exposé. La seule correction complète est l'installation de la version corrigée de PHP.

📌 Surveiller les signes d'attaque#

Des tentatives d'exploitation sont signalées depuis le 17 octobre 2026 selon Amazon, qui conseille de faire remonter les recherches à cette date. Une exploitation réussie se traduit par l'exécution de commandes sur le serveur. Surveillez :

• les requêtes POST d'envoi de formulaire (multipart) contenant la chaîne PHP_SESSION_UPLOAD_PROGRESS, à chercher dans les journaux du serveur web ou du pare-feu applicatif s'ils enregistrent le contenu des requêtes ;
• 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 le 17 octobre 2026 dans la racine web
find /var/www -name '*.php' -newermt 2026-10-17 -not -path '*/var/cache/*' | head -50

Si 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 ?#

Nous avons désactivé session.upload_progress sur tous nos serveurs le 21 octobre 2026 au matin, puis installé les versions corrigées de PHP le soir même, pour toutes les versions que nous hébergeons, y compris les plus anciennes grâce aux correctifs rétroportés. Vous n'avez rien à faire.

Si votre site tourne encore sur une version de PHP en fin de vie, nous vous conseillons de passer à une version maintenue de PHP 8 : écrivez-nous. Hébergé ailleurs, sur un serveur dédié ou un VPS ? Nous pouvons vérifier et mettre à jour votre serveur ou votre CMS. 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 ?#

Les deux permettent d'exécuter du code à distance et sont corrigées par la même publication. CVE-2026-109618 part d'une erreur de dépassement de mémoire qui laisse des données de requête à moitié initialisées ; CVE-2026-109619 repose sur un état interne qui survit d'une requête à l'autre dans un même processus PHP.

📌 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 faire ce réglage dans .user.ini ou avec ini_set() ?#

Non. PHP demande de le faire dans php.ini, dans un pool PHP-FPM ou dans la configuration du serveur, appliqués avant l'analyse de la requête, puis de redémarrer tous les processus PHP.

📌 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 installé la version corrigée et à quelle date.

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.