Node.js corrige quatorze failles de sécurité sur ses trois branches LTS

Le projet Node.js a livré, mercredi 11 novembre 2026, des versions correctives pour ses trois branches activement maintenues, 22.x, 24.x et 26.x. Le lot ferme quatorze vulnérabilités, dont sept classées en gravité élevée, et touche en premier lieu les serveurs HTTP/2 et TLS exposés à des clients non fiables. Une fuite de clés privées en mémoire figure parmi les cas les plus sérieux.

#Sept failles de gravité élevée, d’une fuite de clés TLS à un déni de service HTTP/2

Les versions publiées sont 22.23.5, 24.22.3 et 26.13.1. La faille la plus préoccupante, CVE-2026-123864, provient d’un problème de réentrance dans TLSWrap::DoWrite() : elle peut faire fuiter la mémoire du serveur, clés privées TLS comprises, directement dans le corps d’une réponse HTTP. Le trafic node:http en clair n’est pas concerné, seules les connexions chiffrées le sont.

Plusieurs autres failles élevées touchent la pile HTTP/2 : abandon de connexion non authentifié via une assertion dans ~Http2Session(), sessions jamais nettoyées après une erreur de protocole pendant la fermeture, ou encore use-after-free lors du dévouement d’un flux. Une dernière, CVE-2026-123872, permet à un client de renégocier une session TLS 1.2 pour changer de nom de serveur et contourner l’authentification par certificat client.

#Des failles moyennes et faibles qui méritent aussi une revue de code

Le lot moyen touche notamment le modèle de permissions : les règles --allow-fs-read et --allow-fs-write avec caractère générique accordent plus d’accès que prévu, un /etc/passwd.* finissant par autoriser /etc/passwd. Une autre entrée touche https.Agent, où la réutilisation de session TLS entre deux politiques de CA différentes contourne la validation de certificat, aux côtés d’identifiants de proxy visibles en clair dans un message d’erreur et d’un fs.watch récursif qui expose, sur macOS et Windows, des noms de fichiers normalement interdits.

Une renégociation TLS 1.2 qui change de nom de serveur en cours de route peut suffire à contourner une authentification par certificat client pourtant bien configurée.

#Mettre à jour sans attendre une fenêtre de maintenance

Aucune des notes de version ne documente de contournement pour les éditions non corrigées : la mise à jour reste la seule remédiation. La vérification tient en une ligne, suivie de l’installation de la version corrigée de la branche concernée.

node -v
# selon la branche utilisée
nvm install 22.23.5
nvm install 24.22.3
nvm install 26.13.1

Les dépendances internes llhttp, undici et sqlite ont également été remontées dans ce lot, sans changement côté V8. Les lignes déjà arrivées en fin de vie ne reçoivent, elles, aucun correctif.

#Un rythme de correctifs qui concerne tout l’écosystème back-end

Le calendrier de versions de Node.js, dont la bascule vers un cycle annuel a été actée début novembre sur la branche 27 en alpha, ne change rien au traitement des urgences de sécurité sur les lignes LTS existantes. Les équipes qui orchestrent ces montées de version gagnent à s’appuyer sur des outils de ligne de commande capables de verrouiller une version précise par projet. La même rigueur vaut côté chiffrement du transport, qu’il s’agisse d’un serveur applicatif ou, dans un tout autre contexte, de la supervision du chiffrement SMTP : un certificat mal validé a les mêmes conséquences, quel que soit le protocole.

#Ce qu’il faut retenir

Quatorze failles corrigées en une seule publication, dont sept de gravité élevée concentrées sur HTTP/2 et TLS, justifient une mise à jour rapide des trois branches LTS de Node.js. Les équipes qui exposent des serveurs HTTP/2 ou TLS à des clients extérieurs doivent traiter ce correctif en priorité ; les autres gagneront à revoir leurs règles du modèle de permissions avant leur prochain cycle de déploiement.

Pour aller plus loin : les notes de version complètes sont publiées par le projet Node.js sur nodejs.org.