FROM php:8.1-apache. J'ai trouvé cette ligne deux fois la semaine dernière, dans deux dépôts que personne dans l'équipe actuelle n'avait touchés depuis 2023, et les deux images répondaient gaiement aux requêtes le 22 octobre, un jour après que le projet PHP a publié les correctifs de CVE-2026-109618 et CVE-2026-109619. Apache avec mod_php, en plus, précisément la configuration que l'équipe PHP désignait comme la plus exposée. Les propriétaires de ces dépôts ont eu une chance que je ne nous vois pas retrouver de sitôt. Le cœur ne s'est pas arrêté à 8.2.35, 8.3.36, 8.4.27 et 8.5.12. Il a aussi sorti des patchs source minimaux pour 7.4, 8.0 et 8.1, trois branches déjà sorties du cycle de support normal.

Ça mérite un vrai merci, et ça mérite aussi une lecture honnête. Quelqu'un sur php-src a passé des heures d'urgence dans du code auquel il avait officiellement dit adieu, pour que les équipes qui n'avaient jamais planifié de montée de version aient une porte de sortie. Si ton plan pour le prochain bug critique du moteur suppose en douce que le cœur refera la même chose, tu bâtis ton plan sur une faveur. Pour la plupart d'entre nous, la leçon de PHP2Shell se trouve dans le calendrier des mises à jour, des semaines avant qu'un canal d'incident ne s'ouvre.

Regarde ce qu'un patch source te donne réellement : un diff. Pour en faire quelque chose qui tourne en production, il te faut un build fonctionnel de PHP lui-même, toutes les extensions que tu compiles par-dessus, et quelqu'un qui se souvient encore des options de configure utilisées pour l'image d'origine. J'ai vu une équipe perdre un après-midi entier parce que pdo_pgsql refusait de se lier à leur 8.0 compilée à la main. Et les équipes qui entretiennent une chaîne de build PHP en bonne santé sont, presque par définition, rarement celles qui tournent encore en 8.1.

L'objection la plus solide mérite d'être entendue, et elle est bonne. Une vieille chaîne de version ne fait pas d'un serveur un serveur négligé. Les distributions et les éditeurs LTS rétroportent les correctifs de sécurité dans leurs paquets sans passer au numéro amont, et l'annonce de PHP elle-même renvoyait vers ces éditeurs. Une machine qui affiche un numéro d'apparence préhistorique peut être parfaitement couverte par son éditeur, et je ne dirais jamais à une boîte sous distribution entreprise supportée de paniquer devant la sortie de php -v.

Là où l'argument ne tient plus, c'est dans la différence entre un contrat et une habitude. Un rétroportage, c'est un éditeur identifié, un bulletin publié et une référence de paquet que tu peux coller dans un ticket. Une image de base épinglée en 2023 et jamais reconstruite n'a rien de tout ça. Elle a juste l'air stable parce que rien n'a encore cassé, exactement comme elle en avait l'air le 20 octobre.

Ce que l'image périmée te coûte vraiment, c'est de la vitesse. Cloudflare a signalé du trafic d'attaque, et même des attaquants qui retravaillaient leurs charges utiles pour passer sous ses règles, et a malgré tout dit à ses clients de patcher PHP plutôt que de compter sur le WAF. L'ENISA est allée plus loin : elle a suggéré de retirer du réseau les applications exposées publiquement si les correctifs ne pouvaient pas être appliqués, et a prévenu que PHP se cache dans des produits dont les utilisateurs ignorent totalement sa présence. L'isolement, c'est pour quand tu ne peux pas livrer. Sur une branche supportée avec des montées mineures régulières, toute cette histoire a été un mardi sans relief : passer de 8.3.35 à 8.3.36, laisser tourner la CI, déployer, aller déjeuner. Sur 8.1, c'était un chantier de build avec un compte à rebours.

Mon plaidoyer est donc volontairement ennuyeux. Laisse un bot ouvrir la PR de version corrective chaque fois que le cœur en tague une, et merge-la dans la semaine sauf si les tests protestent. Fixe par écrit le retard maximal que tu t'autorises par rapport à la plus ancienne branche supportée, et traite chaque dépassement comme un bug avec un responsable attitré. Fais les grosses migrations majeures pendant un sprint calme que tu as choisi, parce que l'alternative, c'est de les faire sous un numéro de CVE, avec les clients qui regardent. Rien de tout ça n'est malin. Ça transforme simplement le prochain PHP2Shell d'urgence en ligne de changelog, et ça nous évite de griller la bonne volonté des gens qui maintiennent le runtime dont on dépend tous.

Voilà ce que j'aimerais vraiment lire de ta part dans les commentaires : de combien ta plus vieille charge de travail en production est-elle en retard sur la plus récente branche PHP supportée, et, honnêtement, combien de temps te faudrait-il pour qu'un build corrigé serve du trafic si le prochain bulletin tombait demain matin ?