10 vulnérabilités CVE liées à Node.js, une faille RCE dans Brotli et que faire si votre version est en fin de vie

En bref

Aller directement à la version longue ↓

Ce qui s'est passé : le 21 octobre 2026, Node.js a publié des mises à jour de sécurité pour ses trois branches prises en charge, à savoir les versions 22.x, 24.x et 26.x, une semaine après avoir émis une pré-alerte. Dix vulnérabilités (CVE) ont été identifiées, dont quatre classées « élevées ». Aller à cette section →

Ce qu’entraîne la plus grave de ces failles : CVE-2026-111497 correspond à une écriture hors limites dans le décodeur Brotli intégré à Node.js ; selon l’avis de sécurité, cette faille permet l’exécution de code à distance. Tout processus exécuté sur une version non corrigée qui décompresse des données Brotli contrôlées par un attaquant est exposé, et il n’est pas nécessaire que votre code appelle directement Brotli pour que cela se produise. Aller à cette section →

À quel point la situation est-elle grave, en réalité ? : La première démonstration publique de faisabilité n'a permis d'aboutir à l'exécution de code que sur une version délibérément affaiblie, ce qui a donné l'impression que la situation était moins urgente que ne le laissait entendre le libellé de l'avis de sécurité. C'est alors que la « red team » d'Imperva a publié Node2Shell, illustrant l'exécution de code sur l'image officielle de Node.js 24.22.0 via fetch() et l'analyse des requêtes Express 5. Aucune exploitation dans la nature n'avait été signalée au 22 octobre. Aller à cette section →

Qui est concerné : toutes les versions 22.x, 24.x ou 26.x antérieures à la version corrigée de leur branche, ainsi que les branches en fin de vie pour lesquelles Node.js ne publie plus de correctifs. Le tableau des CVE ci-dessous indique quels CVE affectent quelle branche. L'avis réitère son avertissement habituel selon lequel les versions en fin de vie sont toujours concernées, et que Node.js 20, 18, 16, 14 et 12 ne reçoivent aucun correctif de la part de l'amont. Aller à cette section →

État des lieux : des correctifs en amont sont disponibles pour les versions 22, 24 et 26. Le WAF de Vercel bloque les voies d’attaque entrantes pour les projets hébergés sur sa plateforme, mais ne couvre pas les réponses que votre code récupère depuis d’autres sources. Les versions d’ELS for Runtimes destinées aux lignes de produits concernées arrivées en fin de vie devraient être disponibles dans les prochaines 24 à 48 heures.

À faire aujourd’hui : appliquez les correctifs aux lignes prises en charge, transférez celles en fin de vie vers une version ELS stable dès que celle correspondant à votre ligne sera disponible, puis redémarrez l’ensemble du système, car un processus en cours d’exécution conserve l’ancien décodeur en mémoire. Pour voir ce qui est en cours d’exécution actuellement :

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

Aller à cette section →

La plupart des interventions de sécurité liées à Node.js se font à un niveau supérieur. Dependabot ouvre une pull request, npm audit Tout redevient calme, et personne ne s'attarde une seconde sur le code binaire sur lequel tout fonctionne. Or, le moteur d'exécution comporte lui aussi ses propres vulnérabilités CVE, et le 21 octobre, la plus grave d'entre elles s'est avérée être une corruption de mémoire dans un décodeur que votre application alimente peut-être directement depuis Internet.

Les 22, 24 ou 26, la correction est ennuyeuse. On met à jour la version du patch, on déploie la flotte, et on passe à autre chose.

La situation devient nettement moins ennuyeuse lorsqu’une partie du parc est encore sous Node.js 18 ou 20, soit parce qu’un module natif ne peut pas être compilé sur une version plus récente, soit parce que la migration vers un nouveau framework ne cesse d’être repoussée d’un trimestre à la fois. Ces versions intègrent un décodeur Brotli antérieur au correctif et ne reçoivent aucun des correctifs. La majeure partie de cet article porte sur ce décalage.

Comme à son habitude, le projet a donné une semaine de préavis. Le 14 octobre, Antoine du Hamel a publié une pré-alerte sur la liste oss-security, indiquant que les nouvelles versions 22, 24 et 26 seraient disponibles le 21 octobre ou peu après, le niveau de gravité le plus élevé étant « Élevé ». Aucun nom de composant ni numéro CVE n'a été mentionné, ce qui est habituel pour Node.js. Les versions ont été publiées dans les délais prévus.

