Ce que corrige la publication Node.js d'octobre 2026
Node.js a publié le 21 octobre 2026 des mises à jour pour les lignes 22.x, 24.x et 26.x. Parmi les dix vulnérabilités corrigées, CVE-2026-111497 est classée High par le projet : le décodeur Brotli embarqué écrit au-delà d'un tampon interne lorsqu'il reçoit des données malformées. Concrètement, un changement de bloc invalide était signalé comme un simple besoin de données supplémentaires, et non comme une erreur de format définitive. Le décodeur en flux continuait alors d'ajouter des octets dans un tampon interne de huit octets. Les conséquences possibles vont du plantage du processus à la divulgation de mémoire, puis à l'exécution de code à distance avec les droits du processus Node.
Sur la gravité, deux lectures coexistent. Node.js dit High ; Google, comme autorité de numérotation, attribue un score CVSS v4 de 9,2, d'après l'analyse de Rapid7. Au 26 octobre 2026, Rapid7 ne connaît aucune exploitation dans la nature, et la faille ne figure pas au catalogue CISA des vulnérabilités exploitées. La faille n'est donc pas exploitée à ce jour, d'après Rapid7 : c'est une fenêtre pour patcher à froid, pas une raison d'attendre.
Versions touchées et versions corrigées
Faites défiler le tableau
| Cas de figure | Statut | Action |
|---|---|---|
| Node.js 22.x | Affectée avant 22.23.4 | Passer en 22.23.4 |
| Node.js 24.x | Affectée avant 24.22.1 | Passer en 24.22.1 |
| Node.js 26.x | Affectée avant 26.12.1 | Passer en 26.12.1 |
| Node.js 20.x et autres lignes en fin de vie | À traiter comme affectées, sans correctif | Migrer vers 22.x ou 24.x |
| Image Docker node:<ligne> | Affectée tant que l'image n'est pas reconstruite | Reconstruire avec --pull --no-cache |
| Binaire Node empaqueté dans un outil (Electron, exécutable packagé) | Dépend de la version embarquée | Mettre à jour l'outil lui-même |
| Autre logiciel qui embarque le même décodeur Brotli | Selon l'éditeur | Lire son propre avis |
Êtes-vous exposé : le critère qui tranche
Avoir un Node vulnérable ne suffit pas à être attaquable. L'avis de Node.js vise une application qui décompresse avec node:zlib des données Brotli fournies par un attaquant, via zlib.createBrotliDecompress ou zlib.brotliDecompress. Rapid7 précise que la seule présence du décodeur n'établit pas l'exposition : tout dépend de ce que l'application décompresse. Ne concluez pourtant pas trop vite à l'absence de risque, car le Brotli passe souvent par des bibliothèques que vous n'avez pas écrites.
Le lien avec l'en-tête Content-Encoding: br est notre lecture, pas une affirmation de l'avis. Dans le code source public, le fetch intégré à Node (undici) décode les réponses br avec zlib.createBrotliDecompress, l'adaptateur HTTP d'axios prévoit le même décodage, et le code actuel de body-parser fait de même pour les corps de requêtes entrantes. Deux flux sont donc à examiner : ce que votre application reçoit des clients, et ce qu'elle récupère auprès de serveurs tiers. Vous pouvez le vérifier dans votre propre arbre de dépendances, avec les commandes de l'inventaire plus bas.
Où du Brotli non fiable peut entrer dans une application Node
- Requêtes entrantes compressées — une API Express ou un serveur maison qui utilise body-parser décompresse un corps
Content-Encoding: brenvoyé par n'importe quel client. - Réponses de services tiers —
fetchou axios qui appelle une API, un flux RSS, un webhook ou une page à prévisualiser : c'est le serveur distant qui choisit l'encodage de la réponse. - Rendu côté serveur — une application Next ou Nuxt qui récupère des données distantes pendant le rendu passe par ces mêmes appels sortants.
- Proxys et passerelles écrits en Node — un composant qui décompresse pour inspecter ou transformer le contenu en transit ouvre les deux flux à la fois.
- Traitement de fichiers — un service qui accepte des fichiers ou archives compressés en Brotli et les ouvre avec
zlib.brotliDecompress. - Outils de build et de CI — scripts de déploiement et jobs qui téléchargent des artefacts : moins exposés, mais ils utilisent le même binaire et se patchent au même moment.
- Aucun chemin identifié — priorité plus basse, pas nulle : une dépendance ajoutée plus tard suffit à créer l'exposition, et la publication corrige aussi d'autres failles.
Inventorier le parc en quinze minutes
Relever la version de chaque machine
node -vwhich -a node
Plusieurs binaires cohabitent souvent : celui du système, celui de nvm, celui d'un conteneur.which -ales liste tous, et le premier n'est pas toujours celui que le service utilise.Trouver le binaire réel de chaque processus
ps -eo pid,user,args | grep -E '[n]ode|[p]m2'sudo readlink -f /proc/<pid>/exe
La deuxième commande, lancée avec le PID relevé, donne le chemin exact du binaire qui exécute le processus. C'est la seule réponse fiable sur une machine qui porte plusieurs installations de Node.Interroger les conteneurs
docker psdocker exec <conteneur> node -vdocker images | grep node
Un conteneur en cours d'exécution ne se corrige pas tout seul : il garde l'image avec laquelle il a démarré, même si une image plus récente existe sur la machine.Chercher les appels directs dans votre code
grep -rEn "createBrotliDecompress|brotliDecompress" --include=*.js --include=*.mjs --include=*.ts . --exclude-dir=node_modules
Chaque ligne trouvée est un point où votre code décompresse du Brotli. Regardez d'où viennent les données : un fichier que vous avez produit n'a pas le même risque qu'un corps de requête.Chercher les bibliothèques qui décompressent à votre place
grep -rlE "createBrotliDecompress" node_modules --include=*.jsnpm ls body-parser axios undici
La première commande liste les paquets installés qui appellent le décodeur ; la seconde montre quelles versions de body-parser, axios et undici sont présentes dans le projet. Lancez-les dans chaque dépôt, pas seulement dans le plus récent.Repérer les binaires empaquetés
Les outils qui embarquent leur propre Node (applications Electron, exécutables packagés) ne sont pas couverts par
apt. Relevez leur version dans leur documentation et vérifiez si l'éditeur a republié une version corrigée.Consigner le résultat dans un tableau
Une ligne par processus : machine, client, ligne Node, version, chemin Brotli identifié ou non. Ce tableau décide de l'ordre de traitement, et il servira de preuve une fois la mise à jour faite.
Dans quel ordre traiter le parc
Un parc de sites clients, de versions et d'installations hétérogènes, ne se met pas à jour d'un seul geste, et ce n'est pas nécessaire. Traitez d'abord les serveurs exposés à Internet qui reçoivent des corps compressés ou qui appellent des services tiers : rendu côté serveur, passerelles, proxys, API publiques. Viennent ensuite les applications internes et les workers, puis les outils de build. Les applications sur Node 20 forment un cas à part : aucun correctif n'existera pour elles, la seule sortie est la migration vers 22.x ou 24.x, à planifier avec le client plutôt qu'à improviser. Procédez par paliers de quelques machines, et vérifiez chaque palier avant de passer au suivant.
Mettre à jour selon le mode d'installation
Paquet apt (dépôt NodeSource ou distribution)
apt-cache policy nodejssudo apt-get updatesudo apt-get install --only-upgrade nodejsnode -v
Lisez d'abord la source affichée parapt-cache policy: le dépôt doit pointer sur la bonne ligne (node_22.x ou node_24.x). Un dépôt resté sur une ligne en fin de vie ne proposera jamais le correctif. Un paquet de distribution peut aussi porter un autre numéro : comparez avec l'avis de votre distribution.nvm
nvm install --reinstall-packages-from=current 22nvm alias default 22nvm use 22node -v
La commande installe la dernière 22.x disponible ; contrôlez quenode -vaffiche 22.23.4 ou plus. Faites de même avec 24 si c'est votre ligne. Les services lancés par un autre utilisateur ont leur propre nvm.Docker
Changez le tag de la ligne
FROM, par exempleFROM node:22ouFROM node:24avec la variante que vous utilisez déjà, puis :docker build --pull --no-cache -t monapp:corrige .docker compose up -d
L'option--pullretire la dernière version de l'image de base,--no-cacheévite de réutiliser une couche construite avec l'ancien Node. Le conteneur en cours n'est remplacé qu'au redéploiement.pm2
pm2 restart allpm2 update
Après le remplacement du binaire,pm2 restartrelance les applications ;pm2 updaterafraîchit le démon pm2 en mémoire. La documentation de pm2 ajoute que, après une mise à jour de Node, il faut aussi rafraîchir le script de démarrage :pm2 unstartuppm2 startuppm2 saveService systemd ou autre superviseur
sudo systemctl restart <service>
Redémarrez chaque service un par un, en contrôlant son journal et sa route de santé avant de passer au suivant. Sur une application derrière un répartiteur, sortez la machine du pool le temps du redémarrage.
Un processus déjà lancé garde l'ancien Node
Remplacer le binaire ne corrige pas les processus en cours : ils conservent l'ancienne version en mémoire jusqu'au redémarrage. Un node -v correct sur la machine ne prouve donc rien sur un service lancé la veille. Après chaque redémarrage, vérifiez depuis le processus lui-même : pm2 jlist ou pm2 show <nom> pour la version de Node utilisée, ou process.version exposé dans votre route de santé.
Si la mise à jour est impossible aujourd'hui
Node.js n'a publié aucun contournement : la seule parade éditeur est la version corrigée. Rapid7 recommande, à défaut, de restreindre ou de désactiver les chemins applicatifs qui décompressent du Brotli non fiable. Voici ce que cela donne en pratique. Les points suivants sont des mesures de réduction du risque que nous proposons, pas des recommandations de l'éditeur, et aucun ne remplace le correctif.
Côté requêtes entrantes, refusez le Brotli au niveau du reverse proxy, par exemple dans nginx : if ($http_content_encoding ~* br) { return 415; }. Testez avec nginx -t avant le rechargement, et vérifiez qu'aucun de vos clients légitimes n'envoie de corps en br. Côté réponses de tiers, n'annoncez que les encodages utiles avec l'en-tête Accept-Encoding: gzip, et limitez les destinations autorisées de vos appels sortants. Cette dernière mesure est partielle : un serveur malveillant peut répondre en br sans l'avoir été demandé, et le décodeur suit l'en-tête de la réponse. Sur Vercel, des règles WAF bloquent le flux entrant mais pas les réponses récupérées par vos fonctions ; redéployer avec une version corrigée reste nécessaire.
Ne corrigez pas que le Brotli
La même publication corrige neuf autres failles. Parmi elles figurent deux contournements de vérification de nom d'hôte TLS de gravité élevée, CVE-2026-105483 et CVE-2026-106069, ainsi que CVE-2026-105482, une troncature des noms d'hôte contenant un caractère NUL dans les résolutions DNS, également classée High. Elles ne touchent pas toutes les mêmes lignes : CVE-2026-105483 concerne les lignes 26.x et 24.x, les deux autres concernent aussi 22.x. Une application qui valide des certificats TLS pour ses appels sortants a donc de bonnes raisons de passer à la version corrigée sans attendre d'avoir tranché la question du Brotli.
Pour une agence : un correctif par ligne, pas par site
Quand on porte des dizaines de sites, la commande de mise à jour prend une minute ; le temps part ailleurs. Il faut retrouver quelle machine fait tourner quelle version chez quel client, puis obtenir un créneau de redémarrage. Tenez donc un registre vivant, alimenté par l'inventaire ci-dessus : à la prochaine faille, un simple filtre sur la ligne de Node donne la liste des sites à traiter. Moins il existe de variantes dans le parc, moins il y a de cas à gérer à la main, et l'hébergement revendeur répond à cette logique : une interface unique pour le portefeuille et des renouvellements regroupés, là où une collection de serveurs disparates multiplie les accès à suivre. Les applications bloquées sur Node 20 demandent un traitement séparé : le guide de migration lié sous cet article permet de ne pas découvrir l'absence de correctif le jour de la faille suivante.
La documentation officielle
Avis de sécurité Node.js d'octobre 2026 : https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
Analyse de Rapid7 sur CVE-2026-111497 : https://www.rapid7.com/blog/post/etr-cve-2026-111497-critical-out-of-bounds-write-in-the-node-js-brotli-decoder/
Bulletin de Vercel : https://vercel.com/kb/bulletin/node-js-security-advisory
Documentation du module zlib : https://nodejs.org/api/zlib.html
Documentation de nvm : https://github.com/nvm-sh/nvm
Mise à jour de pm2 : https://pm2.keymetrics.io/docs/usage/update-pm2/
Options de docker build : https://docs.docker.com/reference/cli/docker/buildx/build/
