14:00 UTC, le mercredi 21 octobre 2026. Cet horaire est resté plusieurs jours dans mon agenda avant que quoi que ce soit ne sorte, et c'est bien ce qu'il y a de plus étrange dans la façon dont PHP a géré CVE-2026-109618 et CVE-2026-109619 : on connaissait l'heure du correctif avant de savoir ce qui était cassé. Deux failles, chacune notée 9.2 en CVSS v4.0, un avis du CERT-EU numéroté 2026-018 évoquant une possible exécution de code à distance, et une annonce sur php.net qui disait, en gros, que les détails arriveraient avec la release. Certains y ont vu de l'opacité. Moi, j'y ai vu le projet offrir à chaque équipe un exercice d'évacuation gratuit, et je soupçonne que la plupart d'entre nous l'ont passé à rafraîchir la page d'annonce.

À mon sens, la vraie difficulté d'un correctif critique du runtime est mécanique, et elle se trouve dans ton pipeline. Comprendre le bug vient en second. Tu ne peux rien faire d'utile avec le texte de l'avis tant qu'il n'existe pas, mais tu peux découvrir un mardi tranquille si monter le niveau de patch de PHP en production prend dix minutes ou tourne au chantier d'archéologie de deux jours. Si changer de runtime implique d'ouvrir un ticket chez un hébergeur dont le support répond sous 48 heures, ta faille à 9.2 est devenue un problème d'agenda. Ton code, lui, n'avait rien à corriger.

La semaine dernière, j'ai discuté avec une freelance (elle m'a demandé de ne pas la nommer) qui maintient une trentaine de sites clients. Le 20 octobre, elle pouvait me citer de mémoire la version du framework de chacun d'eux. Elle était incapable de me dire sur lesquels elle avait seulement le droit de mettre PHP à jour. Onze tournaient sur de l'hébergement mutualisé, où la version de PHP est une liste déroulante que quelqu'un d'autre remplit. Quatre vivaient sur un VPS monté en 2021 par une ancienne agence, avec un build compilé à la main auquel personne n'osait toucher. Ce n'est pas de la négligence. Nos outils suivent composer.lock avec amour et traitent l'interpréteur en dessous comme la météo.

L'objection la plus sérieuse au modèle de pré-annonce mérite qu'on l'écoute vraiment. Annoncer une release critique sans détails, c'est sans doute prévenir les attaquants qu'un morceau de choix arrive, et c'est prévenir aussi les dirigeants, qui transfèrent ensuite un titre alarmant en demandant s'il faut fermer la boutique. Le texte du CERT-EU n'a pas aidé le camp des calmes : quand tu ne peux pas corriger rapidement, il suggère d'envisager de couper des réseaux publics les applications exposées sur Internet jusqu'à ce qu'un correctif soit en place. Lu en diagonale, ça sonne comme « débranchez tout », et j'ai vu au moins un canal Slack partir en vrille précisément sur cette lecture.

Je pense quand même que le jeu en vaut la chandelle. Les attaquants capables de faire un diff entre deux arbres de sources découvrent le bug dès que le patch arrive, annonce ou pas ; la notice change seulement le niveau de préparation des défenseurs à ce moment-là. Et si la formulation du CERT-EU est conditionnelle, ce n'est pas un hasard. L'isolement est la solution de repli pour une machine que tu ne peux pas patcher, ce qui revient à avouer que le vrai échec a eu lieu des mois plus tôt, quand personne n'était responsable de cette machine. La panique dans ce canal Slack venait d'une question ennuyeuse restée sans réponse : lesquels de nos serveurs peuvent recevoir un nouveau build de PHP aujourd'hui ?

Voici donc ce que je changerais, et c'est peu de chose. Traite le binaire PHP comme une dépendance avec un lockfile. Fige sa version dans ton image de base de conteneur ou dans ta config de provisioning, fais-le passer par le même circuit de pull requests que tout le reste, et laisse ta CI lancer la suite de tests contre la prochaine version de patch le jour même où elle sort. Si ta stack tourne sous Docker, c'est une ligne FROM à modifier et un pipeline au vert. Si c'est de l'hébergement mutualisé, c'est un engagement écrit sur la rapidité avec laquelle l'hébergeur livre les builds de sécurité, et cet engagement a sa place dans le contrat, à côté du chiffre de disponibilité. Rien de tout ça n'est glamour, et c'est justement l'idée : le 21 octobre, les équipes qui avaient tout ça ont déployé avant le déjeuner, puis sont retournées se disputer sur les conventions de nommage.

L'avis est public maintenant, alors va lire les versions concernées et corrigées sur php.net et chez ta distribution, et compare-les avec ce que tes serveurs web exécutent réellement. Je ne recopie volontairement aucun numéro de version ici, parce que le meilleur moyen d'en propager un faux, c'est une chronique écrite de mémoire. Ce qui m'intéresse, c'est la prochaine fois. Il y aura une autre release de sécurité datée, et l'équipe PHP aura très probablement la même courtoisie de nous prévenir à l'avance.

Alors, franchement : quand la prochaine release critique pré-annoncée tombera, combien d'heures te faudra-t-il pour installer un runtime PHP corrigé sur chaque hôte de production dont tu as la charge, et quelle est l'étape la plus lente de toute cette chaîne ?