L'avis officiel de PHP décrit CVE-2026-109619 comme une exécution de code à distance via un état de worker périmé, et je n'arrête pas de relire cette formule, parce qu'elle décrit nos habitudes de déploiement autant que le bug lui-même. Le 21 octobre, le projet PHP a publié 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent cette faille ainsi que CVE-2026-109618, un chemin de corruption mémoire déclenché en situation de manque de mémoire. Les deux affichent un score CVSS v4.0 de 9.2 et sont exploitables sans authentification. Ma position est simple : la liste des versions, c'est la partie facile de la semaine. Ce que la plupart des équipes ne savent pas faire, et qu'elles devraient apprendre quitte à en rougir, c'est prouver quel build de PHP sert chaque requête, sur chaque hôte, à cet instant précis.

Regarde comment le correctif arrive vraiment en production. Ta distribution peut le rétroporter dans un paquet qui affiche toujours 8.5.4 ou 8.3.quelque chose, donc la chaîne de version ne t'apprend pas grand-chose. Ton image de conteneur peut être corrigée dans le registre pendant que trois réplicas datant d'août continuent tranquillement de servir du trafic. Le processus maître de PHP-FPM a pu être mis à jour sur disque à 03:12 alors que ses processus enfants gardent l'ancien code en mémoire jusqu'à ce que quelqu'un redémarre le service. Et le binaire CLI que tu interroges avec php -v en SSH peut très bien être un autre build que celui qu'Apache ou FPM utilise pour le site. Wordfence le souligne explicitement en renvoyant les propriétaires de sites WordPress vers Tools > Site Health > Info > Server plutôt que vers le shell, et franchement, chaque équipe qui travaille avec un framework mériterait une page équivalente.

Les résultats de labo de l'équipe Wordfence Threat Intelligence méritent une lecture attentive, parce qu'ils jouent dans les deux sens. Dans un labo Apache sous PHP 8.5.11 configuré tout spécialement, leur preuve de concept pour CVE-2026-109619 est passée par du simple HTTP et a écrit un fichier texte temporaire, ce qui est de l'exécution de code, quelle que soit la définition qu'on retient. Contre un build 8.5.11 optimisé classique, la même requête a seulement fait planter PHP. Pour CVE-2026-109618, ils ont vu 8.5.11 tomber là où 8.5.12 répondait normalement, et sur une pile WordPress 7.1.3 avec un paquet Ubuntu 8.5.4 vulnérable, ils ont provoqué des plantages et des redémarrages dans certaines configurations, sans parvenir eux-mêmes à exécuter du code.

Voici le meilleur argument pour se détendre, et je veux lui accorder tout son poids. Si l'exploit public a besoin d'un build réglé en labo pour faire autre chose que planter un worker, alors pour un serveur de production typique, le scénario réaliste aujourd'hui, c'est un déni de service, et une bonne partie du code de preuve de concept qui circule est, de l'aveu même de Wordfence, incomplète ou fausse. Patcher dans la panique un vendredi a ses propres façons de mal tourner, et quiconque a déjà cassé un tunnel de paiement avec un redémarrage précipité sait que ce coût est bien réel.

Je n'y crois toujours pas. CrowdStrike affirme que son exploit non publié fonctionnait de façon fiable aussi bien sur Intel/AMD que sur Arm, y compris contre des workers fraîchement redémarrés, et PHP a lui-même confirmé l'exécution de code pour les deux bugs, avec un chemin de 109618 qui se déclenche avant même que WordPress ne démarre. Ce dernier détail concerne tout le monde, framework ou pas : aucun pare-feu applicatif, aucun middleware, aucun validateur de requêtes astucieux dans ton kernel Laravel ou Symfony ne voit passer une requête qui explose avant que ton code ne s'exécute. Les exploits qui se contentent de faire planter cette semaine donnent une idée assez fiable de ce qu'ils deviendront la semaine prochaine, et un pool FPM qui s'effondre sous une attaque, c'est déjà une panne que tu devras expliquer à quelqu'un.

Alors ce que j'aimerais qu'on retienne de cet incident, c'est une habitude. Traite « quel PHP tourne ici, démarré quand, depuis quelle révision de paquet » comme un fait observable que tu peux interroger, au même titre que le commit déployé. Expose-le sur un endpoint de santé protégé par authentification, logue-le au démarrage des workers, ajoute le digest de l'image dans les labels de tes métriques. Les gens de Go peuvent se vanter qu'un binaire statique rend tout ça trivial, et soit, sur ce point précis ils ont raison, mais on a opcache_get_status, php_uname, PHP_VERSION et le gestionnaire de paquets, et assembler le tout prend un après-midi. Fais-le avant le prochain avis de sécurité, puis passe en revue les sites de staging et les IP d'origine que Wordfence pointe à juste titre, et conserve tes logs web, PHP et pare-feu à partir de 48 heures avant la publication, au cas où tu aurais tardé.

Une dernière remarque désagréable pour ceux qui sont encore en 8.1 ou plus ancien : le projet PHP ne publie plus de versions pour ces branches, donc ta sécurité dépend entièrement d'un éditeur qui affirme, par écrit, avoir intégré les deux correctifs. Si tu n'arrives pas à obtenir cette phrase de sa part, tu as ta réponse, et la migration que tu repousses depuis des mois vient de recevoir une échéance.

Je suis curieux de savoir comment vous gérez ça en pratique dans ton équipe. Quand une version de sécurité tombe, comment tu vérifies concrètement que chaque processus PHP en cours d'exécution, entre les pools FPM, les workers de files d'attente, les conteneurs cron et cette fameuse VM legacy, tourne bien sur le code corrigé, et combien de temps ça t'a pris cette fois-ci ?