CVE-2026-115560 : troisieme faille PHP cette semaine, session upload progress exploitable sans correctif

Deux jours après la publication d'urgence des correctifs PHP2Shell (CVE-2026-109618 et CVE-2026-109619), l'équipe de sécurité de PHP a signalé le 23 octobre 2026 une troisième vulnérabilité : CVE-2026-115560. Il s'agit d'un vecteur d'exécution de code à distance (RCE) lié à la fonctionnalité session.upload_progress, exploitable lorsqu'une application change le session.serialize_handler à la volée avec ini_set() avant d'appeler session_start(). Contrairement aux deux CVE précédentes, aucun correctif n'est disponible à ce jour : la correction est prévue dans la prochaine release de routine. Tous les administrateurs qui hébergent des sites web PHP sur un VPS, un serveur dédié ou un hébergement mutualisé sont concernés par cet avis.

Source : avis informatif de PHP du 23 octobre 2026.

L'essentiel en 30 secondes

• CVE concernée : CVE-2026-115560, vecteur RCE via session.upload_progress combiné à un changement de serialize_handler en cours d'exécution.
• Qui est réellement exposé : les applications dont les scripts PHP définissent session.serialize_handler à php_binary ou php_serialize dans leur configuration, puis le basculent vers php via ini_set() avant session_start(). L'équipe PHP qualifie cette combinaison d'inhabituelle.
• Correctif : pas de patch immédiat. Le correctif sera intégré au prochain package de routine de PHP.
• Mitigation : configurer session.upload_progress.enabled = 0 dans php.ini, la même mesure que pour PHP2Shell.
• Si vous avez déjà appliqué la mitigation PHP2Shell : vous êtes couvert.

Trois failles PHP en une semaine

La semaine du 21 octobre 2026 est dense pour les administrateurs de serveurs PHP. Lundi, les versions PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigeaient en urgence les deux CVE critiques PHP2Shell, notées 9.2 sur l'échelle CVSS v4.0. Mercredi, l'équipe PHP publie un avis informatif sur CVE-2026-115560 : un vecteur RCE supplémentaire qui passe par le même composant, session.upload_progress, mais sous des conditions bien plus restrictives.

Le point central est que la mitigation déjà recommandée pour CVE-2026-109619, c'est-à-dire désactiver session.upload_progress.enabled, couvre aussi cette nouvelle CVE. L'avis le mentionne explicitement : ce réglage figurait déjà dans l'advisory GHSA-6wmf-4rv5-p3rp publiée deux jours plus tôt. Autrement dit, les administrateurs de VPS Linux ou de serveurs dédiés qui ont suivi les recommandations de notre article sur PHP2Shell n'ont, dans l'immédiat, rien de plus à faire.

Impact selon votre type d'hébergement

La marche à suivre dépend de la façon dont votre serveur est administré. L'accès au fichier php.ini et la possibilité de redémarrer PHP-FPM ou Apache varient selon que vous êtes sur un hébergement mutualisé, un VPS ou un serveur dédié.

Quel que soit votre type d'hébergement, faites un backup de votre configuration PHP avant toute modification : copiez votre fichier php.ini actuel ou exportez la configuration depuis votre panel. Sur un VPS Debian ou Ubuntu, le fichier se trouve dans /etc/php/8.x/fpm/php.ini (PHP-FPM) ou /etc/php/8.x/apache2/php.ini (mod_php). Pour une sauvegarde complète de votre serveur, consultez notre guide sauvegarder un VPS avec rsync.

Comment fonctionne CVE-2026-115560

Pour que la faille soit exploitable, trois conditions doivent être réunies simultanément :

1. L'application (ou sa configuration par défaut) définit session.serialize_handler à php_binary ou php_serialize.
2. À l'exécution, le code PHP appelle ini_set('session.serialize_handler', 'php') pour basculer vers le handler natif php.
3. session.upload_progress.enabled est à 1 (sa valeur par défaut), et l'application appelle ensuite session_start().

Quand ces trois conditions sont remplies, les données de progression d'envoi de fichier enregistrées en session avec un format de sérialisation peuvent être relues avec un autre format. Cette désynchronisation ouvre un vecteur d'exécution de code. En dehors de cette combinaison précise, le mécanisme n'est pas déclenchable.

Qui est réellement exposé

La réponse courte : très peu de serveurs. L'équipe PHP décrit elle-même cette configuration comme « unlikely in practice ». Par défaut, session.serialize_handler vaut php et la grande majorité des applications PHP ne le modifient jamais, encore moins pour le changer en cours de route avec ini_set().