Le titre est « CVE-2026-111497 ». L'avis attribue la découverte à Khai Tran et Sylvie Mayer, d'OpenAI Codex Security, et la correction à Matteo Collina et Antoine du Hamel. Quelques premiers articles indiquaient que Collina avait découvert la faille, mais l’avis de sécurité le mentionne parmi les auteurs du correctif. Le correctif lui-même est une sélection de la modification 0ed4268a du code source de Brotli, qui porte le message très sobre : « Détecter et signaler plus tôt les flux non valides. »

Le moment choisi pour cette modification est étrange. Selon The Hacker News, la modification a d’abord été intégrée au code source de Brotli en février 2026, mais elle n’a été incluse dans une version de sécurité qu’à partir du 21 octobre, date de sortie des versions 1.2.1, 1.1.1 et 1.0.10 de Brotli. Ainsi, un correctif pour un bug lié à la sécurité de la mémoire est resté dans un dépôt public pendant des mois, et c’est un outil de sécurité basé sur l’IA qui est à l’origine de cette découverte. Attendez-vous à voir ce genre de situation se reproduire de plus en plus souvent, et à ce que le délai entre un commit en amont non annoncé et un exploit fonctionnel ne cesse de se raccourcir.

Les trois autres vulnérabilités de gravité élevée concernent toutes la gestion des noms. CVE-2026-106069 permet à un certificat TLS de passer la vérification du nom d'hôte lorsque celui-ci ne correspond qu'approximativement à une adresse IP. CVE-2026-105483 est une faille distincte qui fonctionne lorsque l’adresse IP est écrite en chiffres de pleine largeur. Celle-ci n’affecte que les versions 24.x et 26.x, et The Hacker News souligne que le commit qui la corrige décrit le bug comme étant de faible gravité et difficile à exploiter, alors même que l’avis de sécurité lui attribue un niveau de gravité « élevé ». CVE-2026-105482 se trouve dans dns.resolve(), où un nom contenant un octet NUL pouvait être tronqué, de sorte que le nom validé par votre code et celui réellement interrogé n'étaient pas identiques. Les versions corrigées rejettent d'emblée les octets NUL dans les données d'entrée du résolveur.

Les éléments « Moyen » et « Faible » sont plus restreints, mais n’en restent pas pour autant sans importance. Parmi ceux-ci, le CVE-2026-106074 mérite d’être signalé à tous ceux qui distribuent des interfaces CLI ou des outils sous forme d’applications exécutables autonomes. Les caches d’entropie derrière crypto.randomUUID() et crypto.randomInt() étaient enregistrées dans des instantanés de démarrage et des fichiers SEA, de sorte que chaque processus lancé à partir du même binaire produisait les mêmes valeurs « aléatoires ». Tout ce qui utilise ces UUID comme jetons ou nonces mérite d'être examiné.

Ces versions mettent également à jour c-ares, undici et les certificats CA intégrés sur les trois branches, OpenSSL sur les versions 22.x et 24.x, ainsi que SQLite sur la version 22.x. Le changement de certificats est la surprise de cette mise à jour. Node.js utilise la liste racine de Mozilla mais n’effectue aucune vérification de révocation par défaut ; ainsi, les chaînes basées sur les huit certificats intermédiaires eMudhra signalés comme compromis ce mois-ci continuaient d’être validées jusqu’à cette version. Les versions corrigées intègrent une liste noire compilée de ces clés, contenant les mêmes hachages que ceux fournis par Go dans son propre correctif. Deux mises en garde s’imposent : les sessions TLS reprises depuis avant la mise à jour ne sont pas revérifiées avant l’expiration de leur délai, et les versions en fin de vie ne bénéficient pas du tout de ce blocage.

Node.js ne décode pas le format Brotli de lui-même. Un élément de votre processus doit en faire la demande, et de nombreux éléments le font sans que vous vous en rendiez compte.

Le trafic sortant est le plus important. La fonctionnalité intégrée fetch() décompresse les réponses contenant Content-Encoding: br automatiquement, et il n’existe aucune option permettant de désactiver cette fonctionnalité. Les versions actuelles d’axios, de node-fetch et de got fonctionnent de la même manière par défaut. Ainsi, tout service qui interroge des URL qu’il ne contrôle pas est concerné : un expéditeur de webhooks, un worker de prévisualisation de liens, un scraper, un agent IA récupérant des pages web pour les intégrer dans une invite. Vercel’s bulletin ajoute une autre piste qu'on a tendance à négliger. Next.js en auto-hébergement ne bloque pas les réponses Brotli lors de l'optimisation des images ; la solution consiste donc à mettre à jour Node.js, sans modifier la configuration de Next.js.

