Nouvelle alerte PHP : une faille dans la gestion des sessions peut-elle menacer votre site WordPress ?

Le 23 octobre 2026, l’équipe de sécurité PHP a publié un nouvel avertissement concernant un risque potentiel d’exécution de code à distance lié au suivi des téléversements dans les sessions PHP. Identifié sous la référence CVE-2026-115560, ce problème peut concerner certaines applications utilisant une combinaison particulière de paramètres de configuration.

Cette annonce intervient seulement deux jours après la publication des correctifs destinés aux vulnérabilités critiques CVE-2026-109618 et CVE-2026-109619.

Si ces premières failles nécessitaient une intervention urgente, la nouvelle alerte présente un contexte différent.

L’équipe PHP précise que l’exploitation de CVE-2026-115560 nécessite une configuration inhabituelle, ce qui rend ce scénario peu probable dans la majorité des applications.

Toutefois, elle recommande une mesure préventive pour les environnements susceptibles d’être concernés.

Les sites WordPress, WooCommerce et les applications PHP personnalisées doivent-ils s’inquiéter ? Comment vérifier leur configuration et quelles précautions prendre ?

Voici les éléments essentiels pour comprendre cette nouvelle alerte de sécurité.

1. CVE-2026-115560 : que révèle la nouvelle alerte PHP ?

Le 23 octobre 2026, l’équipe officielle PHP a publié un avis intitulé Informational advisory: Session upload progress.

Cette communication concerne une fonctionnalité native de PHP permettant de suivre l’avancement des téléversements de fichiers à travers les sessions.

Dans certaines conditions, le fonctionnement combiné de cette fonctionnalité et du mécanisme de sérialisation des sessions peut ouvrir la voie à une exécution de code à distance.

Une exécution de code à distance, ou Remote Code Execution (RCE), peut permettre à un attaquant d’exécuter des instructions sur un serveur.

Les conséquences potentielles dépendent des permissions du processus compromis et de la configuration de l’infrastructure.

Elles peuvent notamment inclure l’accès à des fichiers, la modification de données ou la compromission de l’application.

Une vulnérabilité aux conditions d’exploitation particulières

Contrairement à ce que pourrait laisser penser l’annonce d’une nouvelle CVE, tous les serveurs PHP ne présentent pas automatiquement un risque d’exploitation.

L’équipe PHP indique que plusieurs conditions doivent être réunies simultanément.

L’application doit notamment utiliser un gestionnaire particulier de sérialisation des sessions, puis en changer dynamiquement avant leur initialisation.

Le mécanisme de suivi de progression des téléversements doit également être activé.

Cette combinaison étant peu fréquente, PHP prévoit de traiter le problème dans son cycle habituel de publication des correctifs.

Il s’agit donc d’un risque de sécurité réel, mais dont l’exposition dépend fortement de la configuration et du comportement de l’application.

Source : PHP.net, avis de sécurité du 23 octobre 2026.

2. Quel est le lien avec les failles PHP découvertes le 21 octobre ?

Le 21 octobre 2026, l’équipe PHP avait déjà annoncé deux vulnérabilités critiques :

• CVE-2026-109618 : une vulnérabilité liée à la gestion de la mémoire en situation d’épuisement des ressources.
• CVE-2026-109619 : une vulnérabilité liée à la persistance d’un état interne après libération de la mémoire correspondante.

Ces deux problèmes pouvaient permettre, dans certaines conditions, une exécution de code à distance sans authentification.

Pour les corriger, PHP avait publié quatre versions de sécurité :

Ces mises à jour restent essentielles pour protéger les installations contre les deux vulnérabilités initiales.

Pourquoi une nouvelle alerte après ces correctifs ?

L’avis du 23 octobre attire l’attention sur un scénario supplémentaire lié aux sessions et au suivi des téléversements.

Ce scénario était déjà évoqué parmi les mesures d’atténuation de CVE-2026-109619.

