Node.js CVE-2026-123864 : 16 failles HTTP/2, HTTPS et TLS

En bref. Le projet Node.js a publié le mercredi 11 novembre 2026 des mises à jour de sécurité pour ses trois lignes maintenues : 22.23.5, 24.22.3 et 26.13.1. Elles corrigent 16 failles dans Node.js, dont 7 notées hautes, presque toutes dans le code serveur HTTP/2, HTTPS et TLS : un client non authentifié peut, selon les cas, arrêter le serveur ou obtenir des morceaux de mémoire appartenant à d'autres connexions. L'avis ne propose aucun contournement : la seule correction est la mise à jour. La priorité va aux processus Node.js qui acceptent eux-mêmes des connexions HTTP/2, HTTPS ou TLS.

Ce qui s'est passé

L'avis Wednesday, November 11, 2026 Security Releases du projet Node.js annonce des mises à jour pour les lignes 26.x, 24.x et 22.x. Il corrige aussi des dépendances embarquées pour des vulnérabilités publiques : llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) et sqlite (22.x, 24.x).

The Hacker News, qui a analysé l'avis le 12 novembre 2026, relève que l'avis ne signale aucune attaque utilisant ces failles. Selon le même article, cinq d'entre elles, dont CVE-2026-123863 et CVE-2026-123864, ont été signalées par Chris Rohlf en collaboration avec Claude et Anthropic Research.

Les versions en fin de vie, dont 20.x et 25.x selon The Hacker News, ne reçoivent aucun correctif. L'avis le rappelle : les versions en fin de vie sont toujours concernées lors d'une publication de sécurité.

Les sept failles hautes

Nous en décrivons le principe et les conditions, telles que les donne l'avis, sans détail d'exploitation.

| CVE | Composant | Effet | Lignes touchées | |---|---|---|---| | CVE-2026-123863 | HTTP/2 | arrêt du serveur à distance | 24.x, 26.x | | CVE-2026-123864 | HTTPS | fuite de mémoire du serveur vers un client | 22.x, 24.x, 26.x | | CVE-2026-123865 | HTTP/2 | sessions jamais libérées (mémoire, descripteurs) | 22.x, 24.x, 26.x | | CVE-2026-123866 | HTTP/2 | envoi au client de mémoire libérée | 22.x, 24.x, 26.x | | CVE-2026-126051 | TLS | arrêt du serveur via certains rappels de négociation | 24.x, 26.x | | CVE-2026-123872 | TLS 1.2 | changement de nom de serveur pendant une renégociation, contournant l'authentification par certificat client | 22.x, 24.x, 26.x | | CVE-2026-123874 | HTTP/2 | corruption de mémoire avec respondWithFile() | 24.x, 26.x |

Quelques précisions utiles pour trier vos services :

• CVE-2026-123863 ne demande qu'un serveur HTTP/2 par défaut qui répond avant d'avoir reçu tout le corps de la requête, un comportement que l'avis qualifie de typique. The Hacker News précise que l'attaque fonctionne en TLS comme en clair.
• CVE-2026-123864 touche les serveurs HTTPS dont un gestionnaire appelle res.flushHeaders() avant la fin du corps de la requête, puis res.end() avec des données. Pour lire la mémoire qui fuit, il faut aussi une route qui renvoie ou stocke le corps de la requête. Le projet indique, cité par The Hacker News, que cette mémoire peut contenir des clés privées TLS et les requêtes d'autres utilisateurs. Les serveurs HTTP simples construits avec node:http ne sont pas concernés.
• CVE-2026-123866 peut être déclenchée par le seul client à partir des versions 24.22.0 et 26.9.0. Sur 22.x et les versions plus anciennes de 24.x et 26.x, elle se déclenche quand le serveur ferme lui-même un flux en cours de réponse, par exemple après un délai d'inactivité.
• CVE-2026-126051 concerne les serveurs TLS qui utilisent les rappels SNICallback, OCSPRequest, newSession ou resumeSession, ou server.addContext().

Les neuf autres failles sont notées moyennes (six) ou basses (trois). Parmi elles : un dépassement de tampon d'un octet dans la gestion HTTP/2 Alt-Svc (CVE-2026-123828), un contournement de validation de certificat dans https.Agent par réutilisation de session TLS (CVE-2026-123877), la divulgation d'identifiants de proxy dans un message d'erreur (CVE-2026-123871), et un arrêt du serveur par annulation d'un téléchargement servi avec respondWithFile() (CVE-2026-123875).

Qui est concerné

The Hacker News le résume : les failles hautes sont dans le code serveur HTTP/2, HTTPS et TLS de Node.js. Elles comptent là où un processus Node.js accepte lui-même ces connexions.