L'Inbound constitue la deuxième voie. Les analyseurs de corps de requête d'Express 5, via body-parser 2.x, décompressent par défaut les corps de requête Brotli ; ainsi, une API utilisant express.json() décompressera un corps Brotli qu’il n’a jamais demandé. Le parseur de corps 1.x d’Express 4 ne prend pas en charge les corps Brotli et les rejette avec un code d’erreur 415. Un simple http Le serveur ne décode pas le corps des requêtes simplement en les recevant. Il existe ensuite la voie directe, où le code appelle zlib.brotliDecompress() ou createBrotliDecompress() sur les fichiers mis en ligne, les archives ou les éléments mis en cache.

Une méthode rapide pour hiérarchiser les priorités. Tout service Express 5 accessible depuis Internet, ou tout service effectuant des requêtes vers des URL arbitraires, doit être corrigé dès aujourd’hui. Un service Express 4 qui communique uniquement avec des backends dont vous êtes propriétaire, sans middleware de décompression personnalisé ni connexion directe zlib Brotli fait appel à des données externes et peut donc figurer un peu plus bas dans la liste. Il faut tout de même procéder à la mise à jour cette semaine, car les neuf autres vulnérabilités CVE ne dépendent pas de la version d'Express que vous utilisez. L'avis de sécurité ne propose aucune solution de contournement. Configuration inflate: false concernant les analyseurs de corps de message, la désactivation de la décompression dans Axios ou GOT, ou le rejet Content-Encoding: br le recours au proxy peut réduire l'exposition pendant quelques heures, mais fetch() n'a pas de bouton d'arrêt et aucune de ces mesures ne constitue une solution.

L'affaire a pris une tournure grave très rapidement. Une démonstration publique de faisabilité a été publiée le 22 octobre et, selon The Hacker News, elle n'a permis l'exécution de code que sur une version de test délibérément affaiblie. Sur une version standard, son auteur a signalé un plantage et une lecture limitée de la mémoire. Il aurait été facile de se contenter de lire cela et de reporter le ticket au sprint suivant.

Le même jour, la « red team » d’Imperva a publié Node2Shell. Sur des machines neuves exécutant l'image officielle Node.js 24.22.0 pour Linux arm64, sans débogueur ni binaire instrumenté, les données Brotli transmises sous forme de réponse récupérée ou de corps de requête ont permis à l'application d'exécuter le code fourni avec ces données. Ils ont reproduit ce phénomène via fetch() et dans les versions d'Express allant de 5.0.0 à 5.3.0 avec le raw() et json() analyseurs syntaxiques. Les mêmes données d'entrée ont été rejetées par l'adresse 24.22.1. Il a fallu plusieurs tentatives pour configurer leur système, et ils n'ont testé que l'architecture arm64 ; ce n'est donc pas une solution prête à l'emploi, mais on est loin de pouvoir dire que « ça ne fonctionne qu'en laboratoire ».

Si le triage a classé ce cas sans suite sur la base de la première preuve de concept, rouvrez-le. Imperva souligne également que les arrêts inattendus de processus lors de la décompression peuvent aider à hiérarchiser l’enquête, bien que ni les plantages ni les erreurs de décodage ne constituent à eux seuls un signe fiable d’exploitation. Au 22 octobre, aucune exploitation en milieu réel n’avait été signalée, et la vulnérabilité CVE-2026-111497 ne figure pas dans le catalogue des vulnérabilités connues pour être exploitées de la CISA.

Les lignes en amont ne se touchent pas

Les avis de sécurité concernant Node.js comportent un avertissement récurrent, et celui-ci le réitère. Les versions en fin de vie sont toujours concernées lorsqu’une mise à jour de sécurité est publiée. Il s’agit d’une déclaration de principe, et non d’un résultat de test spécifique à chaque CVE. Ce qui est certain, c’est que le correctif Brotli n’a été intégré à Node.js que le 21 octobre ; aucune version en amont en fin de vie ne l’inclut donc. Node.js 20 a atteint sa fin de vie le 30 avril 2026, la version 18 le 30 avril 2025, la version 16 le 11 septembre 2023, la version 14 le 30 avril 2023 et la version 12 le 30 avril 2022. Aucune de ces versions ne bénéficiera d’une mise à jour à cet effet. Vercel s’est également montré très clair à ce sujet. Les projets hébergés sur sa plateforme et toujours liés à Node.js 20 doivent passer à la version 22 ou 24 et être redéployés, car la version 20 ne recevra pas ce correctif.