L’équipe PHP précise que la désactivation de session.upload_progress.enabled permet de bloquer ce vecteur d’exploitation particulier.

Une nouvelle référence, CVE-2026-115560, lui a été attribuée.

Il ne faut donc pas considérer cette alerte comme une remise en cause générale des correctifs publiés le 21 octobre.

Ces derniers restent nécessaires et corrigent les deux vulnérabilités critiques initialement identifiées.

La nouvelle communication concerne un scénario spécifique qui doit faire l’objet d’un correctif supplémentaire.

Pour comprendre les deux premières vulnérabilités, consultez notre analyse des failles critiques PHP d’octobre 2026.

3. Comment fonctionne le suivi des téléversements dans les sessions PHP ?

PHP dispose d’une fonctionnalité permettant de suivre la progression de certains transferts de fichiers.

Elle est contrôlée par le paramètre suivant :

session.upload_progress.enabled = 1

Lorsque cette fonctionnalité est activée, PHP peut enregistrer dans la session des informations relatives à un téléversement en cours.

Ces informations peuvent notamment comprendre :

• La taille totale du fichier.
• La quantité de données déjà transférées.
• L’état du téléversement.
• Le nom du fichier.
• Des informations de progression.

Une application peut ensuite consulter ces données pour afficher une barre de progression.

Exemple d’utilisation

Imaginons une application permettant de transmettre des fichiers volumineux.

Un utilisateur sélectionne un document et démarre son téléversement.

Pendant le transfert, l’application affiche une barre de progression indiquant le pourcentage de données envoyées.

PHP peut contribuer à ce fonctionnement en enregistrant les informations de progression dans la session utilisateur.

Cette fonctionnalité est distincte du mécanisme classique de téléversement des fichiers.

Désactiver le suivi des téléversements ne signifie donc pas désactiver la possibilité d’envoyer des fichiers vers le serveur.

Cela peut néanmoins affecter les applications utilisant spécifiquement le mécanisme de progression fourni par les sessions PHP.

4. Pourquoi la sérialisation des sessions est-elle importante ?

Pour comprendre CVE-2026-115560, il faut également connaître le rôle de la sérialisation des sessions.

Une session PHP permet de conserver certaines informations entre plusieurs requêtes HTTP.

Ces données peuvent être utilisées pour mémoriser un état applicatif, des préférences ou des informations liées à un utilisateur.

PHP doit convertir ces informations dans un format permettant leur stockage et leur récupération.

Cette opération est appelée sérialisation.

Les différents gestionnaires de sérialisation

PHP propose plusieurs formats pour représenter les données de session.

Parmi eux :

php

Le format historique de sérialisation des sessions PHP.

php_binary

Un autre format utilisant une représentation spécifique des noms de variables et de leurs valeurs.

php_serialize

Un format reposant sur le mécanisme général de sérialisation PHP.

Le choix du gestionnaire peut être défini dans la configuration du serveur.

Par exemple :

session.serialize_handler = php_serialize

Une application peut également modifier certains paramètres à l’exécution.

C’est précisément cette possibilité qui intervient dans le scénario décrit par l’équipe PHP.

5. Quelles configurations sont réellement concernées par CVE-2026-115560 ?

Selon l’avis officiel du 23 octobre 2026, le problème nécessite la réunion de plusieurs conditions.

Première condition : un gestionnaire de sérialisation particulier

L’application doit initialement utiliser l’un des deux gestionnaires suivants :

session.serialize_handler = php_binary

ou :

session.serialize_handler = php_serialize

Ces paramètres peuvent être définis dans la configuration PHP.

Deuxième condition : un changement dynamique du gestionnaire

L’application doit ensuite modifier son gestionnaire de sérialisation pour utiliser le format php.

Ce changement doit être effectué pendant l’exécution de l’application avec la fonction ini_set().

Il doit également intervenir avant l’appel à session_start().

