CVE-2026-109618 et CVE-2026-109619 sont arrivées sur php.net le 21 octobre 2026. Les deux sont critiques, les deux se trouvent dans le runtime lui-même, et les deux permettent à un attaquant d'exécuter du code sur ton serveur sans même se connecter. Ma première pensée n'avait rien à voir avec la classe de bug. J'imaginais tous les fils Slack lancés à 9 h 14 ce matin-là par « petite question, on est sur quelle version de PHP en prod ? », restés sans réponse pendant que quelqu'un cherchait la bonne clé SSH.

Alors voilà ma position. S'il faut un humain, un terminal et une supposition pour savoir quelle version de PHP traite tes requêtes en production, tu as un problème d'inventaire, et le prochain bulletin sur le runtime te le fera découvrir, que tu sois prêt ou non. Chaque déploiement devrait enregistrer cette version comme un fait, juste à côté du hash de commit et du lock Composer. Ça ne devrait jamais relever du savoir tribal.

La part de supposition compte plus qu'on ne veut bien l'admettre. Sur une machine tout à fait ordinaire, j'ai déjà vu `php -v` afficher une version mineure pendant que le pool FPM derrière nginx en faisait tourner une autre sans broncher, parce qu'un paquet de la distrib, un PPA et une image Docker de base avaient chacun leur avis sur la question. La CLI, c'est ce qui se trouve en premier dans le PATH. Tes visiteurs, eux, tombent sur ce que vise la config du pool. Fais tourner une tâche cron, un worker de file d'attente et une requête web sur le même hôte, et ça peut faire trois interpréteurs différents, dont un seul a peut-être reçu le correctif.

Le correctif que j'aimerais voir dans chaque base de code est volontairement ennuyeux. Au build, écris `PHP_VERSION` et `PHP_SAPI` dans un petit artefact. À l'exécution, fais remonter les mêmes valeurs par chaque SAPI que tu utilises vers un health check interne, et déclenche une alerte dès que les deux divergent ou passent sous un plancher défini dans ta config. Avec ça, le jour du bulletin se résume à une requête sur un dashboard. Tu obtiens la liste des hôtes à traiter en quatre minutes environ, là où il te fallait avant tout un après-midi d'archéologie.

La meilleure objection mérite une réponse franche : publier ta version exacte du runtime, c'est offrir la reconnaissance à un attaquant sur un plateau. C'est précisément pour ça qu'`expose_php` existe, et pour ça que les gens raisonnables le désactivent. Je suis entièrement d'accord. Rien de ce que je décris ne doit apparaître dans un en-tête public ou sur une route non authentifiée. Les données partent vers ta stack de métriques ou vers un endpoint protégé par jeton que seul ton monitoring peut atteindre. De toute façon, un attaquant peut identifier ta stack avec ou sans ton aide. Celui qui n'y arrive pas, c'est toi, un mardi, avec une CVE ouverte dans un autre onglet.

Deuxième objection : sur les plateformes managées, le runtime n'est pas ton boulot. Soit, le patcher n'est peut-être pas ton boulot, mais le risque, lui, reste le tien, et c'est à toi de le connaître. Si ton fournisseur maintient vraiment PHP à jour, ton health check le confirmera, et ça ne te coûte rien. Sinon, tu l'apprends par ta propre télémétrie plutôt que par le rapport d'incident de quelqu'un d'autre. Honnêtement, c'est un des rares points où les gens de Go ont la vie un peu plus facile, puisque le runtime est intégré au binaire qu'ils livrent. Nous, on peut remplacer l'interpréteur sous du code qui tourne, ce qui est un vrai avantage, à condition de savoir quel interpréteur s'y trouve.

PHP a un rythme de versions et de correctifs de sécurité prévisible, et c'est l'une des forces discrètes de l'écosystème. Le maillon faible, c'est l'écart entre une archive corrigée sur php.net et le processus qui répond réellement sur le port 443. Alors raconte-moi comment tu combles cet écart. Est-ce que ton équipe suit déjà automatiquement la version de PHP servie sur chaque hôte, et si oui, où vit ce chiffre : dans ton journal de déploiement, dans ton APM, ou encore dans la tête de quelqu'un ?