Node.js : les failles HTTP/2 et HTTPS permettent à des clients de faire planter des serveurs et de lire les données d'autres utilisateurs

Ce qui s'est passé

Le 11 novembre 2026, le projet Node.js a publié des versions de sécurité pour ses trois branches prises en charge. Les versions corrigées sont 22.23.5, 24.22.3 et 26.13.1. Elles corrigent 16 vulnérabilités dans Node.js lui-même, dont sept sont classées à haut risque. Les versions mettent également à jour les dépendances intégrées llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) et sqlite (22.x, 24.x).

Les problèmes les plus importants concernent le code serveur que Node.js fournit lui-même pour HTTP/2, HTTPS et TLS :

• Plantage du serveur HTTP/2 (24.x et 26.x) : tout client non authentifié peut provoquer l'arrêt du processus Node.js. Le serveur n'a besoin que de la configuration HTTP/2 par défaut et d'un gestionnaire qui répond avant la réception complète du corps de la requête. Le projet qualifie ce comportement de typique. L'attaque fonctionne via TLS comme via des connexions en clair.
• Divulgation de mémoire HTTP/2 (les trois branches) : un serveur peut envoyer à un client des fragments de sa mémoire, y compris des réponses destinées à d'autres connexions. À partir des versions 24.22.0 et 26.9.0, un client peut déclencher ce problème de sa propre initiative. Sur les versions 22.x et sur les anciennes versions 24.x et 26.x, cela peut se produire lorsque le serveur ferme un flux en cours de réponse, par exemple après un délai d'inactivité.
• Divulgation de mémoire HTTPS (les trois branches) : un client non authentifié peut lire la mémoire d'autres connexions, « y compris des clés privées TLS et les requêtes d'autres utilisateurs », selon le projet. Cela nécessite un gestionnaire qui appelle res.flushHeaders() avant la fin du corps de la requête, puis res.end() avec des données. Pour lire la mémoire divulguée, l'attaquant a également besoin d'une route qui renvoie ou stocke le corps d'une requête.
• Épuisement des ressources HTTP/2 (les trois branches) : un client peut amener tout serveur HTTP/2 par défaut à conserver de manière permanente de la mémoire et des descripteurs de fichiers.
• Service de fichiers HTTP/2 (24.x et 26.x) : un client peut corrompre la mémoire du serveur lorsque celui-ci sert des fichiers via stream.respondWithFile() ou stream.respondWithFD(). Sur les trois branches, l'annulation de tels téléchargements peut aussi faire planter le serveur (risque moyen).
• Plantage du serveur TLS (24.x et 26.x) : un client peut faire planter un serveur TLS qui utilise les hooks SNICallback, OCSPRequest, newSession ou resumeSession, ou server.addContext().
• Contournement du certificat client TLS (les trois branches) : certains serveurs appliquent des règles plus strictes sur les certificats clients pour certains noms d'hôte. Sur ces serveurs, un client autorisé pour un autre nom d'hôte peut passer à un hôte plus strict lors d'une renégociation TLS 1.2, sans respecter ses règles.

Le bulletin ne signale aucune attaque exploitant ces failles.

Qui est concerné

• Les serveurs exécutant Node.js 22.x avant 22.23.5, 24.x avant 24.22.3 ou 26.x avant 26.13.1.
• Les branches en fin de vie, dont 20.x et 25.x, ne reçoivent aucun correctif dans cette version. Le projet indique que ces versions sont toujours concernées.
• Les problèmes graves côté serveur ne touchent que les cas où un processus Node.js accepte lui-même des connexions HTTP/2, HTTPS ou TLS. Exemples : les modules intégrés node:http2, node:https ou node:tls, ou les frameworks qui les utilisent pour terminer TLS ou HTTP/2.
• Les serveurs HTTP simples construits avec node:http ne sont pas concernés par la divulgation de mémoire HTTPS.
• Le plantage HTTP/2 ne touche que les branches 24.x et 26.x, et non la branche 22.x.

Votre exposition est nettement moindre si un reverse proxy comme nginx, Apache, HAProxy ou un équilibreur de charge termine TLS et HTTP/2, et que Node.js ne reçoit de lui que du HTTP/1.1 en clair. Vous devez tout de même mettre à jour, car cette version contient d'autres correctifs et mises à jour de dépendances.

Que faire maintenant

1. Repérez toutes les installations de Node.js. Pensez aux paquets système, aux gestionnaires de versions (nvm, n, Volta), aux images Docker, aux runners CI et aux panneaux d'hébergement qui embarquent leur propre Node.js.
2. Mettez à jour vers la version corrigée de votre branche : 22.23.5, 24.22.3 ou 26.13.1. Si vous utilisez des paquets de distribution ou de fournisseurs (par exemple NodeSource ou la distribution Linux), installez la mise à jour dès que votre source de paquets propose ces versions.
3. Quittez les versions en fin de vie. Si vous utilisez encore 20.x, 25.x ou une version plus ancienne, passez à une branche prise en charge. Le bulletin ne propose aucune solution de contournement pour les serveurs qui ne peuvent pas être mis à jour.
4. Reconstruisez les images de conteneurs avec une image de base Node.js mise à jour, puis redéployez-les. La mise à jour de l'hôte seul ne modifie pas Node.js à l'intérieur des conteneurs.
5. Redémarrez tous les processus Node.js (unités systemd, PM2, conteneurs Docker, etc.) afin que le nouveau runtime soit chargé. Vérifiez ensuite que vos applications répondent normalement.
6. Envisagez de renouveler vos secrets si vous avez été exposé. Le bulletin ne précise pas si les serveurs remplissant les conditions de la divulgation de mémoire HTTPS doivent remplacer leurs clés TLS ou d'autres secrets. Si un de vos serveurs HTTPS Node.js remplissait ces conditions et était accessible depuis Internet, envisagez de renouveler son certificat et sa clé TLS.

Comment vérifier si vous êtes concerné

• Exécutez node -v sur chaque serveur, ainsi que dans chaque conteneur (docker exec <conteneur> node -v). Les versions inférieures à 22.23.5, 24.22.3 ou 26.13.1 de leur branche, ou toute branche en fin de vie comme 20.x ou 25.x, sont concernées.
• Avec PM2, pm2 list et pm2 show <app> indiquent le binaire et la version de Node.js utilisés par chaque application.
• Vérifiez si vos applications terminent elles-mêmes HTTP/2 ou TLS dans Node.js : recherchez dans le code http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback et addContext.
• Consultez votre gestionnaire de processus et les journaux système pour repérer les redémarrages ou plantages inattendus de Node.js. Des interruptions répétées d'un serveur HTTP/2 peuvent indiquer des tentatives d'exploitation du plantage.

Sources

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html