Troisième condition : le suivi des téléversements doit être actif

Enfin, le mécanisme suivant doit être activé :

session.upload_progress.enabled = 1

C’est la combinaison de ces comportements qui constitue le scénario particulier décrit par PHP.

Pourquoi cette combinaison est-elle inhabituelle ?

La majorité des applications ne modifient pas dynamiquement leur gestionnaire de sérialisation des sessions.

Lorsqu’un format est défini dans la configuration PHP, il est généralement conservé pendant toute l’exécution de l’application.

L’équipe PHP précise d’ailleurs que les applications ne changeant jamais leur gestionnaire de sérialisation à l’exécution peuvent conserver le suivi des téléversements activé au regard de ce scénario particulier.

La présence de session.upload_progress.enabled = On ne suffit donc pas à conclure qu’un serveur est vulnérable à CVE-2026-115560.

Il faut également vérifier le fonctionnement réel de l’application.

6. WordPress et WooCommerce sont-ils concernés ?

WordPress utilise PHP et peut donc être affecté par les vulnérabilités de ce langage.

Cependant, il faut distinguer une vulnérabilité présente dans le moteur PHP de son exploitabilité dans une installation WordPress donnée.

WordPress utilise-t-il ce mécanisme de progression ?

WordPress propose nativement des fonctionnalités de téléversement, notamment dans sa médiathèque.

WooCommerce et certaines extensions permettent également aux utilisateurs d’envoyer des fichiers.

Toutefois, le fait qu’une application permette de téléverser des fichiers ne signifie pas qu’elle utilise le mécanisme session.upload_progress de PHP.

Il ne faut donc pas établir de lien automatique entre la présence d’un formulaire de téléversement et cette vulnérabilité.

Le rôle des extensions et des développements personnalisés

Certaines applications PHP peuvent mettre en place leur propre gestion des sessions.

Cela peut notamment concerner :

• Des extensions WordPress particulières.
• Des développements métier personnalisés.
• Des systèmes d’authentification spécifiques.
• Des intégrations avec des applications externes.
• Des bibliothèques PHP utilisant des sessions natives.

Dans ces environnements, un audit du comportement des sessions peut être pertinent.

Il convient notamment de rechercher les éventuelles modifications dynamiques du paramètre session.serialize_handler.

Peut-on considérer un WordPress standard comme vulnérable ?

Non, pas uniquement sur la base de cette annonce.

À ce stade, l’avis officiel PHP décrit une combinaison particulière de paramètres et de code applicatif.

Il ne démontre pas que toutes les installations WordPress ou WooCommerce présentent cette combinaison.

Une vérification de la configuration et des développements utilisés reste nécessaire pour évaluer l’exposition réelle.

7. Comment vérifier la configuration PHP de son site ?

Avant toute modification, il est recommandé d’identifier les paramètres actuellement utilisés par le serveur.

Deux directives sont particulièrement importantes.

Vérifier session.upload_progress.enabled

Ce paramètre indique si le suivi des téléversements est activé.

Les valeurs possibles sont notamment :

session.upload_progress.enabled = On

ou :

session.upload_progress.enabled = Off

Lorsque la valeur est désactivée, le vecteur particulier décrit dans l’avis du 23 octobre n’est plus disponible.

Si elle est activée, il faut poursuivre les vérifications.

Vérifier session.serialize_handler

Ce paramètre permet de connaître le gestionnaire de sérialisation configuré.

Par exemple :

session.serialize_handler = php

Il peut également utiliser php_binary ou php_serialize.

Cependant, cette valeur ne permet pas à elle seule de déterminer si une application change de gestionnaire pendant son exécution.

Pour cela, il faut également examiner le code PHP concerné.

Où consulter ces paramètres ?

Selon l’environnement, plusieurs méthodes sont possibles :