Les cas où cette configuration se rencontre sont rares. Certains scripts PHP configurent php_serialize dans leur php.ini ou .htaccess pour supporter des clés de session contenant le caractère pipe (|), puis basculent vers php dans un fichier d'amorçage. C'est un schéma de contournement ancien, documenté dans la communauté PHP, mais marginal. Les CMS courants (WordPress, Joomla, Drupal), les frameworks (Laravel, Symfony) et les applications de gestion comme Pterodactyl n'effectuent pas ce changement de handler. Les connexions aux bases de données MySQL ou MariaDB et les sessions stockées en base ne sont pas non plus un vecteur pour cette CVE, sauf si le code qui gère les sessions change le serialize_handler à la volée.

Vérifier votre configuration PHP

Deux réglages suffisent à évaluer votre exposition. Connectez-vous en SSH à votre serveur VPS et lancez ces commandes. Sur Debian 12 et Ubuntu 24.04, les chemins ci-dessous sont les mêmes : seule la version de PHP (8.2, 8.3 ou 8.4) change.

Vérifier session.upload_progress.enabled

php -i | grep session.upload_progress.enabled

Si la valeur affichée est Off ou 0, le vecteur d'attaque est fermé, que ce soit pour CVE-2026-115560 ou pour la CVE-2026-109619 de PHP2Shell.

Vérifier session.serialize_handler

php -i | grep session.serialize_handler

Si la valeur est php (la valeur par défaut), votre configuration système n'est pas dans le cas de figure vulnérable. Il faudrait en plus qu'un script PHP change ce réglage à l'exécution, ce qui est très rare.

Vérifier la configuration vue par le serveur web

La ligne de commande (php -i) et le serveur web peuvent utiliser des fichiers php.ini différents. Sur un VPS sous Debian ou Ubuntu, PHP-FPM utilise /etc/php/8.x/fpm/php.ini, tandis que la CLI utilise /etc/php/8.x/cli/php.ini. Si votre serveur web est Nginx avec PHP-FPM, vérifiez la configuration du pool FPM :

# Vérifier quel php.ini est chargé par PHP-FPM
php-fpm8.3 -i | grep "Loaded Configuration"

# Vérifier les overrides dans la config du pool
grep -r "upload_progress" /etc/php/8.3/fpm/pool.d/
grep -r "serialize_handler" /etc/php/8.3/fpm/pool.d/

Pour la version vue par le serveur web Apache (mod_php), utilisez un fichier phpinfo() temporaire, accessible depuis l'URL de votre site, puis supprimez-le immédiatement après consultation. Vérifiez aussi que personne ne surcharge ce réglage avec php_value ou php_admin_value dans la configuration du virtual host ou un fichier .htaccess.

Chercher un ini_set dans le code applicatif

Si vous soupçonnez une application d'effectuer le changement de handler en cours d'exécution, recherchez dans le répertoire de vos sites web :

grep -r "ini_set.*serialize_handler" /var/www/

Si cette commande ne retourne rien, vos scripts PHP ne changent pas le handler à l'exécution : le scénario d'attaque ne s'applique pas.

Consulter les logs PHP

Profitez-en pour vérifier vos fichiers de log PHP. Des avertissements liés au serialize_handler ou à la sérialisation de sessions peuvent indiquer un problème de configuration :

# Log d'erreurs PHP-FPM (chemin Debian/Ubuntu par défaut)
tail -100 /var/log/php8.3-fpm.log | grep -i "session\|serialize"

# Log d'erreurs Nginx
tail -100 /var/log/nginx/error.log | grep -i "php\|upstream"

# Log d'erreurs Apache
tail -100 /var/log/apache2/error.log | grep -i "session\|php"

Pour aller plus loin dans l'analyse des logs de votre serveur, consultez notre guide analyser les logs avec journalctl et notre guide sur la rotation des journaux Linux.

Appliquer la mitigation

La mesure est identique à celle recommandée pour PHP2Shell : désactiver session.upload_progress dans php.ini. Avant de modifier quoi que ce soit, faites une copie de sauvegarde (backup) de la configuration actuelle :

# Backup de la configuration PHP-FPM avant modification
sudo cp /etc/php/8.3/fpm/php.ini /etc/php/8.3/fpm/php.ini.bak
sudo cp /etc/php/8.3/fpm/pool.d/www.conf /etc/php/8.3/fpm/pool.d/www.conf.bak

Sur un VPS ou serveur dédié avec PHP-FPM (Nginx ou Apache)

Ajoutez la directive dans la configuration du pool PHP-FPM. C'est la méthode la plus sûre car php_admin_flag empêche tout script PHP ou fichier .htaccess de réactiver la fonctionnalité :

# /etc/php/8.3/fpm/pool.d/www.conf (adaptez à votre version)
php_admin_flag[session.upload_progress.enabled] = off

Redémarrez PHP-FPM après la modification :

sudo systemctl restart php8.3-fpm

Vérifiez dans les logs que le service a bien redémarré sans erreur :

sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm --since "1 minute ago"