Concrètement, sont exposés en priorité :

• les API et serveurs Node.js qui terminent eux-mêmes TLS (HTTPS exposé directement, sans proxy devant) ;
• les serveurs qui activent HTTP/2 dans Node.js, y compris pour du service de fichiers ;
• les services qui utilisent l'authentification mutuelle par certificat client (mTLS) en TLS 1.2, concernés par CVE-2026-123872 ;
• toute instance en ligne 20.x ou 25.x, qui reste vulnérable sans correctif possible.

Un service placé derrière un reverse proxy ou un répartiteur de charge qui termine TLS et HTTP/2 lui-même, et qui parle à Node.js en HTTP/1.1 simple, est moins directement exposé aux failles serveur. C'est une déduction à partir du périmètre décrit par la source, à vérifier service par service, pas une garantie : certaines failles moyennes touchent aussi le côté client (https.Agent).

Corriger : méthode en quatre étapes

1. Inventorier les versions réellement en production. Le piège habituel est de regarder le package.json alors que la version qui compte est celle de l'image ou du runtime. Relevez la version de Node.js dans chaque image de conteneur de base, chaque environnement serverless, chaque machine virtuelle et chaque poste de CI. Un scanner de composition logicielle (SCA, Software Composition Analysis) ou un scanner d'images qui inventorie le runtime fait ce travail à l'échelle.

2. Trier par exposition. Avec la liste, classez les services selon trois questions tirées de l'avis : Node.js termine-t-il TLS ? HTTP/2 est-il activé ? Le code appelle-t-il res.flushHeaders() avant la fin du corps de requête sur un serveur HTTPS ? Les services qui répondent oui passent en premier.

3. Mettre à jour vers la version corrigée de la ligne. 22.23.5, 24.22.3 ou 26.13.1. Pour les lignes en fin de vie, la seule option est la migration vers une ligne maintenue. Reconstruisez les images de base plutôt que de modifier les conteneurs en place, et vérifiez que le build n'utilise pas une étiquette d'image figée sur une ancienne version.

4. Contrôler. Après déploiement, vérifiez la version effectivement exécutée par chaque service (par une route de santé qui expose la version de runtime en interne, ou par le scanner d'images), pas seulement celle déclarée dans le dépôt.

La question des clés TLS

The Hacker News note que l'avis ne dit pas si les serveurs qui réunissaient les conditions de CVE-2026-123864 doivent remplacer leurs clés TLS ou d'autres secrets après la mise à jour. Aucune exploitation n'étant signalée, la décision vous appartient. Une approche proportionnée, à titre de bonne pratique : si un service exposé à Internet réunissait les deux conditions (appel à res.flushHeaders() avant la fin du corps, et route qui renvoie ou stocke le corps de requête), le renouvellement de son certificat et de sa clé privée est une mesure peu coûteuse au regard de ce qu'une fuite permettrait.

Ce qu'il faut retenir pour le pipeline

Cet avis est un cas typique pour une chaîne DevSecOps : 16 failles, aucun contournement, trois lignes à suivre en parallèle. Trois capacités, à titre de bonne pratique, permettent d'absorber ce type d'avis sans course contre la montre : un inventaire automatique des runtimes en production, des images de base reconstruites et redéployées par le pipeline, et une règle qui bloque le déploiement de versions en fin de vie. Si l'une manque, cet avis est une bonne occasion de la mettre en place.

FAQ

Quelles versions de Node.js corrigent les failles de novembre 2026 ?

Node.js 22.23.5, 24.22.3 et 26.13.1, publiées le 11 novembre 2026.

Y a-t-il un contournement si je ne peux pas mettre à jour ?

L'avis n'en liste aucun. The Hacker News le souligne : la mise à jour est la seule correction proposée.

Node.js 20 est-il concerné ?

Les versions en fin de vie, dont 20.x selon The Hacker News, ne reçoivent aucun correctif et sont considérées comme toujours concernées par le projet. La seule voie est la migration.

Ces failles sont-elles exploitées ?

L'avis ne signale aucune attaque, selon The Hacker News. Cette absence au jour de la publication ne garantit rien pour la suite : mieux vaut planifier la mise à jour sans attendre un signal d'exploitation.

Sources

• Node.js, Wednesday, November 11, 2026 Security Releases : https://nodejs.org/en/blog/vulnerability/november-2026-security-releases
• The Hacker News, Swati Khandelwal, Node.js Fixes 16 Flaws, Including HTTP/2 Bugs That Crash Servers and Leak Other Connections' Data, 12 novembre 2026 : https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html

---

Pour automatiser l'inventaire des runtimes et le déploiement des correctifs dans vos pipelines, WeeSec accompagne les équipes en DevSecOps.