Node.js corrige une faille RCE dans le décodeur Brotli de toutes ses lignes supportées
Le 21 octobre 2026, Node.js publie des correctifs de sécurité pour ses trois lignes supportées (22.x, 24.x, 26.x) et corrige dix failles, dont une écriture hors limites dans le décodeur Brotli (CVE-2026-111497) pouvant mener à une exécution de code à distance. Aucun contournement n’étant proposé, la mise à jour vers 22.23.4, 24.22.1 ou 26.12.1 est la seule parade.
21 octobre 2026. Node.js publie des correctifs de sécurité pour ses trois lignes supportées — 22.x, 24.x et 26.x — et corrige dix failles. 21 octobre 2026. La plus sérieuse est une écriture hors limites dans le décodeur Brotli que le projet embarque, capable selon ses termes d’autoriser une exécution de code à distance (CVE-2026-111497). 22 octobre 2026. Une preuve de concept publique n’a obtenu l’exécution de code que contre une version de test volontairement affaiblie. Pourquoi c’est important : la faille touche du code embarqué par Node.js, pas le vôtre — elle se déclenche dès que votre application décompresse du Brotli contrôlé par un attaquant, y compris via un simple fetch().
Une écriture hors limites dans du code que vous n’avez pas écrit
La faille Brotli ne vit pas dans un programme utilisateur : elle vit dans la copie de la bibliothèque de compression Brotli que Node.js embarque. Node.js exécute ce code chaque fois qu’il décompresse des données Brotli — soit directement à travers le module node:zlib, soit automatiquement quand du code appelle fetch() sur une réponse envoyée avec une compression Brotli.
Concrètement, une application est exposée dès qu’elle décompresse du Brotli dont un attaquant contrôle le contenu : un corps de requête compressé, ou une réponse récupérée depuis un autre serveur. Le défaut est une écriture hors limites dans le décodeur, déclenchée par une entrée compressée malformée. Le correctif est un patch amont du projet Brotli que Node.js a recopié : le décodeur détecte désormais l’entrée invalide et s’arrête plus tôt au lieu d’écrire au-delà du tampon.
Le même correctif a été publié dans Brotli 1.2.1, 1.1.1 et 1.0.10 le 21 octobre. Toute autre application qui embarque sa propre copie de Brotli — des serveurs web, des proxies, des outils de ligne de commande — peut donc avoir besoin de la même mise à jour. Le changement avait été introduit dans le code source de Brotli dès février 2026, mais n’a été livré comme correctif de sécurité qu’en octobre.
Les versions corrigées sont 22.23.4 et 24.22.1 sur les lignes LTS, et 26.12.1 sur la ligne courante. Node.js 20.x et les versions antérieures sont en fin de vie et ne recevront pas le correctif : elles doivent migrer vers une ligne supportée.
Le décalage entre le libellé et la réalité de l’exploitation
Le projet qualifie la faille de haute, pas de critique, et ce choix est étayé. Une preuve de concept publiée le 22 octobre n’a atteint l’exécution de code que contre une version de test délibérément affaiblie. Sur une version standard de Node.js, son auteur rapporte un crash et une lecture limitée de la mémoire du processus, pas d’exécution de code, et conclut qu’aucune attaque fonctionnelle contre une version normale n’a été réalisée.
Node.js corrigé rejette l’entrée malformée utilisée par la preuve de concept, et aucune exploitation en conditions réelles n’avait été signalée au 22 octobre. Ce n’est pas une raison pour différer : une écriture hors limites dans un décodeur de compression est exactement le type de défaut que la recherche offensive fait mûrir en RCE exploitable en quelques semaines, et l’absence de correctif de contournement supprime toute marge de manœuvre.
Les neuf autres failles, et deux oublis à ne pas négliger
Les dix correctifs ne se limitent pas à Brotli. Trois autres failles sont classées haute. Deux concernent des contournements de vérification de certificat TLS : un attaquant peut écrire l’adresse IP d’un serveur sous une forme inhabituelle pour qu’un certificat corresponde à un hôte auquel il n’a pas droit — des chiffres pleine chasse pour CVE-2026-105483, une résolution approximative de l’hôte vers une IP pour CVE-2026-106069. La troisième empêche dns.resolve de tronquer un nom d’hôte au niveau d’un octet nul (CVE-2026-105482).
La faille moyenne la plus sournoise est CVE-2026-106074 : crypto.randomUUID() et crypto.randomInt() renvoient les mêmes valeurs à chaque processus quand une application est construite en startup snapshot ou en exécutable unique (SEA). Tout ce qui repose sur l’imprévisibilité de ces valeurs — jetons, identifiants de session, nonces — se retrouve alors déterministe. Deux correctifs faibles concernent le modèle de permission : un sur-accord d’accès au système de fichiers via une recherche radix avec caractère générique (CVE-2026-106071) et un contournement via fs.realpathSync (CVE-2026-106073).
La mise à jour rafraîchit aussi plusieurs composants embarqués : la copie d’undici, le client HTTP derrière fetch(), absorbe trois avis de gravité modérée ; c-ares, OpenSSL (sur 22.x et 24.x) et SQLite (sur 22.x) reçoivent des correctifs pour des vulnérabilités publiques connues.
Le blocage des clés eMudhra, embarqué dans la même mise à jour
Les mêmes versions cessent de faire confiance aux huit clés intermédiaires de l’autorité indienne eMudhra signalées compromises quelques jours plus tôt. Node.js utilise la liste de racines de Mozilla mais n’effectue pas de contrôle de révocation par défaut : avant cette mise à jour, une chaîne de certificats construite sur l’une de ces clés compromises passait donc encore. La mise à jour ajoute un blocage intégré des huit clés et retire trois racines emSign de la liste embarquée ; Go avait fait le même blocage dans sa propre mise à jour du 20 octobre.
Le lien avec notre analyse de la sortie d’eMudhra du marché des certificats TLS est direct : la compromission d’une autorité se propage dans les runtimes avant même que la plupart des administrateurs aient reçu l’alerte. Une connexion reprise depuis une session établie avant la mise à jour ne sera pas re-vérifiée tant que cette session n’expire pas, et les lignes en fin de vie ne reçoivent pas le blocage.
Ce que la mise à jour dit de vos dépendances embarquées
La faille Brotli illustre un angle mort classique du suivi de vulnérabilités : vous auditez vos dépendances applicatives, mais pas les bibliothèques natives qu’un runtime compile et embarque en silence. Node.js livre sa propre copie de Brotli, d’undici, d’OpenSSL, de c-ares et de SQLite — et chacune transporte son propre historique de failles. Une CVE dans l’une d’elles se propage à tous les programmes Node.js, même ceux dont le code n’a pas changé depuis des années.
Le correctif ne demande aucune modification de votre code : c’est une mise à jour du runtime, pas une migration d’API. Mais c’est précisément ce qui le rend facile à différer — une montée de version mineure de Node.js est souvent traitée comme de la maintenance, alors qu’elle transporte ici une correction de RCE. Les équipes qui épinglent leurs versions ou qui attendent la prochaine fenêtre de maintenance prennent un risque inutile sur une faille sans contournement.
Pour l’audit, deux réflexes suffisent. D’abord, inventoriez vos versions : node -v sur chaque service, et repérez tout ce qui tourne en 20.x ou antérieur. Ensuite, élargissez la recherche à tout ce qui embarque Brotli hors de Node.js — les proxies, les serveurs web et les outils qui font leur propre décompression doivent appliquer les correctifs Brotli 1.2.1, 1.1.1 et 1.0.10. Une faille de décompression ne respecte pas vos frontières de langage : elle traverse tout ce qui accepte du Brotli malformé en entrée.
Verdict
Mettez à jour Node.js vers 22.23.4, 24.22.1 ou 26.12.1 sans attendre. La faille Brotli n’a pas encore d’exploit fiable en conditions réelles, mais elle n’a aucun contournement : une application qui ne peut pas migrer immédiatement n’a aucune parade interne, et les deux contournements TLS ainsi que le cache d’entropie de CVE-2026-106074 sont exploitables dès aujourd’hui sur des configurations courantes. Si vous tournez sous Node.js 20.x ou antérieur, planifiez la migration vers une ligne supportée : vous n’aurez ni le correctif Brotli ni le blocage eMudhra. Si vous opérez une plateforme qui exécute du Node.js pour ses clients, suivez l’exemple de Vercel : des règles de pare-feu appliquées dès le 21 octobre bloquent l’attaque en entrée, mais elles ne couvrent pas les réponses Brotli récupérées depuis d’autres serveurs et ne remplacent pas la mise à niveau. La compression n’est plus un détail d’optimisation — c’est une surface d’attaque, et elle se corrige en montant de version.