Depuis quand ce bug Brotli existe-t-il ? Brotli est intégré à Node.js depuis les versions 10.x et 11.x, et l'équipe du projet Brotli a appliqué ce correctif jusqu'à la branche 1.0. Cela indique clairement que la logique de décodage vulnérable est ancienne, et qu'il ne s'agit pas d'un problème apparu au printemps dernier. Les versions de Node.js 16 et antérieures ne disposent pas d'une variable globale fetch(), mais Axios et Got ont tout de même renvoyé des réponses Brotli vers le même décodeur zlib, et directement zlib Les appels fonctionnent de la même manière sur toutes les lignes.

Les installations qui posent problème sont rarement celles que l’on associe généralement à des serveurs Node.js. Un conteneur de compilation bloqué sur la version 16 de Node.js parce qu’un module complémentaire de traitement d’images ne se compile plus sur la version 18. Un outil d’administration interne que quelqu’un a déployé sous la forme d’un binaire unique en 2022. Un appareil d’un fournisseur dont la console web fonctionne sous Node 14. Imaginez une équipe chargée des paiements disposant de 40 services sous Node 18, bloqués à ce niveau par une seule dépendance dont le responsable de maintenance a quitté ses fonctions, et qui lit un avis de vulnérabilité RCE sans correctif joint. Personne ne va migrer 40 services d’ici vendredi.

C’est cette lacune que comble le service ELS pour les environnements d’exécution. TuxCare fournit des correctifs de sécurité pour les versions de Node.js ayant atteint leur fin de vie; ainsi, dès que la version de sa gamme est disponible, un service verrouillé sur la version 18 reçoit les correctifs du mois sous forme de mise à jour du paquet, plutôt que de devoir procéder à une migration d’urgence. La migration reste toutefois nécessaire, et les dates de fin de vie de Node.js ne changent pas. Avec ELS, elle s’effectue selon un calendrier choisi par votre équipe, et non selon celui imposé par un avis de sécurité.

La documentation « ELS for Runtimes » répertorie les versions de Node.js allant de la 12 à la 26 par système d'exploitation ; d'autres versions et architectures sont disponibles sur demande. Pour en savoir plus sur l'utilisation de Node.js après la fin de vie, consultez ce guide consacré au support étendu de Node.js après la fin de vie.

Voici ce que la documentation mentionne actuellement au titre du support actif :

Les versions sont disponibles pour x86_64 sur tous les systèmes d’exploitation pris en charge, et pour aarch64 (arm64) sur Debian 12, Debian 13 et Alpine 3.23 et versions ultérieures. Les versions arm64 revêtent une importance particulière cette semaine, car la démonstration d’exécution de code d’Imperva a été réalisée sur arm64.

Les paquets de distribution fonctionnent un peu différemment. Certaines versions, notamment les paquets Debian et Ubuntu ainsi que Homebrew, utilisent une bibliothèque Brotli partagée au lieu de celle fournie avec Node.js. Dans ce cas, suivez les mises à jour de sécurité de la bibliothèque Brotli fournie par votre gestionnaire de paquets. La vérification se fait en une seule ligne :

ldd "$(command -v node)" | grep -i brotli

La présence de « libbrotli » dans la sortie indique que le binaire utilise une bibliothèque Brotli partagée. L'absence de correspondance suggère qu'il s'agit d'une copie intégrée ou liée statiquement, ce qui correspond à la manière dont sont distribuées les versions officielles de nodejs.org ; toutefois, cette commande ne permet pas à elle seule de le confirmer. Vérifiez donc les informations relatives à votre paquet ou la configuration de compilation si cela vous importe. ldd est réservé à Linux. Sous macOS, où Homebrew est installé, otool -L "$(command -v node)" | grep -i brotli fait la même chose.

Procurez-vous ELS pour Runtimes dès aujourd'hui →

Commencez par faire l'inventaire, car la liste est toujours plus longue que prévu. Les gestionnaires de versions comme nvm et Volta placent les binaires dans les répertoires personnels, tandis que les paquets de distribution les placent dans /usr/bin, et les versions d'ELS sont compilées sous /opt/alt/ avec un script d'activation par version. Ces deux boucles Bash affichent chaque node dans votre PATH actuel, alors toutes les versions ELS situées sous /opt/alt/, avec la version indiquée par chacun :

type -ap node | while read -r n; do echo "$n $("$n" -v)"; done
for e in /opt/alt/alt-nodejs*/enable; do [ -f "$e" ] && ( . "$e" && echo "$e $(node -v)" ); done