• Consulter la configuration PHP de l’hébergement.
• Utiliser les outils d’administration du serveur.
• Examiner les paramètres des pools PHP-FPM.
• Effectuer un contrôle technique depuis un environnement d’administration sécurisé.

Sur un VPS, les administrateurs peuvent également examiner les fichiers de configuration PHP et ceux des services PHP-FPM.

Il faut vérifier la configuration réellement utilisée par le site web, car elle peut être différente de celle de PHP en ligne de commande.

8. Comment protéger son serveur contre CVE-2026-115560 ?

L’équipe PHP recommande une mesure préventive simple.

Elle consiste à désactiver temporairement le suivi de progression des téléversements.

Dans la configuration PHP :

session.upload_progress.enabled = 0

Cette directive empêche PHP d’utiliser le mécanisme concerné par le scénario d’exploitation.

Où appliquer cette modification ?

La méthode dépend de l’infrastructure.

Sur un VPS utilisant PHP-FPM, le paramètre peut être défini dans la configuration PHP ou dans celle du pool concerné.

Sur un hébergement mutualisé, son contrôle dépend des fonctionnalités proposées par le fournisseur.

L’objectif est que le paramètre soit appliqué suffisamment tôt, avant le traitement des requêtes HTTP.

Il ne faut pas se contenter de modifier sa valeur au milieu de l’exécution de WordPress.

En particulier, une modification effectuée avec ini_set() dans le code applicatif ne constitue pas la mesure d’atténuation recommandée pour ce mécanisme.

Faut-il redémarrer PHP-FPM ?

Après une modification de la configuration serveur, le service PHP concerné doit être rechargé ou redémarré selon les recommandations de l’environnement.

Cette opération permet de garantir que les nouveaux paramètres sont pris en compte par les processus PHP.

Quels effets secondaires faut-il anticiper ?

La désactivation du suivi de progression n’empêche normalement pas les téléversements classiques.

Cependant, certaines applications peuvent utiliser cette fonctionnalité pour suivre les transferts en cours.

Il faut donc vérifier les éventuelles dépendances avant de modifier la configuration d’un environnement de production.

Sur un hébergement administré, il est préférable de demander confirmation à l’hébergeur avant toute intervention sur les paramètres globaux de PHP.

9. Les versions PHP corrigées le 21 octobre sont-elles suffisantes ?

Cette question est particulièrement importante.

Les versions PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 ont été publiées pour corriger CVE-2026-109618 et CVE-2026-109619.

Elles restent les versions correctives officielles pour ces deux vulnérabilités.

Cependant, le bulletin du 23 octobre présente un scénario supplémentaire faisant l’objet d’une référence spécifique.

L’équipe PHP prévoit de publier un avis complet pour CVE-2026-115560 avec une prochaine version corrective.

Il faut donc distinguer :

Cela ne signifie pas que les mises à jour précédentes sont inefficaces.

Elles corrigent les vulnérabilités pour lesquelles elles ont été publiées.

En revanche, les administrateurs doivent rester attentifs aux nouvelles communications de sécurité.

Une version PHP corrigée contre une vulnérabilité connue ne garantit pas qu’aucun autre problème de sécurité ne sera découvert ultérieurement.

10. Faut-il désactiver session.upload_progress sur tous les serveurs ?

Pas nécessairement.

L’équipe PHP précise que les applications ne changeant jamais leur gestionnaire de sérialisation des sessions pendant l’exécution ne sont pas concernées par le scénario spécifique décrit le 23 octobre.

Cependant, elle recommande également la désactivation préventive de la fonctionnalité jusqu’à la publication du correctif.

Deux approches sont donc possibles.

Désactivation préventive

Lorsque l’application ne dépend pas du suivi de progression des téléversements, désactiver cette fonctionnalité permet de supprimer le vecteur concerné.

Cette approche est particulièrement intéressante sur les infrastructures où la fonctionnalité n’est pas utilisée.

Vérification ciblée

