Vous avez désactivé Session Upload Progress pour vous protéger des failles PHP2Shell ? Gardez ce réglage en place. L’équipe de PHP signale un nouveau vecteur permettant l’exécution de code malveillant, la CVE-2026-115560, et elle passe par la même fonction. Voici ce qu’il faut retenir.
Pour rappel, le 21 octobre 2026, l’équipe de PHP a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 afin de corriger PHP2Shell, deux failles critiques (CVE-2026-109618 et CVE-2026-109619) permettant d’exécuter du code à distance sans authentification. J’ai publié un article à propos de ces correctifs, et depuis, on a appris que des tentatives d’exploitation avaient été repérées par Amazon quatre jours avant la sortie des correctifs.
Deux jours plus tard, le 23 octobre, PHP a publié un avis à propos d’un nouveau problème de sécurité, référencé CVE-2026-115560. Sur le papier, c’est une nouvelle faille permettant une exécution de code à distance (RCE) sans correctif. Dans les faits, je vous invite à ne pas paniquer : l’équipe de PHP la décrit d’ailleurs comme un vecteur d’exécution de code peu probable et ne publiera pas de version en urgence. Ce qui n’empêche pas l’arrivée d’un futur patch de sécurité.
Ce problème est distinct de PHP2Shell. De ce fait, les versions du 21 octobre ne le corrigent pas, puisque PHP renvoie à sa prochaine mise à jour de maintenance. Le seul point commun entre PHP2Shell et cette nouvelle faille, c’est que la mesure d’atténuation est la même que l’une des mesures temporaires déjà recommandées pour la CVE-2026-109619.
CVE-2026-115560 : trois conditions à réunir
D’après l’équipe de PHP, le problème ne peut survenir qu’avec une combinaison inhabituelle entre la configuration de PHP et le code de l’application. Cela limite d’entrée les possibilités d’exploitation de cette nouvelle vulnérabilité. Toutes les conditions spécifiées ci-dessous doivent être réunies :
Configuration de PHP : la directive session.serialize_handler est définie sur php_binary ou php_serialize.
Code de l’application : l’application repasse cette directive sur php pendant l’exécution, avec ini_set(), avant d’appeler session_start().
Session Upload Progress : la fonction est toujours active, ce qui est le cas par défaut.
Le premier point écarte déjà la configuration par défaut, puisque session.serialize_handler vaut php par défaut. Par ailleurs, une application qui ne modifie jamais ce gestionnaire pendant l’exécution peut conserver Session Upload Progress actif sans être exposée par ce chemin. Autrement dit, il faut une configuration qui sort de l’ordinaire, et une application qui agit aussi d’une façon spécifique.
“Comme cette configuration est peu probable en pratique, nous la traitons dans le cycle de publication habituel et publierons un bulletin complet pour CVE-2026-115560 avec la prochaine version.”, précise l’équipe de PHP. On est loin du coup de pression qu’ils ont mis à tout le monde avant l’arrivée des patchs pour les failles PHP2Shell.
Pour le moment, plusieurs informations manquent : PHP n’a communiqué ni la liste des versions affectées, ni la version qui contiendra le correctif, ni de score CVSS.
Ce qu’il faut faire, et ce qu’il ne faut pas faire
La recommandation de PHP pour se protéger de cette faille, et c’est là qu’on en revient à l’une des atténuations que vous connaissez désormais : passer session.upload_progress.enabled à 0. Si vous l’avez déjà fait suite à PHP2Shell, il n’y a rien de plus à faire, à condition de laisser ce réglage en place.
Le bon emplacement : comme l’indique le bulletin GHSA-6wmf-4rv5-p3rp consacré à la CVE-2026-109619, la directive doit être définie dans le php.ini, dans le pool PHP-FPM ou dans la configuration du serveur, puis chaque worker doit être redémarré. Ne comptez ni sur ini_set() ni sur un fichier .user.ini.
Le contrôle de votre code : une recherche de session.serialize_handler dans le code de vos applications (un grep récursif suffit) vous dira rapidement si vous êtes concerné par ce scénario.
L’effet de bord : cette fonction sert à suivre l’avancement d’un envoi de fichier, en général pour afficher une barre de progression. Une application qui s’appuie dessus perdra cet affichage.
Il y a d’ailleurs une précision à propos de cette fameuse fonction Session Upload Progress : “Il pourrait être prudent de passer session.upload_progress.enabled à 0 si vous n’avez pas besoin de cette fonction, même après avoir appliqué le correctif, car de plus en plus d’attaquants cherchent des failles dans cette fonction peu utilisée et peu testée.”, peut-on lire.
Vous pouvez partir en week-end l’esprit tranquille !
Cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Mon obsession depuis près de 15 ans ? Rendre l’administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu’un métier, l’IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.