Commençons par les versions : 8.5.11, 8.4.26, 8.3.35, 8.2.34. Ce sont les releases qu'une alerte Medium largement partagée donnait comme porteuses du correctif pour CVE-2026-109618 et CVE-2026-109619, une faille de sécurité mémoire dans le code de suivi de progression des uploads de session, notée CVSS v4.0 9.2 et exploitable sans authentification avec la configuration par défaut. Le correctif était attendu le 2026-10-21 à 14:00 UTC, soit une semaine avant que j'écrive ces lignes. Avant toute chose, compare le changelog officiel de php.net et le suivi de sécurité de ta distribution avec ce qui tourne réellement chez toi : un billet de blog, c'est une alerte, la source de vérité reste l'avis de sécurité officiel.

session.upload_progress.enabled = Off

Si tu es sur l'une de ces versions, tant mieux. Tu as bouché ce trou-là. Ce qui me gêne, c'est l'étape que la plupart d'entre nous vont franchir ensuite : supprimer discrètement la ligne d'urgence du php.ini parce que le ticket d'incident est clos et que cette ligne ressemble à un échafaudage. Je pense exactement l'inverse. Ce palliatif est la modification la plus utile que tes serveurs aient reçue ce mois-ci, et la mise à jour l'a seulement rendu facultatif.

Demande-toi quand tu as livré pour la dernière fois une fonctionnalité qui reposait sur session.upload_progress. J'ai passé en revue les quatre bases de code sur lesquelles je travaille régulièrement, dont une appli Laravel née en 2016, et je n'ai trouvé aucune lecture de la clé de progression dans la session. Toutes nos barres de progression viennent du navigateur, où les événements d'upload de XHR ou de fetch indiquent les octets envoyés sans que le serveur ait à conserver le moindre état. Pendant ce temps, la fonctionnalité côté serveur était activée par défaut sur chaque pool FPM et analysait chaque requête multipart, au cas où quelqu'un en aurait besoin.

Voilà la vraie nature de cet incident. Du code que personne n'appelle s'exécute quand même si une option par défaut l'active, et du code qui s'exécute peut casser. Un bug de framework ou de CMS peut se corriger côté applicatif ; un bug du cœur comme celui-ci touche WordPress, Drupal, ton API maison et cet outil interne oublié de la même façon, et en attendant le correctif, ton seul levier, c'est la configuration. Les vieilles branches aggravent les choses : l'alerte précise que 8.0, 8.1 et tout ce qui relève de 7.x et 5.x ne reçoivent rien, donc sur ces machines, désactiver la fonctionnalité n'est pas un palliatif, c'est toute la défense.

Passons à l'objection légitime. Le suivi de progression existe pour une raison : il fonctionnait avant que les navigateurs exposent les événements d'upload de façon fiable, et certaines applis anciennes, surtout celles avec des interfaces d'admin rendues côté serveur et un endpoint de polling, en dépendent encore. Le couper globalement peut casser en silence une barre de progression dont un client a besoin, et personne ne veut d'un changement de sécurité qui se transforme en ticket de support à 23:40 un vendredi. On peut aussi raisonnablement soutenir que la vraie correction doit se faire dans le cœur, et que les équipes ops ne devraient pas avoir à remettre en question chaque option par défaut livrée par php-src.

Ces deux arguments sont vrais, et aucun ne change ma conclusion. Ici, la casse se détecte à peu de frais : un grep sur la clé de session de progression dans tes dépôts prend à peu près une minute, et les applis qui en ont besoin peuvent la réactiver dans la configuration de leur propre pool, avec un commentaire qui explique pourquoi. Ça inverse la charge de la preuve : c'est à la fonctionnalité de justifier qu'elle soit active, pas à toi de justifier que tu l'as coupée. Quant aux options par défaut du cœur, je serais ravi que php-src revoie celle-ci, mais modifier un comportement par défaut aussi ancien est un travail lent et prudent, pour de bonnes raisons, et tes serveurs n'ont pas besoin d'attendre la fin de ce débat.

Le même raisonnement vaut pour les autres mesures suggérées par l'alerte que tu as peut-être ajoutées dans la panique : un open_basedir par pool, une liste disable_functions, des alertes quand des workers FPM meurent avec le signal 11. Rien de tout ça n'arrête un attaquant déterminé, et l'article le dit lui-même. Mais un crash de worker qui apparaît dans tes logs en quelques minutes, c'est le genre d'alerte précoce qu'on a rarement, et un pool qui ne voit rien en dehors de son propre répertoire transforme une nuit catastrophique en nuit gérable. Garde ces défenses ennuyeuses une fois l'agitation retombée.

Alors voilà ce que j'aimerais vraiment savoir dans les commentaires : est-ce que quelqu'un fait encore tourner session.upload_progress côté serveur en production, volontairement, et qu'est-ce qu'il te faudrait pour déplacer cette barre de progression côté client ? Si on est assez nombreux à répondre, on aura peut-être les données pour aller proposer à php-src de changer cette option par défaut.