CVE-2026-115560 : nouvelle faille RCE PHP sans correctif, la fenêtre d'exposition s'allonge

Ce qui s’est passé

Le 21 octobre 2026, PHP a publié des versions d’urgence (8.5.12, 8.4.27, 8.3.36 et 8.2.35) pour corriger les deux failles critiques PHP2Shell, CVE-2026-109618 et CVE-2026-109619. En une journée, les tentatives d’attaque se comptaient déjà par millions.

Deux jours plus tard, le 23 octobre, PHP a révélé une troisième faille : CVE-2026-115560, une vulnérabilité d’exécution de code à distance (RCE) dans la gestion des sessions. Les versions du 21 octobre ne la corrigent pas, et aucun correctif d’urgence n’est prévu. Le correctif arrivera avec la prochaine version de maintenance régulière de PHP, accompagné de l’avis de sécurité complet.

Pourquoi celle-ci est différente

Soyons clairs : cette faille est beaucoup plus ciblée que PHP2Shell. Une application n’est exposée que si les trois conditions suivantes sont réunies :

1. Configuration : session.serialize_handler vaut php_binary ou php_serialize.

2. Code : l’application repasse cette option à php à l’exécution via ini_set(), avant d’appeler session_start().

3. Valeur par défaut conservée : session.upload_progress.enabled est toujours activé, ce qui est le cas par défaut.

PHP juge lui-même cette configuration peu probable, et aucune exploitation n’a été signalée. Mais « peu probable » ne veut pas dire « impossible », pour deux raisons :

• L’appel à risque n’est pas forcément dans votre code. Il peut se trouver dans une dépendance Composer, sous vendor/, là où presque personne ne regarde.

• L’essentiel reste inconnu. Les versions concernées, le score CVSS et la cause exacte n’ont pas été publiés. Les attaquants lisent le même avis que vous, et la gestion des sessions PHP est désormais le code le plus scruté du web.

Pour les décideurs : trois actions cette semaine

1. Vérifiez que PHP2Shell est corrigé partout. Tous les serveurs, tous les environnements. CVE-2026-115560 ne doit pas ralentir la correction des failles déjà attaquées.

2. Vérifiez que le contournement est appliqué partout. Une seule ligne de configuration couvre à la fois CVE-2026-109619 et cette nouvelle faille. Assurez-vous qu’elle est en production, pas seulement planifiée.

3. Demandez combien de temps vous restez exposés. C’est la troisième faille RCE PHP en trois jours, et le prochain correctif dépend du calendrier de PHP, pas du vôtre. Si votre seule défense est le correctif, quelqu’un d’autre décide de la durée de votre exposition.

Pour les équipes techniques : vérifier et atténuer

Vérifier votre exposition

Recherchez toute référence au sérialiseur de session dans la configuration et le code, vendor/ compris :

grep -rn "serialize_handler" /etc/php* /etc/httpd /etc/apache2 2>/dev/null
grep -rn "serialize_handler" /var/www --include="*.php" --include=".htaccess" --include=".user.ini"

Contrôlez ensuite les valeurs effectives sur chaque environnement d’exécution, car CLI et FPM peuvent différer :

php -i | grep -E "session.serialize_handler|session.upload_progress.enabled"

Vous êtes probablement concernés si la configuration indique php_binary ou php_serialize et que le code appelle ini_set('session.serialize_handler', 'php'). PHP n’a pas précisé si une directive php_value dans un .htaccess ou un .user.ini déclenche le même chemin : considérez-les comme suspectes.

Atténuer dès aujourd’hui

session.upload_progress.enabled = 0

• Appliquez ce réglage dans php.ini, dans le pool PHP-FPM ou dans la configuration du serveur web. Ne comptez pas sur ini_set() ni sur .user.ini.

• Redémarrez tous les workers PHP, puis vérifiez avec php -i ou phpinfo() depuis le pool réellement utilisé par l’application.

• Si vous l’avez déjà appliqué le 21 octobre pour PHP2Shell, laissez-le en place.

• Les barres de progression d’upload natives de PHP cesseront de fonctionner. La plupart des interfaces modernes gèrent la progression côté navigateur.

La place de CYBERDEFENSE.AI

Trois failles RCE PHP en trois jours, dont une toujours sans correctif. À chaque étape, les protections traditionnelles ont attendu quelque chose : un correctif, une signature, une nouvelle règle de blocage, un changement de configuration. Chaque attente ouvre une fenêtre d’exposition, et c’est précisément là que les attaquants vont le plus vite.

Le WAF préemptif de CYBERDEFENSE.AI n’attend pas. Il s’appuie sur l’intelligence artificielle pour analyser en temps réel le comportement des applications, sans signatures, sans règles et sans correctifs réactifs. Concrètement :

• Aucune mise à jour n’a été nécessaire pour PHP2Shell, et aucune ne l’est pour CVE-2026-115560. La protection était en place avant même la divulgation de ces failles.

• Les tentatives d’exploitation ressortent comme des comportements anormaux. Les scanners automatisés qui balaient des milliers de sites et les requêtes qui ne correspondent pas à l’usage normal de votre application sont détectés et bloqués.

• Le renseignement sur les menaces est partagé sur toute la plateforme. Les adresses IP déjà repérées en train d’attaquer ailleurs sont bloquées avant d’atteindre vos applications.

Une couche de protection, pas un substitut : continuez à appliquer les correctifs. Mais avec une défense préemptive devant vos applications, le délai entre divulgation et correction cesse d’être une période d’exposition.

À retenir

• CVE-2026-115560 est une nouvelle faille RCE PHP, toujours sans correctif. Les correctifs PHP2Shell ne la couvrent pas.

• L’exposition dépend d’une configuration de session précise, mais le code déclencheur peut se cacher dans des dépendances tierces.

• Appliquez session.upload_progress.enabled=0 au niveau serveur dès aujourd’hui, puis mettez à jour dès la prochaine version de PHP.

• Une sécurité qui dépend des correctifs vous laisse exposés aussi longtemps qu’ils se font attendre. La protection préemptive referme cette fenêtre.