Node.js, correctifs d’octobre 2026 : RCE Brotli et contournements TLS

Le 21 octobre 2026, le projet Node.js a publié les versions 22.23.4, 24.22.1 et 26.12.1. Elles corrigent dix vulnérabilités, dont quatre de gravité élevée. La plus grave, CVE-2026-111497, est une écriture hors limites dans le décodeur Brotli de Node : des données compressées malformées peuvent corrompre la mémoire, et l’hébergeur Vercel indique que des chercheurs s’en sont servis pour lire la mémoire du processus et exécuter des commandes avec les droits du processus Node.js. Deux autres failles de gravité élevée permettent à un certificat TLS de passer la vérification du nom d’hôte alors qu’il ne le devrait pas. Node.js 20 et 25 sont en fin de vie et ne reçoivent aucun correctif.

Quelles versions sont corrigées

Les dix failles

Les versions mettent aussi à jour des composants intégrés : c-ares, Undici, la liste des autorités de certification de confiance (avec le retrait de l’autorité intermédiaire compromise d’eMudhra), OpenSSL sur la 24 et la 22, et SQLite sur la 22.

Qui est exposé à la faille Brotli

Node.js ne décode pas Brotli de lui-même. Vous êtes exposé lorsque votre code, ou une bibliothèque qu’il utilise, décompresse des données Brotli contrôlées par quelqu’un d’autre. Cela arrive plus souvent qu’on ne le croit :

• Le fetch() intégré décode automatiquement les réponses avec Content-Encoding: br. Un service qui récupère des URL choisies par des utilisateurs, des webhooks ou des API tierces peut recevoir une réponse malveillante.
• axios, got et node-fetch décodent eux aussi les réponses compressées par défaut.
• Express 5 (body-parser 2) décode par défaut les corps de requête Brotli : une API peut donc recevoir les données directement d’un attaquant.
• Tout appel à zlib.brotliDecompress, zlib.createBrotliDecompress ou DecompressionStream sur des fichiers téléversés ou des données tierces.

Corrigez en priorité les endroits où cela touche Internet : les API publiques qui acceptent des corps compressés, les services qui récupèrent des URL fournies par les utilisateurs et tout ce qui décompresse des fichiers téléversés.

Les failles TLS comptent surtout lorsqu’un attaquant peut obtenir, auprès d’une autorité de certification à laquelle votre client fait confiance, un certificat contenant un nom DNS en forme d’IP, et la faille DNS lorsque votre code transmet une entrée externe à dns.resolve. Selon le commit de correction, les failles TLS ne sont pas faciles à exploiter, mais la même mise à jour les corrige.

Étape 1 : trouver chaque environnement Node.js

Sous Linux, listez chaque binaire node avec sa version :

sudo find / -xdev -type f -name node -perm -u+x 2>/dev/null | while read -r n; do echo "$n: $("$n" --version 2>/dev/null)"; done

Vérifiez quel environnement d’exécution utilisent les processus en cours :

for p in $(pgrep -x node); do echo "$p $(sudo readlink -f /proc/$p/exe)"; done

Sous Docker, vérifiez chaque conteneur en cours d’exécution :

for c in $(docker ps --format '{{.Names}}'); do echo "$c: $(docker exec "$c" node --version 2>/dev/null)"; done

Vérifiez aussi les gestionnaires de versions (nvm, fnm, Volta, asdf), les runners de CI, les images de build, les applications Electron et les fonctions serverless, où la version de l’environnement est définie dans la configuration du projet.

Étape 2 : mettre à jour

Ubuntu et Debian avec les paquets NodeSource :

sudo apt update && sudo apt install --only-upgrade nodejs && node --version

Avec nvm :

nvm install 24.22.1 && nvm alias default 24.22.1

Conteneurs : remplacez l’image de base par une version corrigée, par exemple node:24.22.1-alpine ou node:22.23.4-bookworm-slim, reconstruisez et redéployez. Mettre à jour l’hôte ne change pas ce qui s’exécute dans un conteneur.

Plateformes serverless et d’hébergement : sur Vercel, les projets en 22.x et 24.x sont corrigés par Vercel, qui a aussi ajouté des règles de pare-feu contre l’attaque entrante ; les projets encore en 20.x doivent passer à la 22.x ou à la 24.x et être redéployés. Sur les autres plateformes, consultez l’avis du fournisseur et redéployez dès que l’environnement corrigé est disponible.

Les paquets des distributions, comme le paquet nodejs propre à Ubuntu, sont souvent en retard. Si node --version n’affiche pas 22.23.4, 24.22.1 ou 26.12.1 (ni un build de distribution qui cite ces CVE), utilisez les versions officielles.

Étape 3 : redémarrer et vérifier

Un processus en cours d’exécution garde l’ancien environnement jusqu’à son redémarrage. Après une mise à jour de paquet sous Linux, cette commande liste les processus node qui exécutent encore le binaire remplacé :

sudo ls -l /proc/*/exe 2>/dev/null | grep -i 'node.*(deleted)'

Redémarrez ces services (par exemple avec systemctl restart, pm2 reload all ou un nouveau déploiement) et relancez les commandes de l’étape 1.

Si vous ne pouvez pas mettre à jour aujourd’hui

Aucune de ces mesures ne remplace la mise à jour, mais elles réduisent le risque pendant quelques jours :

• Rejetez les corps de requête Brotli avant qu’ils n’atteignent l’application, par exemple dans NGINX avec if ($http_content_encoding ~* br) { return 415; }, ou dans un middleware exécuté avant les analyseurs de corps (body parsers).
• Désactivez la décompression automatique pour les requêtes vers des serveurs non fiables : decompress: false dans axios et got, compress: false dans node-fetch, ou request() d’undici, qui ne décompresse pas. Le fetch() intégré ne peut pas être désactivé.
• Exécutez la récupération d’URL fournies par les utilisateurs dans un processus séparé, avec le moins de droits possible.
• Avant de transmettre une entrée externe à dns.resolve, rejetez les noms qui contiennent un caractère NUL.

Si vous ne savez pas lesquels de vos services décodent des données non fiables, ou si vous avez besoin d’aide pour mettre à jour un système de production sans interruption, nos équipes de développement logiciel sécurisé et de sécurité managée peuvent vous aider.