Vous disposez ainsi d'un inventaire de départ, qui ne correspond pas nécessairement à ce qu'utilise chaque service. Les unités systemd, les configurations PM2, les exécuteurs CI et les images de base des conteneurs peuvent chacun pointer vers un binaire différent ; veillez donc à les vérifier également. Sur les systèmes basés sur RPM, les versions d'ELS sont mises à jour avec yum update 'alt-nodejs*', et les instructions relatives aux fichiers DEB et APK figurent sur la même page de documentation.

Ne vous fiez pas aux chaînes de version concernant le correctif Brotli dans les versions en amont. Node.js a intégré le correctif de manière sélective sans augmenter la version de Brotli, donc process.versions.brotli Il semble identique avant et après. Cette version a mis en évidence une nouvelle constante zlib présente dans les binaires corrigés en amont, mais absente des binaires non corrigés :

node -p "'BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH' in require('zlib').constants"

true signifie que le décodeur fixe est présent. Cette vérification n'est fiable que pour les versions officielles en amont ; pour les versions de distribution ou ELS, veuillez donc vous référer à l'avis du fournisseur. Le projet lui-même npx is-my-node-vulnerable C'est également pratique pour les installations en amont, mais comme ce système se base sur les numéros de version, une version rétroportée peut sembler vulnérable alors qu'elle ne l'est pas.

Redémarrez ensuite : c'est cette étape qui est généralement omise. Un processus Node.js en cours d'exécution conserve l'ancien décodeur jusqu'à sa fermeture, et un conteneur le conserve jusqu'à ce qu'il soit redéployé à partir d'une image reconstruite sur une base corrigée. Les fichiers SEA et les instantanés de démarrage doivent être reconstruits avec le runtime corrigé, et pour la vulnérabilité CVE-2026-106074, cette reconstruction constitue le correctif. Relancez la commande ps Commande figurant en haut de cet article : vérifiez tous les processus Node.js lancés après l'application de la mise à jour. Les applications à exécutable unique et les binaires renommés n'apparaîtront pas dans cette liste ; vérifiez-les donc en fonction du nom du service.

Enfin, ne clôturez pas le ticket sur la base d’une comparaison de versions effectuée par un scanner. Une version rétroportée peut toujours indiquer sa version en amont d’origine. Lorsque vos outils le permettent, alimentez-les avec les données de sécurité lisibles par machine de TuxCare pour Node.js, qui incluent les avis CSAF, et conservez une trace du paquet installé, de l’avis auquel il répond et du processus qui gère effectivement le trafic. C’est ce qu’un auditeur vous demandera.

Pourquoi une faille d'exécution a des conséquences différentes

Un runtime est lui aussi une dépendance, et dès lors que plus personne ne publie de correctifs pour celui-ci, chaque nouvelle vulnérabilité du noyau reste non corrigée tant que ce runtime reste en production. Des équipes qui n’oseraient jamais utiliser une version de Lodash datant de deux ans n’hésitent pas à exécuter leur code sur une version de Node.js qui a cessé de bénéficier de correctifs de sécurité en 2025.

Cette semaine a également montré à quel point le temps disponible pour s'organiser est limité. Sept jours entre la pré-alerte et la publication, une démonstration publique de faisabilité le lendemain, un exploit fonctionnel contre l'image par défaut le jour même, et des correctifs qui concernent exactement trois versions. « Mettre à jour au trimestre prochain » est un excellent plan pour le trimestre prochain. Mais ce n'est absolument pas un plan pour cette semaine.

Appliquez donc dès maintenant les correctifs aux lignes prises en charge et redémarrez les services qui doivent l'être. Pour les lignes Node.js que l'amont a laissées de côté, transférez-les vers une version ELS corrigée dès que celle correspondant à votre ligne sera disponible ; en attendant, limitez leur exposition aux données Brotli non fiables, puis planifiez la migration dans votre calendrier.

Procurez-vous ELS pour Runtimes dès aujourd'hui →

Comment ces événements se sont déroulés

Sources

Les sources utilisées pour cet article comprennent l’avis de sécurité Node.js du 21 octobre 2026, les notes de mise à jour des versions 22.23.4 et 24.22.1, l’alerte préliminaire publiée sur oss-security, le calendrier des mises à jour de Node.js, le commit de correction de google/brotli, la pull request de la liste noire eMudhra, le bulletin de sécurité de Vercel, l’étude Node2Shell d’Imperva, l’article de The Hacker News, le catalogue KEV de la CISA, le site is-my-node-vulnerable ainsi que la documentation ELS for Runtimes de TuxCare pour Node.js et les données de sécurité lisibles par machine.