Node.js corrige 16 failles de sécurité sur les branches 22, 24 et 26

Le projet Node.js a publié le 11 novembre 2026 une salve de correctifs de sécurité pour les trois branches actives, 22.x, 24.x et 26.x. Seize vulnérabilités sont comblées, dont neuf classées en sévérité élevée, la plupart logées dans le module HTTP/2 et dans la couche TLS. Les versions 22.23.5, 24.22.3 et 26.13.1 sont recommandées sans délai pour tout serveur exposé à des clients non authentifiés.

#Seize failles corrigées, un volume inhabituel

La publication regroupe des correctifs répartis sur trois niveaux de sévérité : neuf failles élevées, six moyennes et une faible. Plusieurs portent sur des scénarios de type déni de service ou fuite de mémoire déclenchables à distance, sans authentification préalable. Deux d’entre elles sont des variantes ou des correctifs incomplets de failles déjà traitées par le passé, ce qui signale la difficulté à fermer durablement certaines classes de bugs dans l’implémentation HTTP/2 du runtime, à peine un mois après que Node.js 26 a basculé en support à long terme sous le nom Lithium.

#HTTP/2 et TLS concentrent les points chauds

Sept des seize correctifs touchent directement le module HTTP/2 : usage de mémoire déjà libérée pendant la fermeture d’un flux, dépassement de tampon d’un octet dans session.altsvc(), ou sessions qui restent bloquées en CLOSE_WAIT faute d’un nettoyage correct après une erreur de protocole. Côté TLS, une réexécution de llhttp_execute() déclenchée par une écriture de longueur nulle peut provoquer une utilisation de mémoire libérée et exposer le contenu de requêtes en cours. Une autre faille permet à un client de changer de nom de serveur pendant une renégociation TLS 1.2, contournant ainsi des politiques de certificat client définies par hôte.

#Le modèle de permissions laisse passer des jokers trop larges

La faille CVE-2026-106071 concerne les applications lancées avec le modèle de permissions expérimental. Une règle en apparence restrictive peut en réalité autoriser bien plus que prévu :

# Censé ne matcher que les fichiers /etc/passwd.,
# mais autorise aussi la lecture de /etc/passwd lui-même
node --permission --allow-fs-read=/etc/passwd.* app.js

Le correctif resserre l’interprétation des motifs génériques pour les options --allow-fs-read et --allow-fs-write. Les équipes qui s’appuient sur ce modèle pour isoler des processus doivent revérifier leurs règles existantes après mise à jour.

Neuf des seize vulnérabilités corrigées portent la sévérité la plus haute que Node.js attribue en dehors d’une faille critique, un volume inhabituel pour une seule salve de correctifs.

#Prioriser la mise à jour selon l’exposition réelle

Toutes les failles ne pèsent pas de la même façon selon l’architecture en place. Les problèmes HTTP/2 concernent en priorité les serveurs qui acceptent ce protocole depuis des clients non maîtrisés. Les failles liées à respondWithFile() ne touchent que les applications qui servent des fichiers par cette voie. Le problème zlib ne se déclenche que si deflate.params() est appelé en cours de flux. L’équipe Node.js recommande de monter en priorité vers 22.23.5, 24.22.3 ou 26.13.1 selon la branche utilisée, puis d’auditer les dépendances llhttp et undici, également mises à jour dans ce train de correctifs. La même discipline de mise à jour rapide vaut pour l’ensemble de la pile exposée publiquement, qu’il s’agisse du runtime ou, par exemple, du socle minimal recommandé pour durcir une installation WordPress.

#Ce qu’il faut retenir

Seize vulnérabilités sont corrigées dans les branches 22.x, 24.x et 26.x de Node.js, dont neuf de sévérité élevée, concentrées sur HTTP/2 et TLS. La mise à jour vers 22.23.5, 24.22.3 ou 26.13.1 est à traiter en priorité pour tout service exposé à des clients non authentifiés, et les équipes utilisant le modèle de permissions doivent revalider leurs règles de filtrage de fichiers.

Pour aller plus loin : le détail complet des seize vulnérabilités est publié sur le blog officiel de sécurité de Node.js.