Sur Apache avec mod_php

Ajoutez la directive directement dans php.ini :

session.upload_progress.enabled = 0

Puis redémarrez Apache :

sudo systemctl restart apache2

Sur un panel Plesk

Si votre serveur est administré via Plesk, la modification se fait sans SSH. Dans l'interface Plesk : Outils & paramètres > Paramètres PHP (ou au niveau du domaine : Sites web & domaines > Paramètres PHP). Cherchez session.upload_progress.enabled et passez la valeur à Off. Plesk redémarre PHP-FPM automatiquement après l'enregistrement. La même logique s'applique sur ISPConfig ou tout autre panel de gestion de serveur web.

Sur un hébergement mutualisé

Si vous n'avez pas d'accès root, essayez d'ajouter la directive dans un fichier .user.ini à la racine de votre site web (cette méthode fonctionne avec PHP-FPM mais pas avec mod_php). Si votre hébergeur ne le permet pas, contactez-le directement en citant la référence CVE-2026-115560.

Avec Docker

Pour les administrateurs qui utilisent Docker, la même directive s'ajoute dans le php.ini personnalisé de votre image ou dans le docker-compose.yml (consultez notre guide Docker Compose sur VPS Linux).

Ce réglage désactive la fonctionnalité de suivi de progression des envois de fichiers via les sessions PHP. En pratique, cette fonctionnalité est utilisée par un nombre très restreint d'applications pour afficher une barre de progression d'upload côté navigateur. Les CMS et frameworks majeurs (WordPress, Laravel, Symfony) n'en dépendent pas. Les fonctionnalités critiques de vos sites web (connexions utilisateur, bases de données MySQL ou MariaDB, envoi de fichiers, SMTP, FTP) ne sont pas affectées par cette désactivation.

Déjà protégé par la mitigation PHP2Shell ?

Si vous avez suivi les recommandations de notre article sur PHP2Shell et que vous avez configuré session.upload_progress.enabled = 0 dans votre configuration, vous n'avez rien à faire de plus. L'avis de PHP le confirme explicitement : cette directive était déjà listée comme mitigation dans l'advisory GHSA-6wmf-4rv5-p3rp pour CVE-2026-109619.

La mise à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, qui corrige PHP2Shell, ne corrige pas CVE-2026-115560. Le correctif pour cette nouvelle CVE sera inclus dans la prochaine release de routine. En attendant, la directive reste le seul rempart. Si vous avez mis à jour PHP mais retiré la mitigation temporaire parce que vous pensiez le danger écarté, remettez-la en place et redémarrez PHP-FPM.

Que faire en attendant le correctif

Pas de panique : la gravité réelle de CVE-2026-115560 est bien moindre que celle de PHP2Shell. Les deux CVE critiques de lundi permettaient une exécution de code sans aucune condition applicative particulière, sur n'importe quelle installation PHP exposée au web. Ici, l'attaquant a besoin que le code de l'application effectue lui-même le changement de handler, ce qui élimine la quasi-totalité des serveurs.

En résumé, la feuille de route pour les administrateurs de serveurs :

1. Mettez à jour PHP vers les versions corrigées (8.2.35, 8.3.36, 8.4.27, 8.5.12) si ce n'est pas déjà fait. Sur Debian et Ubuntu, mettez à jour les packages PHP via apt update && apt upgrade. Ces versions corrigent PHP2Shell, pas CVE-2026-115560, mais elles restent indispensables.
2. Maintenez session.upload_progress.enabled = 0 dans votre php.ini jusqu'à la prochaine release de routine qui corrigera CVE-2026-115560.
3. Vérifiez vos scripts PHP : si aucun n'appelle ini_set('session.serialize_handler', ...), votre exposition à cette CVE spécifique est nulle, même sans la mitigation.
4. Surveillez les logs de votre serveur pour détecter toute tentative d'exploitation. Les entrées suspectes liées aux sessions PHP ou à l'upload de fichiers méritent une attention particulière.
5. Automatisez les mises à jour de sécurité pour ne pas rater la future release qui contiendra le correctif.
6. Faites un backup de vos données et de vos configurations. Consultez notre guide chiffrer les sauvegardes hors site pour protéger vos copies de sauvegarde.

Bilan de la semaine PHP

Trois CVE, un seul geste de mitigation. Si vous administrez un VPS Linux ou un serveur dédié qui fait tourner PHP, la combinaison « mise à jour des packages + session.upload_progress.enabled = 0 configuré dans php.ini » couvre les trois vulnérabilités connues cette semaine. Que vous utilisiez Nginx ou Apache, Debian ou Ubuntu, un panel Plesk ou une administration en ligne de commande, la procédure est la même : un seul réglage à vérifier et un redémarrage de service. Retrouvez tous nos guides d'administration serveur pour renforcer la sécurité de vos machines.