PHP vient de signaler une nouvelle faille d'exécution de code à distance (un pirate fait tourner ses propres commandes sur votre serveur), CVE-2026-115560, sans correctif pour l'instant. La réponse courte : elle ne concerne qu'un montage très particulier, PHP la juge peu probable, et une ligne de configuration la neutralise. Plus urgent : les correctifs publiés quelques jours plus tôt.
Que dit PHP sur cette faille ?
Selon BleepingComputer, qui cite l'avis de PHP, trois conditions doivent être réunies. L'application règle le format de stockage des sessions (session.serialize_handler) sur php_binary ou php_serialize. Elle le repasse ensuite à php en cours de route, avec ini_set() (une commande qui modifie un réglage depuis le code), avant de démarrer la session. Et l'option session.upload_progress reste active.
Cette option est activée par défaut. Elle suit l'avancement d'un envoi de fichier, et se déclenche dès qu'une requête contient le champ prévu, même si votre site n'affiche aucune barre de progression. Une application qui ne change jamais ce format à l'exécution n'est pas concernée. The Hacker News relaie la même alerte.
Ce que nous n'avons pas trouvé : les versions de PHP touchées, le score de gravité, la date du correctif. PHP traitera la faille dans son cycle normal de publication.
Comment la neutraliser sans casser son site ?
PHP recommande de passer session.upload_progress.enabled à 0. D'après lilting.ch, ce réglage ne se change pas avec ini_set() : il faut passer par le php.ini, un fichier .user.ini ou, selon l'hébergement, un .htaccess. Un phpinfo() temporaire, supprimé aussitôt après, confirme la valeur.
Les envois de fichiers continuent de fonctionner. Seule la barre de progression disparaît, et la plupart des sites n'en ont pas.
Reste la deuxième condition. Une recherche de ini_set('session.serialize_handler' dans le code du projet suffit à dire si elle existe.
Pourquoi PHP2Shell passe avant ?
Parce que celle-là est corrigée, et que l'exploitation paraît bien plus simple. Selon Help Net Security, les deux failles PHP2Shell, notées 9,2 sur 10, sont corrigées depuis le 21 octobre 2026 dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Une requête sans authentification suffirait, d'après la même source. Nous avons détaillé la mise à jour dans notre article sur PHP2Shell.
Sur un serveur installé par paquets, le numéro de version peut ne pas bouger : lisez le changelog du paquet, puis redémarrez PHP-FPM ou Apache. Et si vous êtes sur PHP 8.1 ou plus ancien, vous êtes le plus exposé.
Ce que nous en pensons
Une faille conditionnelle ne justifie pas de couper un site. Elle révèle en revanche un angle mort fréquent : personne ne sait précisément comment PHP est réglé sur le serveur, et les mises à jour du CMS ou du framework ne touchent pas à PHP.
C'est typiquement le travail d'un contrat d'hébergement et maintenance : quelqu'un doit savoir quelle version tourne, avec quels réglages. Pour une application ancienne dont plus personne ne connaît le code, une reprise d'application existante commence par cet inventaire. Et si vous cherchez qui peut le mener, notre article sur ce qu'il faut vérifier avant de missionner un développeur PHP senior peut aider.
- CVE-2026-115560 exige une configuration inhabituelle et n'a pas encore de correctif : PHP la juge peu probable.
- Mettre
session.upload_progress.enabledà 0 la neutralise, sans empêcher les envois de fichiers. - Appliquer d'abord les correctifs PHP2Shell, puis vérifier la configuration.
- Les mises à jour de CMS ne mettent pas PHP à jour : contrôlez le serveur.
Questions fréquentes
Faut-il couper le site en attendant un correctif ?
Non. PHP juge le scénario peu probable et une simple option de configuration le neutralise. Aucune interruption de service n'est nécessaire.
Désactiver cette option casse-t-elle les formulaires d'envoi de fichiers ?
Non. Seul le suivi de progression de l'envoi est coupé. Les fichiers continuent d'être reçus normalement, d'après l'analyse publiée par lilting.ch.
Mon CMS à jour me protège-t-il ?
Pas pour cette faille. Mettre à jour WordPress ou Laravel ne met pas PHP à jour : c'est le serveur lui-même qu'il faut regarder.
Mon site tourne sur un vieux PHP, que faire ?
PHP 8.1 et les versions antérieures ne sont plus supportées. Pour PHP2Shell, seuls des backports à compiler soi-même existent : c'est le moment d'envisager une migration.