Vulnérabilités critiques dans PHP et Node.js, les correctifs du 21 octobre

Le 21 octobre 2026, deux bulletins de sécurité distincts ont été publiés : l'un pour PHP, l'autre pour Node.js. Tous deux concernent des vulnérabilités qui peuvent permettre l'exécution de code à distance, c'est-à-dire la possibilité pour un attaquant d'exécuter des commandes sur un système sans avoir besoin d'identifiants.

Pour PHP, deux failles ont été signalées, CVE-2026-109618 et CVE-2026-109619. La première concerne la gestion de la mémoire lorsque les ressources du système s'épuisent : certaines données de la requête peuvent rester partiellement initialisées et être malgré tout traitées comme valides lors du nettoyage. Le problème a été démontré sur des configurations avec Apache et mod_php, et peut survenir avant que l'application ne vérifie les identifiants de l'utilisateur. PHP-FPM est également considéré comme vulnérable, même si, pour cette variante, aucune démonstration complète de l'attaque n'existe encore. La seconde faille concerne des données internes qu'un processus PHP peut conserver après avoir libéré la mémoire d'une requête précédente : une requête suivante peut finir par accéder à ces références qui ne sont plus valides.

Pour Node.js, le bulletin signale CVE-2026-111497, une faille de gravité élevée dans le décodeur du format de compression Brotli, également utilisé dans le trafic des sites web. Là aussi, la vulnérabilité peut conduire à l'exécution de code à distance, bien que le risque concret dépende de la façon dont l'application traite les données compressées qu'elle reçoit. La même mise à jour de Node.js corrige aussi des problèmes liés au DNS et à la vérification des certificats TLS.

Les correctifs sont inclus dans les versions les plus récentes publiées par les deux projets, mais identifier la bonne version n'est pas toujours simple. Une distribution Linux peut avoir déjà appliqué le correctif tout en conservant un numéro de version qui semble ancien : pour PHP 8.3 sous Ubuntu 24.04, par exemple, le correctif correspond au paquet 8.3.6-0ubuntu0.24.04.13, et non à un saut de version visible au premier regard.

Pour qui gère des serveurs PHP, il existe un outil libre, php2shell-audit, publié sur GitHub. Il recense les installations de PHP présentes sur une machine, relève leur version exacte et le paquet de la distribution dont elles proviennent, et les compare aux versions corrigées, en tenant compte des correctifs appliqués par les distributions. Il peut aussi rechercher dans les journaux les traces d'une tentative d'attaque. Le scanner n'essaie pas d'exploiter les failles : sur les sites distants, il se contente de lire les en-têtes de la réponse, et il ne doit être utilisé que sur ses propres systèmes ou avec une autorisation explicite.

La même comparaison est appliquée, de manière passive, à l'administration publique par le Recensement de la sécurité du secteur public suisse, un projet de Webcracy qui vérifie chaque jour quelque 2200 communes, cantons et offices fédéraux en ne lisant que des données publiques. Il indique notamment combien des entités qui affichent leur version de PHP sont déjà passées à une version corrigée. L'absence d'en-tête ne suffit toutefois pas à dire qu'un site est sûr.

Le travail de vérification derrière la mise à jour

Webcracy, société de logiciels de Locarno qui suit des sites et des applications pour des entreprises tessinoises, a expliqué comment elle a géré la mise à jour pour ses clients. La première étape a consisté à établir quelles versions de PHP et de Node.js servaient réellement les requêtes : sur un même serveur peuvent coexister le PHP du système, celui d'un conteneur et celui d'une application distincte, et en corriger un laisse les autres tels quels. De même, un Node.js déjà chargé en mémoire par un gestionnaire de processus comme PM2 continue de tourner jusqu'à son redémarrage, quelle que soit la version installée entre-temps.

Avant d'intervenir, les versions précédentes des conteneurs et des copies des bases de données ont été conservées, afin de pouvoir revenir en arrière en cas de problème. Les modifications ont été testées sur des copies isolées des environnements, avec les tests automatisés des applications et des contrôles manuels des fonctions qui comptent au quotidien : connexions, bases de données, documents. Le passage en production s'est fait sans interruption : la surveillance des points de terminaison a continué de recevoir des réponses correctes.

Ce cas montre pourquoi un site protégé par un VPN ou mis à jour uniquement au niveau du CMS n'est pas automatiquement sûr : le correctif concerne l'environnement d'exécution PHP ou Node.js qui fait fonctionner l'application, pas seulement le logiciel écrit au-dessus. Une application peut en outre continuer à utiliser une ancienne version de l'environnement d'exécution à l'intérieur d'une image Docker, même après la mise à jour du système d'exploitation.