Sécurité Node.js, octobre 2026 : quoi mettre à jour et pourquoi

Le 21 octobre 2026, le projet Node.js a publié des versions de sécurité pour ses trois branches supportées : v26.12.1, v24.22.1 et v22.23.4. Elles corrigent dix vulnérabilités. Quatre sont jugées de gravité élevée, et celle qui attire le plus l'attention est une écriture hors limites dans le décodeur Brotli qui, selon le projet, permet une exécution de code à distance. Le correctif existe déjà pour chaque branche supportée : c'est donc une mise à jour de routine, à faire tant qu'elle reste de la routine.

Trois sortes de correctifs dans une seule version

Les quatre failles de gravité élevée ne forment pas un seul bug. Elles se trouvent dans trois parties différentes du runtime, et chacune est atteinte par un type de code différent.

Le décodeur Brotli (CVE-2026-111497, les trois branches). Un bug mémoire dans le code natif qui décompresse des données. Ma lecture, en raisonnement général et non d'après un détail de l'avis : le code qui l'atteint est celui qui décompresse des données Brotli contrôlées par quelqu'un d'autre. Un serveur qui accepte des corps de requête compressés, ou un client qui récupère des réponses d'API tierces et les décompresse, entrent tous les deux dans ce cas.

La validation du nom d'hôte TLS (CVE-2026-106069 sur les trois branches, CVE-2026-105483 sur 26 et 24). Ce sont des bugs de logique dans la vérification qu'un certificat correspond bien à l'hôte que vous vouliez joindre : l'un quand l'hôte se résout de façon approximative en adresse IP, l'autre quand une IP est écrite avec des chiffres pleine chasse. Une faille voisine de gravité moyenne, CVE-2026-106072, permet à des noms DNS d'un certificat d'authentifier des points d'accès IP écrits sous une forme IPv4 non canonique. Le code exposé : tout ce qui se connecte à un hôte ou une IP venus d'un utilisateur, d'un réglage de webhook ou d'un fichier de configuration.

La gestion des noms DNS (CVE-2026-105482, les trois branches). dns.resolve tronque les noms qui contiennent un caractère NUL. Là encore en raisonnement général : cela compte dès qu'un nom que vous n'avez pas écrit vous-même est résolu, par exemple pour le comparer à une liste d'autorisation.

Les autres sont de gravité moyenne ou faible : un socket keep-alive qui traite une réponse écrite avant l'envoi de la requête, des valeurs aléatoires qui se répètent dans les snapshots de démarrage, et des problèmes dans le modèle de permissions et dans ZipFile. La version met aussi à jour des dépendances embarquées, dont c-ares, Undici et la liste des certificats d'autorité, qui retire la confiance accordée à l'autorité intermédiaire compromise d'eMudhra.

Vérifier le Node qui tourne vraiment

Votre ordinateur portable est en général l'endroit le moins important à vérifier. Le runtime qui sert le trafic vient d'une image Docker de base, et celui qui exécute vos tests vient d'une image de CI. Tous peuvent dériver les uns des autres.

# on any machine, or inside a running container
node -v
# what a base image really ships, without trusting its tag name
docker run --rm node:22 node -v

Comparez chaque réponse aux versions corrigées : 26.12.1 ou plus sur la 26, 24.22.1 ou plus sur la 24, 22.23.4 ou plus sur la 22. Un tag comme node:22 ne bouge que quand vous le récupérez à nouveau, donc une image en cache sur un serveur de build peut encore contenir l'ancien patch. Si votre Dockerfile fixe une version exacte, montez-la.

Node 20 ne reçoit rien

Node 20 « Iron » est en fin de vie ; sa dernière mise à jour date du 24 mars 2026, et il ne figure pas dans cette version. Le projet le dit clairement : les versions en fin de vie sont toujours concernées quand une version de sécurité sort. « On est en 20, elle n'était pas listée » veut donc dire l'inverse de « on est tranquilles ». Les branches impaires comme 25 et 23 sont elles aussi en fin de vie. La consigne du projet est de ne faire tourner en production que des branches Active LTS ou Maintenance LTS, soit aujourd'hui 24 ou 22, ou 26 si vous acceptez une version Current.

L'étape suivante est petite : montez la version de l'image de base dans votre Dockerfile et dans la config de CI jusqu'au patch corrigé de votre branche, reconstruisez sans cache et laissez tourner la suite de tests. Si vous êtes encore en Node 20, planifiez dès maintenant le passage en 22 ou 24 plutôt qu'au prochain avis. Source : nodejs.org, Wednesday, October 21, 2026 Security Releases.