Lorsque le mécanisme est nécessaire au fonctionnement de l’application, une analyse de la configuration et du code peut permettre de déterminer si les conditions particulières sont réunies.

Cette vérification doit notamment porter sur les modifications dynamiques du gestionnaire de sérialisation.

Dans tous les cas, les autres mises à jour de sécurité PHP doivent continuer à être appliquées.

11. Pourquoi cette nouvelle alerte rappelle l’importance de la sécurité serveur

CVE-2026-115560 illustre un aspect souvent méconnu de la cybersécurité web.

Les vulnérabilités ne concernent pas uniquement les fonctionnalités visibles d’une application.

Elles peuvent également provenir des interactions entre différents composants internes du langage.

Une configuration qui semble anodine peut devenir problématique lorsqu’elle est associée à un comportement applicatif particulier.

C’est pourquoi la sécurité d’un site web doit être abordée à plusieurs niveaux.

Le code applicatif

Il faut contrôler les permissions, les traitements des données et les dépendances utilisées.

La configuration PHP

Les fonctionnalités inutilisées doivent être identifiées et, lorsque cela est pertinent, désactivées.

L’infrastructure

Les accès réseau, les services exposés et les permissions système doivent être maîtrisés.

La maintenance

Les mises à jour de sécurité doivent être surveillées et appliquées rapidement.

Cette approche permet de réduire les risques sans attendre qu’une vulnérabilité soit activement exploitée.

Elle s’inscrit dans une stratégie de défense en profondeur.

12. Quel intérêt pour les architectures WordPress Headless ?

Les récentes vulnérabilités PHP rappellent également l’intérêt de limiter les interactions publiques avec les composants sensibles d’une application.

Dans une architecture WordPress Headless, il est possible de séparer le serveur WordPress du frontend visible par les visiteurs.

Par exemple, une application Astro peut générer des pages HTML statiques à partir des contenus WordPress.

Le site public ne nécessite alors aucune exécution PHP pour afficher ces pages.

Le backend WordPress peut être placé derrière un accès réseau privé, tandis que le frontend est hébergé séparément.

Cette organisation permet de réduire l’exposition directe du serveur PHP.

Cependant, elle ne dispense pas d’appliquer les correctifs ou de sécuriser la configuration des sessions.

Le Headless peut réduire la surface d’attaque, mais il ne corrige pas les vulnérabilités du langage PHP.

Pour approfondir ce sujet, découvrez notre article consacré à la sécurité de WordPress Headless et à l’isolation du backend.

Conclusion : surveiller PHP au-delà des mises à jour critiques

L’alerte CVE-2026-115560 publiée le 23 octobre 2026 montre que la sécurisation d’un environnement PHP ne se limite pas à l’installation des dernières versions.

La configuration du moteur PHP et son interaction avec le code applicatif jouent également un rôle essentiel.

Dans le cas présent, l’exploitation nécessite une combinaison inhabituelle de paramètres de session et de comportements applicatifs.

La situation ne justifie donc pas de considérer tous les sites WordPress comme vulnérables.

En revanche, elle rappelle l’importance de vérifier régulièrement la configuration des serveurs et de suivre les recommandations officielles.

En attendant la publication du correctif complémentaire, la désactivation préventive de session.upload_progress.enabled constitue la mesure recommandée par PHP pour les environnements concernés.

La sécurité d’une application web repose autant sur sa configuration que sur les mises à jour de ses composants.

Chez Naxialis, nous accompagnons les entreprises dans la sécurisation et la maintenance de leurs environnements WordPress et PHP.

L’analyse des configurations, la réduction de la surface d’attaque et la surveillance des vulnérabilités permettent d’anticiper les risques et de renforcer la sécurité des infrastructures web.

Vous souhaitez vérifier la configuration PHP de votre site ou renforcer la sécurité de votre hébergement ? Contactez Naxialis pour étudier votre environnement technique.