Deux jours après les correctifs d’urgence contre PHP2Shell, PHP a publié le 23 octobre 2026 un second avis, pour une nouvelle faille PHP enregistrée sous le numéro CVE-2026-115560. Le scénario est jugé peu probable : aucune version d’urgence, un simple réglage du serveur en attendant le correctif. Voici comment savoir si votre boutique PrestaShop est concernée et quoi demander à votre hébergeur, ou nous confier la vérification.
PHP juge le risque peu probable et ne sort pas de version d’urgence pour cette nouvelle faille PHP.
Il faut trois conditions réunies, dont un code qui change le format des sessions en cours de route. Le cœur de PrestaShop ne le fait pas.
Le geste conseillé, session.upload_progress.enabled=0, se règle sur le serveur, puis PHP redémarre. Si c’est déjà fait depuis le 21 octobre, PHP n’exige rien de plus pour cet avis.
La priorité reste le correctif du 21 octobre, pour lequel des exploits circulent déjà.
Ce que PHP a publié le 23 octobre
L’avis tient en deux paragraphes, sur la page d’accueil de php.net. Il porte sur la CVE-2026-115560 et contient cette phrase : « The issue can only occur under an unusual combination of configuration and application code. » En français, le problème n’apparaît qu’avec une combinaison inhabituelle de configuration du serveur et de code de l’application.
Pour l’instant, PHP n’a publié ni avis détaillé, ni score de gravité, ni liste des versions touchées. L’avis complet sortira avec la prochaine version corrective normale, dont la date n’est pas annoncée. Les versions du 21 octobre, les plus récentes, ne le contiennent donc pas.
En attendant, PHP propose de couper une fonction rarement utilisée en boutique, le suivi d’avancement des envois de fichiers.
Trois conditions à réunir pour être exposé
PHP ne parle de risque que si ces trois éléments se cumulent sur le même serveur.
- Le format des sessions,
session.serialize_handler, qui décide comment PHP range les données d’un visiteur, est réglé surphp_binaryouphp_serializedans la configuration. - Pendant l’exécution, le code repasse ce format à
phpavecini_set(), juste avant d’ouvrir la session. - Upload progress, le suivi d’avancement des envois de fichiers, est encore actif (sa valeur par défaut).
Or, selon la documentation de PHP, ce format vaut php par défaut. Un serveur resté sur la valeur d’origine n’est donc pas concerné.
Par prudence, l’avis du 21 octobre sur PHP2Shell conseille de couper ce suivi s’il ne sert pas, car de plus en plus d’attaquants y cherchent des failles.
Le schéma ci-dessous résume ces trois questions.
Share this infographic: Copy the code below to embed it on your site.
<a href="https://cyberial.fr/nouvelle-faille-php-session-prestashop/"><img src="https://cyberial.fr/wp-content/uploads/arbre-faille-php-23-octobre.png.webp" alt="Arbre de décision : votre boutique PrestaShop est-elle concernée par la faille PHP CVE-2026-115560 ?" /></a><p>Infographic by <a href="https://cyberial.fr">cyberial.fr</a></p>Si votre parcours s’arrête sur « Je ne sais pas », il reste à regarder la configuration du serveur et le code des modules ; nous pouvons le faire pour vous.
Votre boutique PrestaShop est-elle concernée ?
PrestaShop utilise bien des sessions PHP. Depuis la 1.7.0, le contrôleur des pages de la boutique en ouvre une pour afficher un message après une redirection. Le gestionnaire de fichiers de l’éditeur du back-office le fait aussi, dès la 1.6.
Aucun de ces appels ne touche au format des sessions. Nous avons cherché serialize_handler dans le code source de PrestaShop 1.6.1.24, 1.7.8.11, 8.2.8 et 9.1.5, hors bibliothèques tierces du dossier vendor, sans une seule occurrence. Dans ces versions 1.7, 8 et 9, le back-office Symfony laisse lui aussi PHP utiliser le format choisi par le serveur. Le cœur ne remplit donc pas la deuxième condition.
Le doute porte sur ce qui a été ajouté autour :
- les modules tiers, en particulier les plus anciens et ceux développés sur mesure ;
- les fichiers du dossier
override/et les scripts posés à la racine, comme un export ou un connecteur.
Aucune liste publique ne recense les modules qui changent ce format : nous ne pouvons pas affirmer qu’aucun ne le fait. Un prestataire peut chercher ce mot dans modules/, override/ et la racine ; s’il ne trouve rien, rien ne laisse penser que votre code change ce format.
Le réglage à demander à votre hébergeur
Le réglage session.upload_progress.enabled, qui active le suivi d’avancement des envois, passe de 1 à 0.
Aucun module PrestaShop ne peut le faire à votre place : PHP n’accepte ce réglage que dans la configuration du serveur ou du dossier, et un ini_set() reste sans effet. L’avis de sécurité publié par PHP le 21 octobre recommande php.ini ou le pool PHP-FPM, puis le redémarrage de chaque processus PHP. Les lignes à poser, puis le contrôle :
; dans php.ini session.upload_progress.enabled = 0 ; ou dans le pool PHP-FPM php_admin_value[session.upload_progress.enabled] = 0 # contrôle php -i | grep -E 'upload_progress.enabled|serialize_handler'
En cas d’écart avec la ligne de commande, phpinfo() côté site fait foi. Les envois de fichiers continuent ; seule la barre de progression native disparaît.
Sur un mutualisé, ces fichiers vous échappent. Écrivez à votre hébergeur : « Suite à l’avis PHP du 23 octobre, pouvez-vous passer session.upload_progress.enabled à 0, redémarrer PHP et me donner la valeur de session.serialize_handler ? »
Si vous l’avez déjà coupé le 21 octobre, gardez-le : PHP n’exige rien de plus pour cet avis. Et laissez-le coupé après les prochains correctifs si vous ne vous servez pas de ce suivi : c’est le conseil de PHP dans son avis du 21 octobre sur la CVE-2026-109619. Avec notre hébergement PrestaShop, en option de la maintenance, la configuration de PHP est gérée par nos soins.
Si votre hébergeur ne vous répond pas, nous vérifions les deux avis, du 21 et du 23 octobre : version de PHP et correctif installé, état du suivi des envois, modules qui changent le format des sessions. Dès 150 € HT, prix fixe validé avant toute intervention ; ces 150 € sont déduits si vous passez ensuite à la maintenance. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h, ou au 09 72 03 59 17.
La vraie priorité reste le correctif du 21 octobre
Le réglage du 23 octobre ne remplace pas la mise à jour de PHP : contre PHP2Shell, couper le suivi des envois ferme une voie d’attaque, pas les autres. Des exploits sont publics, a signalé Rapid7 le 22 octobre ; chacun exige une combinaison précise de système, de version de PHP et de serveur web. Rapid7 n’a pas observé d’exploitation réelle, mais plusieurs tentatives ont été signalées.
Les versions à atteindre sont 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Pour PHP 7.4, 8.0 et 8.1, le dépôt deb.sury.org, très répandu sur les serveurs Debian et Ubuntu, publie depuis le 21 octobre des paquets corrigés : 7.4.33-31, 8.0.30-25 et 8.1.34-9. La marche à suivre est détaillée dans notre article sur PHP2Shell, et les versions de PHP acceptées par PrestaShop ont leur propre page.
Il faudra encore mettre PHP à jour quand sortira le correctif de la CVE-2026-115560. Suivre ces avis et appliquer ces mises à jour après test fait partie de notre maintenance PrestaShop, à 69 € HT/mois, sans engagement.
Questions fréquentes
Faut-il mettre à jour PHP à cause de la CVE-2026-115560 ?
Pas encore pour elle : aucune version ne la corrige au 23 octobre. En attendant, coupez session.upload_progress.enabled côté serveur. Les versions du 21 octobre, elles, sont à installer dès maintenant contre PHP2Shell.
Quand le correctif de la nouvelle faille PHP du 23 octobre sera-t-il disponible ?
PHP n’a donné aucune date ; il parle de la prochaine version corrective normale. D’ici là, gardez le réglage à 0, puis mettez PHP à jour dès sa sortie, ou confiez-nous cette veille. Ensuite, ne remettez pas le suivi des envois en marche : PHP conseille de le laisser coupé si vous n’en avez pas besoin.
Couper le suivi des envois empêche-t-il l’envoi des images produits ?
Non. Les envois de fichiers, images produits ou imports, continuent. Seule la barre de progression native de PHP disparaît, et le cœur de PrestaShop ne l’utilise pas.
Sur un hébergement mutualisé, que faire ?
Demandez à votre hébergeur de passer session.upload_progress.enabled à 0 et de redémarrer PHP. Si votre offre a un sélecteur de réglages PHP, faites-lui confirmer que la valeur s’applique bien au site.
Faire vérifier votre boutique
Donnez-nous votre version de PrestaShop et votre hébergeur : nous regardons ce que la nouvelle faille PHP change. Dépannage PrestaShop dès 150 € HT, prix fixe validé avant. Réponse en moins d’une heure, 7j/7, de 8 h à 22 h, ou au 09 72 03 59 17.
