CVSS 9.2, deux fois, et la première chose que la moitié d'entre nous a tapée le 21 octobre, c'est php -v. Je l'ai fait aussi, dans un terminal, sur une machine dont j'étais à peu près sûr qu'elle comptait, et j'ai obtenu un numéro rassurant qui ne m'apprenait presque rien. Cette commande renvoie la version du binaire CLI présent dans le PATH de ton shell. Elle ne dit rien du pool FPM derrière nginx, ni de l'image de conteneur que quelqu'un a construite il y a trois semaines, ni du worker de file d'attente que Supervisor a lancé un mardi d'août et qu'il maintient en vie depuis.

Passer à la version corrigée, c'est la partie bon marché de la semaine. La partie coûteuse, c'est que la plupart des équipes avec qui je parle sont incapables de sortir, de mémoire ou depuis un fichier dans un dépôt, la liste complète des processus PHP qui répondent au trafic réseau pour leur compte. Sans cette liste, le patch reste un vœu pieux. Tu as mis à jour les machines dont tu te souvenais, et l'attaquant s'occupe de celles que tu as oubliées.

Les faits, rapidement, parce qu'ils expliquent pourquoi cette fois, ça se passe sous ton framework. CVE-2026-109618 se loge dans la façon dont le moteur gère les requêtes qui crèvent leur plafond mémoire, et CVE-2026-109619 est un use-after-free qu'une erreur fatale peut préparer pour ce qui s'exécute ensuite. Ce sont deux bugs du runtime : ton middleware Laravel et tes classes FormRequest soigneusement écrites ne sont tout simplement pas dans la bonne pièce. L'équipe PHP précise en plus qu'il n'existe aucun contournement complet, donc pas de directive ini à basculer en attendant une fenêtre de maintenance. Les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35, et c'est tout le menu.

Ce qui m'inquiète le plus, c'est la durée de vie des processus. Un gestionnaire de paquets peut terminer sa mise à jour proprement pendant que l'ancien moteur continue de tourner en mémoire, parce que personne n'a demandé au master FPM de recharger. php artisan queue:work sous Supervisor, Horizon, les workers Octane : tout ça est conçu pour tenir des semaines, et c'est une qualité jusqu'au moment où le code qu'ils ont chargé est justement celui dont tu dois te débarrasser. Nos amis de Go ont au moins un avantage dont ils peuvent se vanter : quand ils redéploient un binaire statique, ce qui tourne, c'est ce qu'ils ont compilé. Nous, on a apt qui annonce un succès à 14:02 et un worker en vie depuis 41 jours qui sert encore l'ancien runtime à 14:03.

L'objection la plus solide que j'ai entendue cette semaine est légitime. La plupart d'entre nous s'appuient sur une distribution, une plateforme managée ou un outil de provisioning justement pour que personne dans l'équipe n'ait à surveiller les runtimes, et ces fournisseurs ont publié des paquets corrigés rapidement. Mieux encore, les distributions rétroportent souvent les correctifs de sécurité dans un numéro de version plus ancien, si bien qu'une machine Debian ou Ubuntu peut être protégée alors que php -v affiche quelque chose qui a l'air périmé. D'accord, mais ça marche dans les deux sens. Si la chaîne de version peut te tromper dans le sens rassurant, elle peut aussi te tromper dans le sens dangereux, et la seule vérification qui tranche, c'est celle faite depuis l'intérieur du processus qui sert les requêtes, après son redémarrage.

Donc ce que je construirais vraiment cette semaine, c'est petit et ennuyeux. Donne à chaque appli un endpoint de santé accessible uniquement en interne, qui renvoie PHP_VERSION et l'heure de démarrage du processus depuis FPM, pas depuis un shell, et fais en sorte que ta supervision signale tout ce qui est antérieur au correctif. Configure ta CI pour qu'elle refuse les images de base en dessous de la version corrigée de ta branche. Tiens un seul fichier par équipe qui liste chaque hôte, chaque image et chaque worker qui fait tourner PHP, et traite-le comme du code. Il sera rentabilisé deux fois avant le Nouvel An : PHP 8.2 arrive en fin de vie le 31 décembre 2026, et ce même fichier te dira dès le premier jour qui doit encore migrer.

Rien de tout ça ne remplace la recherche de traces suspectes. Six jours se sont écoulés depuis la publication, les failles sont exploitables sans authentification, et une mise à jour propre ne prouve rien sur ce qui s'est passé avant. Parcours les logs FPM à la recherche de pics de crashs, vérifie qu'il n'y a pas de fichiers ou de comptes admin que tu n'as pas créés, et fais tourner tes identifiants si quoi que ce soit te paraît louche. C'est de l'hygiène d'incident ordinaire, et ça devient beaucoup plus simple quand tu sais déjà quelles machines regarder.

Voici ce que j'aimerais vraiment lire de ta part sous cet article : là, tout de suite, sans ouvrir de terminal, saurais-tu dire quelle version de PHP a servi la dernière requête de ton appli en production, et comment tu le prouverais ? Tu vérifies depuis l'intérieur de la requête, ou tu fais confiance au pipeline pour avoir fait ce qu'il annonçait ? Et si tu fais tourner des workers longue durée, est-ce que tu les redémarres à chaque patch du runtime, ou seulement quand quelqu'un y pense ?