Dans cet article
Si vous avez mis à jour le site de votre entreprise vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 après la faille PHP2Shell, vous avez bien fait, mais cela ne couvre pas tout. Le 23 octobre 2026, le projet PHP a publié une nouvelle alerte sur une troisième faille, CVE-2026-115560, que la mise à jour du 21 octobre ne corrige pas. Elle exige une configuration inhabituelle et PHP la juge peu probable, mais la parade temporaire est simple : demandez aujourd'hui à votre équipe ou à votre hébergeur de régler session.upload_progress.enabled sur 0 et de redémarrer PHP, puis de confirmer par écrit que la mise à jour du 21 octobre est bien appliquée.
Qu'a annoncé PHP le 23 octobre ?
Deux jours après la version d'urgence, le projet a publié une courte alerte informative sur le suivi de « progression de l'envoi » dans les sessions, la fonction qui montre à l'utilisateur où en est l'envoi d'un gros fichier. L'alerte indique que cette fonction peut ouvrir une voie d'exécution de code à distance dans un cas précis, et que le correctif arrivera avec la prochaine version régulière plutôt qu'en urgence, accompagné alors d'un avis complet sur la faille.
Deux points comptent pour un dirigeant. D'abord, il s'agit d'une faille distincte : tourner sur l'une des quatre versions ci-dessus ne suffit pas à lui seul. Ensuite, la même mesure temporaire figurait déjà dans l'avis sur CVE-2026-109619 du 21 octobre. Si votre équipe l'a appliquée à ce moment-là, rien de nouveau à faire : gardez-la en place.
Votre site est-il exposé ?
Selon l'alerte de PHP, le problème n'apparaît que si trois conditions sont réunies :
- La configuration de PHP règle session.serialize_handler sur php_binary ou php_serialize.
- Le code de l'application le bascule sur php à l'exécution avec ini_set() avant le démarrage de la session.
- Le suivi de progression de l'envoi est toujours actif, ce qui est le cas par défaut.
La plupart des sites ne font pas cela. Le problème, c'est qu'un dirigeant sait rarement ce que fait chaque ligne d'un système construit il y a des années ou d'une vieille extension. Le choix le plus sûr : si votre site n'affiche pas de barre de progression pour l'envoi de fichiers, désactiver la fonction ne casse rien et ferme la porte. S'il en dépend, demandez à vos développeurs si le code modifie ce réglage à l'exécution.
Trois jours plus tard : vérifiez que la mise à jour du 21 octobre est bien en place
Les failles d'origine, CVE-2026-109618 et CVE-2026-109619, restent le risque principal. L'Autorité nationale saoudienne de cybersécurité (NCA) a publié l'alerte n° 2026-7949 à leur sujet, et l'agence américaine CISA recommande d'inventorier tous les systèmes PHP, de corriger en priorité ceux exposés à Internet et de mettre un système hors ligne s'il ne peut pas être corrigé tout de suite. La CISA indiquait n'avoir constaté aucune exploitation réussie au moment de la publication, ce qui ne veut pas dire que le temps joue pour vous.
Trois points que beaucoup oublient :
- Redémarrer, pas recharger. Le bulletin de Red Hat précise que les changements de configuration exigent de redémarrer les processus PHP, et qu'un simple rechargement ne suffit pas.
- Le numéro de version peut différer sur les serveurs Linux. L'annonce de PHP indique que les distributions Linux ont reçu les correctifs à l'avance : vous pouvez donc voir un autre numéro que 8.5.12, par exemple, alors que le correctif est appliqué. Demandez à votre hébergeur une confirmation écrite, pas seulement un numéro. Red Hat signale que RHEL 8, 9 et 10 sont tous concernés.
- Le mode d'exécution de PHP change le risque. Le projet PHP juge le risque le plus élevé avec mod_php sous Apache, tandis que Red Hat estime l'exploitation plus difficile en pratique avec PHP-FPM par défaut. Plus difficile ne veut pas dire impossible : la mise à jour reste nécessaire dans les deux cas.
5 questions à envoyer aujourd'hui à votre hébergeur ou à votre équipe
- Quelle version de PHP tourne sur chacun de nos sites et systèmes, et inclut-elle les correctifs du 21 octobre 2026 ?
- Les processus PHP ont-ils été redémarrés après la mise à jour, et pas seulement rechargés ?
- Avons-nous réglé session.upload_progress.enabled sur 0 ? Sinon, avons-nous vraiment besoin de cette fonction ?
- Le code de notre site modifie-t-il session.serialize_handler à l'exécution ?
- Avons-nous un site en 8.1 ou plus ancien ? Ces branches ne sont plus maintenues, et le tableau des versions supportées montre que le support de sécurité de 8.2 prend fin le 31 décembre 2026.
Le regard d'Origami
Trois alertes en trois jours, c'est normal après une faille majeure : quand les chercheurs creusent une partie du langage, ils trouvent ce qui se trouve à côté. Mais cela dit aussi quelque chose des entreprises. Celle qui a corrigé le 21 et refermé le dossier passera à côté de l'alerte du 23. Ici, la sécurité est un suivi continu, pas une tâche que l'on termine une fois pour toutes.
Ce que nous constatons dans les entreprises saoudiennes, c'est que la question difficile n'est pas « quelle est la faille ? » mais « qui, chez nous, lit une alerte PHP un vendredi matin et sait quel serveur est le nôtre ? ». Chez Origami, nous construisons des sites et des systèmes et nous surveillons leurs mises à jour dès le premier jour. Si vous voulez faire vérifier votre site, ou appliquer ces réglages sans interruption de service, contactez-nous.
En résumé
La mise à jour du 21 octobre est indispensable et reste la priorité ; la nouvelle alerte n'y change rien. Ajoutez aujourd'hui une étape peu coûteuse : désactivez le suivi de progression de l'envoi si vous n'en avez pas besoin, redémarrez PHP et obtenez une confirmation écrite de votre hébergeur. Surveillez ensuite la prochaine version régulière de PHP, qui apportera le correctif définitif de CVE-2026-115560.
Sources
- PHP : alerte informative sur la progression de l'envoi dans les sessions, 23 octobre 2026
- PHP : avis de sécurité d'urgence et versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35, 21 octobre 2026
- PHP sur GitHub : avis sur CVE-2026-109619
- Autorité nationale saoudienne de cybersécurité (NCA) : alerte PHP n° 2026-7949
- CISA : Critical Vulnerabilities in PHP Require Immediate Patching
- Red Hat : bulletin RHSB-2026-013 sur les trois failles PHP
- PHP : tableau des versions supportées
Questions fréquentes
Mettre PHP à jour en 8.5.12 ou 8.4.27 suffit-il à protéger mon site ?
Cela couvre les deux failles critiques PHP2Shell, mais pas la nouvelle faille CVE-2026-115560 annoncée le 23 octobre 2026. Pour celle-ci, PHP recommande de régler session.upload_progress.enabled sur 0 jusqu'à la prochaine version régulière.
Mon site va-t-il cesser de fonctionner si je désactive le suivi de progression de l'envoi ?
En général, non. Cette fonction affiche une barre de progression pendant l'envoi de fichiers, et la plupart des sites ne s'en servent pas. Si le vôtre affiche cette barre, consultez votre équipe avant de la désactiver, et redémarrez PHP après le changement dans tous les cas.
Mon hébergeur indique un numéro de version différent de ceux annoncés. Sommes-nous exposés ?
Pas forcément. Les distributions Linux ont reçu les correctifs à l'avance et peuvent afficher d'autres numéros. Demandez à votre hébergeur une confirmation écrite que les correctifs du 21 octobre 2026 sont appliqués et que les processus PHP ont été redémarrés.
Quand le correctif définitif de la nouvelle faille sera-t-il publié ?
PHP indique qu'il la corrigera dans la prochaine version régulière, avec un avis complet, et non par une mise à jour d'urgence, car la configuration nécessaire pour l'exploiter est rare. D'ici là, le réglage temporaire vous protège.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
