PHP 7.4.33 (cli). Je parierais que c'est la bannière qui s'affiche encore cette semaine sur un nombre effrayant de serveurs de production. La 7.4.33 a été la toute dernière version de cette branche, et la ligne 7.4 ne reçoit plus de correctifs de sécurité depuis novembre 2022. Garde cette chaîne de version en tête pendant que les gros titres se disputent au sujet de l'intelligence artificielle, parce que c'est elle qui décide si CVE-2026-109618 et CVE-2026-109619 seront pour toi un mauvais mardi ou une notification de fuite de données.

Voici ce qui a été rapporté. Deux failles dans le moteur PHP, notées 9,2, permettent l'exécution de code à distance sans authentification. Les bugs auraient plus de dix ans, et le correctif aurait exigé une modification importante du moteur lui-même. Wiz les a trouvés avec GPT-5.6 Sol d'OpenAI, dans le cadre d'un programme baptisé Patch the Planet. Palo Alto Networks recense plus de 22,6 millions d'instances exposées. Nicholas Weaver a déclaré à Cybersecurity Dive que des exploitations avaient déjà été observées dans la nature. Des détails ont fuité sur les réseaux sociaux un mardi, si bien que la version d'urgence est sortie avec un jour d'avance. La Finlande a mis hors ligne ses services publics, l'agence nationale néerlandaise de cybersécurité a coupé son propre site, des sites de préfectures françaises sont restés inaccessibles un moment et Wikimedia a brièvement perdu certains systèmes. Je relaie tout ça tel que ça a été rapporté. Compare l'avis publié sur php.net avec ta propre stack avant de te fier à un résumé de seconde main, celui-ci compris.

Le chiffre auquel je reviens sans cesse, ce n'est pas 22,6 millions. Cisco estime qu'environ la moitié des instances exposées sur Internet tournent sur des versions de PHP tellement anciennes qu'elles ne reçoivent plus aucune mise à jour de sécurité. Pour ces serveurs, le correctif d'urgence n'existe pas. Aucune 7.2.35 ne viendra les sauver. La seule option, c'est un saut de version, et un saut de version sur une base de code que personne n'a touchée depuis 2019, c'est un projet, pas un patch.

L'argument le plus solide contre moi, c'est que l'angle IA est vraiment le sujet. Si un modèle peut dénicher en quelques mois une faille du moteur vieille de douze ans, alors trouver des bugs vient de devenir bon marché pour tout le monde, attaquants compris, et le délai entre la divulgation et l'exploitation va continuer de se réduire. Je suis d'accord. Je ne pense simplement pas que ça change la conclusion. Imagine que ce même bug ait été trouvé à l'ancienne, par un chercheur humain. Les serveurs coincés sur des branches non maintenues seraient exactement aussi exposés, parce que leur problème n'a jamais été que la faille passe inaperçue. Leur problème, c'est qu'aucun correctif ne peut les atteindre en moins d'une semaine. Une façon moins chère de trouver des bugs met davantage de pression sur cette faiblesse. Mais la faiblesse, ce n'est pas elle.

Je ne vais pas non plus prétendre que la migration est facile, j'en ai fait assez pour savoir où ça fait mal. Une appli legacy qui s'appuie sur each() ou create_function() casse net en PHP 8.0, puisque les deux ont été supprimées. La dépréciation des propriétés dynamiques en 8.2 remplit tes logs d'avertissements venus de code vendor que tu n'as pas écrit et que tu ne peux pas forker facilement. Et puis il y a l'extension compilée contre une ABI disparue depuis longtemps, que comprenait une seule personne, partie en 2021. Dire à une équipe qui a vécu tout ça de juste mettre à jour, c'est un conseil qui ne coûte rien. Mais un week-end de passes Rector et de fixtures cassées coûte quand même moins cher que de faire partie des sites que l'État a dû débrancher.

Honnêtement, c'est l'un des rares endroits où notre écosystème s'en sort bien, pour peu qu'on plisse les yeux. Le moteur a reçu un correctif profond et délicat, publié en avance malgré une fuite : c'est un projet qui fonctionne comme il le devrait. Là où tout se délite, c'est en aval, dans les images d'hébergement qui figent les versions mineures pour toujours et dans les contrats d'agence qui couvrent la construction d'un site mais jamais sa maintenance. Une amie qui écrit du Go aime me rappeler que son déploiement tient en un seul binaire. C'est vrai, et elle a quand même dû tout recompiler et redéployer ce qui était lié à une bibliothèque vulnérable la dernière fois que c'est arrivé. Tous les langages ont ce problème. Le nôtre fait simplement tourner une plus grosse part du web, alors on le voit à plus grande échelle.

Donc la leçon que je retiens d'octobre, ce n'est pas que l'IA fait peur. C'est que « on est sur une branche maintenue » doit être une exigence permanente, vérifiée aussi souvent que les sauvegardes, et pas un vœu pieux qu'on valide au détour d'une réécriture. Si ton plus vieux serveur de production ne peut pas passer à une version mineure maintenue dans la semaine qui suit un avis de sécurité, c'est ça ton vrai risque, peu importe qui ou quoi trouvera le prochain bug.

Ce qui m'amène à ce que j'aimerais vraiment savoir de toi. Qu'est-ce qui bloque ton plus vieux serveur de production sur sa version actuelle de PHP : une extension, une version majeure de framework, un contrat client, ou simplement le fait que personne n'en est responsable ? Et, de façon réaliste, combien de temps te faudrait-il pour le passer sur une branche maintenue si le prochain avis tombait demain matin ?