Vulnérabilité Brotli de Node.js : comment les applications se retrouvent exposées et ce que les développeurs doivent vérifier

Illustration de la vulnérabilité par TechiesJournal. Les mêmes données compressées malformées sont traitées différemment par le décodeur Node.js vulnérable et par le décodeur corrigé.

Une part essentielle de la sécurité d’une application peut se trouver dans du code que ses développeurs ne touchent jamais directement. Les versions de sécurité de Node.js d’octobre 2026 montrent pourquoi comprendre le comportement de l’environnement d’exécution (runtime) compte autant que mettre à jour les dépendances de l’application.

Une réponse d’API compressée peut atteindre du code natif

Imaginez un service Node.js qui récupère des informations auprès d’une API externe. L’application envoie une requête HTTP ordinaire, reçoit une réponse compressée et traite les données renvoyées. Rien dans ce déroulement ne semble inhabituel.

Entre la réception de la réponse et l’utilisation de son contenu, le runtime peut avoir besoin de la décompresser. Si la réponse utilise Brotli, ce travail passe par un décodeur implémenté en code natif. Supposons maintenant que les données compressées soient délibérément malformées et que le décodeur les traite de façon incorrecte.

C’est le problème de sécurité derrière CVE-2026-111497, une vulnérabilité de gravité élevée divulguée avec les versions de sécurité de Node.js du 21 octobre 2026. Cette faille peut amener le décodeur Brotli intégré à Node.js à écrire en dehors d’un tampon mémoire interne. Selon l’avis officiel de Node.js, les conséquences peuvent aller du plantage du processus à la divulgation de mémoire ou à l’exécution de code à distance. Des chercheurs d’Imperva ont ensuite démontré une exécution de code à l’aide de données Brotli spécialement conçues, contre une build officielle et vulnérable de Node.js.

Pour les développeurs et les équipes d’ingénierie, la question importante n’est pas seulement de savoir si leur application utilise Node.js. Il s’agit de savoir si des données compressées non fiables peuvent atteindre le décodeur vulnérable, et si la version de Node.js qui s’exécute réellement dans leur environnement a reçu le correctif.

Node.js a publié dix correctifs de sécurité le 21 octobre

Le 21 octobre, le projet Node.js a publié des mises à jour de sécurité pour trois branches de versions prises en charge. Les branches 22.x et 24.x sont des versions à support à long terme (LTS), et 26.x est la branche Current.

La première version corrigée de Node.js pour chaque branche prise en charge

Branche de Node.js	Version de sécurité
22.x LTS	22.23.4
24.x LTS	24.22.1
26.x Current	26.12.1

L’annonce traitait dix CVE touchant la sécurité mémoire, la validation des certificats TLS, la gestion du DNS, l’aléa cryptographique, la réutilisation des connexions HTTP, le traitement des fichiers ZIP et les permissions du système de fichiers. Elle mettait aussi à jour des dépendances intégrées, dont c-ares, OpenSSL, SQLite, Undici et le magasin de certificats d’autorités de certification (CA). Le niveau de gravité le plus élevé attribué par le projet Node.js était High (élevé). Le Hong Kong Computer Emergency Response Team Coordination Centre a également publié un bulletin de sécurité le 22 octobre, qui recommande de passer aux versions corrigées.

Une vulnérabilité se distingue par ses conséquences possibles et par les éléments techniques publiés ensuite : CVE-2026-111497, qui concerne le décodeur Brotli. Le reste de la publication de sécurité compte aussi : les équipes devraient donc appliquer la mise à jour complète plutôt que de chercher à traiter une seule vulnérabilité.

Brotli est un format de compression intégré à Node.js

Quand un serveur envoie des informations sur un réseau, la compression peut réduire la quantité de données transférées. Une réponse d’API contenant du texte répétitif peut nécessiter moins d’octets une fois compressée, et l’application qui la reçoit la décompresse pour retrouver l’information d’origine. Brotli est l’un des formats de compression utilisés à cette fin ; on le reconnaît généralement à l’encodage de contenu HTTP br.

Node.js fournit la compression et la décompression Brotli par son module node:zlib. Les applications peuvent atteindre cette fonctionnalité directement, ou indirectement par des composants qui traitent des données compressées. Un développeur peut ne jamais écrire de code qui appelle explicitement une fonction de décompression Brotli, et l’application peut pourtant en utiliser une par le traitement des réponses HTTP ou par un middleware de corps de requête. Un middleware est du code qui traite une requête avant que le gestionnaire propre à l’application ne la voie.

La vulnérabilité se trouve dans le décodeur, pas dans la logique métier de l’application.

Un changement de bloc invalide permettait au décodeur d’écrire au-delà de son tampon

Un décodeur traite les données compressées selon les règles définies par le format de compression. À mesure qu’il lit l’entrée, il suit l’état du flux compressé, notamment les blocs et types de blocs valides à un moment donné. Si le flux contient une transition invalide, le décodeur doit la rejeter.

Le décodeur Brotli vulnérable ne faisait pas toujours correctement cette distinction. Selon l’avis de Node.js, un changement de bloc (block switch) invalide pouvait être traité comme si le décodeur avait simplement besoin de davantage de données en entrée. Au lieu de renvoyer une erreur de format définitive, le traitement pouvait se poursuivre. Cette mauvaise gestion de l’état permettait au décodeur en flux de continuer à ajouter des octets dans un tampon interne de huit octets, au-delà de la limite prévue.

Il s’agit d’une écriture hors limites (out-of-bounds write) : un programme écrit des données au-delà de la zone mémoire prévue pour les contenir. Un tel défaut peut corrompre la mémoire du processus. Selon les circonstances, les conséquences peuvent aller d’un plantage à une compromission de sécurité plus grave. L’avis de Node.js attribue le signalement de la faille à Khai Tran et Sylvie Mayer, chercheurs d’OpenAI Codex Security.

La correction de Brotli en amont modifie la façon dont les fonctions du décodeur détectent et propagent les erreurs de format invalide. Une transition de bloc impossible est signalée comme une erreur au lieu d’être confondue avec une demande de données supplémentaires. Concrètement, le correctif rétablit une limite importante : des données compressées invalides ne doivent pas amener le décodeur à poursuivre son traitement dans un état dangereux.

Cela ne signifie pas que toute réponse Brotli malformée aboutira à une exécution de code. Le problème, c’est qu’une catégorie particulière d’entrées malformées peut atteindre un comportement vulnérable de gestion de la mémoire.

Deux chemins peuvent amener des données Brotli non fiables jusqu’au décodeur

Il faut comprendre au moins deux chemins importants.

Un service reçoit une réponse HTTP compressée

Prenons un service backend qui récupère des données auprès d’une API tierce avec la fonction fetch() intégrée à Node.js. Le serveur distant peut renvoyer une réponse compressée avec Brotli. Lorsque le client traite cette réponse, l’opération de décodage peut atteindre l’implémentation Brotli intégrée à Node.js. Si un attaquant peut contrôler les données compressées renvoyées à l’application, le décodeur devient une surface d’attaque potentielle.

Cela ne signifie pas que toute utilisation de fetch() soit automatiquement exploitable. L’application doit recevoir une entrée compressée pertinente, et le chemin de décodage vulnérable doit être atteint. Cela montre en revanche pourquoi une requête HTTP sortante peut avoir une importance pour la sécurité. Les développeurs se concentrent souvent sur la protection des requêtes entrantes, puisque c’est là que les utilisateurs externes interagissent avec leurs applications, mais les réponses des services externes sont elles aussi des données qui franchissent une frontière de confiance.

Un service décompresse le corps d’une requête entrante

Le second chemin concerne le traitement du corps des requêtes. Les applications construites avec Express peuvent configurer un middleware pour analyser des corps de requête entrants au format JSON, texte ou brut, et certaines configurations d’analyseur peuvent décompresser des corps encodés en Brotli avant d’en transmettre le contenu au code de l’application. Dans cette situation, un client qui fournit un corps de requête compressé spécialement conçu peut être en mesure d’atteindre le même décodeur vulnérable.

Un serveur HTTP Node.js de base ne décompresse pas automatiquement chaque corps de requête Brotli au seul motif qu’il en reçoit un. Le traitement correspondant doit être activé par un middleware ou par le code de l’application. C’est pourquoi il importe davantage d’examiner le chemin réel de traitement des requêtes que de supposer que toutes les applications Express ou Node.js ont la même exposition.

Imperva a démontré une exécution de code sur une build testée

Le 22 octobre, Imperva Threat Research a publié une analyse de Ron Masas intitulée Node2Shell: From Brotli Data to Remote Code Execution. Ses chercheurs ont testé des données Brotli spécialement conçues contre des applications exécutant l’image officielle Node.js 24.22.0 pour Linux arm64. Ils ont fait état d’une exécution de code réussie dans deux scénarios applicatifs : un service qui consomme une réponse HTTP compressée par la fonction fetch() intégrée, et des applications qui traitent des corps de requête entrants compressés en Brotli avec certaines configurations d’Express 5 et de body-parser 2.

Les tests utilisaient un fichier témoin pour démontrer que du code fourni avec les données compressées malveillantes s’était exécuté dans le processus de l’application. Point important, Imperva a indiqué que les mêmes entrées étaient rejetées par Node.js 24.22.1, sans que le fichier témoin soit créé.

Les chercheurs ont aussi fait état de limites significatives. Leur preuve de concept n’a pas réussi à chaque tentative, et ils n’ont pas testé toutes les builds de Node.js ni toutes les configurations d’application. Ces résultats étayent une conclusion précise : l’exécution de code à distance a été démontrée dans l’environnement testé, avec une build officielle et vulnérable de Node.js. Ils n’établissent pas que l’exécution de code soit fiable dans tous les environnements vulnérables, ni que des attaquants aient déjà compromis des applications en production.

Une preuve de concept fonctionnelle et une exploitation confirmée en conditions réelles sont deux formes de preuve différentes. D’après les sources examinées pour cet article le 23 octobre 2026, aucune exploitation active n’a été confirmée dans des attaques réelles.

Express est un chemin vers le décodeur, pas la cause

Utiliser Express ne rend pas, à lui seul, une application vulnérable. Les applications Express peuvent avoir des configurations de traitement des requêtes très différentes. Certains points de terminaison analysent des corps compressés, tandis que d’autres peuvent ne jamais faire appel à la décompression Brotli.

Imperva a testé certaines configurations faisant intervenir Express 5 et body-parser 2, et ses résultats démontrent que ces composants peuvent ouvrir un chemin vers le décodeur Node.js concerné. Express n’était pas la source profonde du défaut de sécurité mémoire, et cette distinction détermine la bonne remédiation. Modifier la configuration d’un middleware peut aider à réduire l’exposition à certaines entrées, mais cela ne répare pas le décodeur vulnérable à l’intérieur d’un runtime Node.js plus ancien.

Le correctif principal consiste à mettre à jour Node.js.

Les équipes devraient tout de même examiner les middlewares et le traitement du corps des requêtes, car ces composants contribuent à déterminer par où des données compressées non fiables entrent dans l’application.

Un pare-feu peut ne pas couvrir le chemin sortant

Un pare-feu applicatif web (WAF) peut inspecter, et parfois bloquer, le trafic HTTP entrant malveillant. Cela peut offrir une protection utile contre certains chemins d’attaque, en particulier lorsque l’opération vulnérable porte sur des corps de requête qui entrent dans un service public.

Reprenons l’exemple précédent d’une application Node.js qui envoie une requête sortante. Un pare-feu entrant qui protège les points de terminaison publics de l’application n’inspecte pas nécessairement la réponse compressée renvoyée par une API externe : le décodeur peut donc toujours recevoir des données non fiables par cet autre chemin. Imperva indique avoir déployé des règles WAF contre les tentatives d’exploitation qu’elle a reproduites, tout en recommandant à ses clients de mettre à jour leurs runtimes Node.js.

Ces contrôles n’ont pas le même rôle. Une règle de pare-feu peut réduire l’exposition à un trafic malveillant connu, tandis qu’une mise à jour de sécurité du runtime corrige la vulnérabilité sous-jacente. Limiter temporairement le trafic Brotli non fiable sur les chemins concernés, comme le suggère Imperva, ou filtrer d’autres trafics peut être utile pendant le déploiement des mises à jour, à condition que les équipes comprennent l’effet sur le comportement normal de l’application. Ces mesures ne doivent pas être considérées comme un substitut permanent à l’application des correctifs.

Vérifier la version en cours d’exécution, les chemins des données et les artefacts déployés

La priorité immédiate est d’établir quelles versions du runtime Node.js sont réellement déployées.

Vérifier la version de Node.js en cours d’exécution

Sur un hôte ou dans un environnement de développement :

node --version

Pour un conteneur Docker en cours d’exécution :

docker exec <container-name> node --version

Pour une image de conteneur disponible localement :

docker run --rm --entrypoint node <image-name> --version

La dernière commande suppose que l’image peut être exécutée avec ce point d’entrée et que l’exécutable Node.js se trouve dans le chemin de recherche des exécutables du conteneur. Ces vérifications identifient la version de l’exécutable Node.js invoqué. Elles ne prouvent pas, à elles seules, que l’application entière est sécurisée.

Examiner où les données compressées sont traitées

Les équipes devraient repérer les applications qui décompressent des données externes, en particulier par :

• les API Brotli de node:zlib dans Node.js
• des appels à la fonction fetch() intégrée qui consomment des réponses compressées
• un middleware de corps de requête configuré pour décompresser les corps entrants
• d’autres paquets ou composants qui utilisent, en fin de compte, le décodeur intégré

Cet examen aide à hiérarchiser l’analyse de l’exposition. Il ne doit pas retarder l’installation des mises à jour de sécurité disponibles.

Inspecter les artefacts déployés, pas seulement les fichiers source

Un dépôt peut indiquer une version récente de Node.js alors qu’une version plus ancienne subsiste dans une image de conteneur déployée. De même, un pipeline de build peut avoir été mis à jour sans que toutes les images d’application dérivées d’une ancienne image de base aient été reconstruites. Pour les systèmes conteneurisés, la remédiation devrait comprendre la reconstruction des images concernées, leur déploiement et la vérification de la version de Node.js à l’intérieur des conteneurs en cours d’exécution.

Pour les runtimes managés et les services serverless, les équipes devraient confirmer la version du runtime et l’état des correctifs indiqués par leur fournisseur, plutôt que de supposer que chaque environnement a déjà été mis à jour. Si une application s’exécute encore sur une version de Node.js qui n’est plus prise en charge, la remédiation appropriée peut exiger le passage à une branche prise en charge.

Tester l’application après la mise à niveau

Une mise à jour de sécurité du runtime peut modifier le comportement d’une application, en particulier lorsque le traitement réseau, les dépendances ou les composants natifs changent. Les équipes devraient exécuter leurs tests de non-régression habituels, vérifier les intégrations HTTP essentielles et confirmer que l’analyse des requêtes et la décompression se comportent toujours correctement avec des entrées valides. Les correctifs de sécurité doivent être appliqués rapidement, mais le déploiement doit rester maîtrisé et vérifiable.

La même publication a corrigé neuf autres vulnérabilités

Le problème Brotli est le sujet principal de cet article, mais la publication d’octobre traitait un ensemble plus large de questions de sécurité. Les autres résultats comptent, car ils touchent des hypothèses que les développeurs et les équipes plateforme peuvent faire sur le comportement du runtime.

Les autres domaines de sécurité corrigés dans la même publication

Domaine de sécurité	Vulnérabilités concernées	Pourquoi les équipes doivent s’en soucier
Validation des certificats TLS	CVE-2026-105483, CVE-2026-106069, CVE-2026-106072	Certaines représentations non standard des adresses IP peuvent conduire, dans des conditions précises, à une mise en correspondance incorrecte de l’identité du certificat.
Résolution DNS	CVE-2026-105482	Les noms d’hôte contenant des caractères NUL (octets nuls) peuvent être tronqués pendant la résolution, ce qui crée des différences entre le nom validé et le nom résolu.
Aléa cryptographique	CVE-2026-106074	Certains instantanés de démarrage (startup snapshots) et certaines single executable applications (programmes empaquetés autonomes) peuvent conserver des caches d’entropie, c’est-à-dire des valeurs aléatoires stockées, si bien que des valeurs censées être uniques ou imprévisibles se répètent d’un processus à l’autre.
Réutilisation des connexions HTTP	CVE-2026-105481	Dans certaines conditions de synchronisation, un client HTTP peut associer une réponse non sollicitée à une requête ultérieure.
Traitement des fichiers ZIP	CVE-2026-106070	Dans Node.js 26.x, un échec de validation ZIP peut entraîner le renvoi inattendu d’octets contrôlés par l’attaquant.
Permission Model du système de fichiers	CVE-2026-106071, CVE-2026-106073	Certains comportements de correspondance de chemins et d’API du système de fichiers peuvent contourner les restrictions de permissions prévues.

Ces vulnérabilités n’ont pas toutes les mêmes prérequis, la même gravité, les mêmes conséquences ni les mêmes branches concernées. Selon l’avis, CVE-2026-105483 touche 26.x et 24.x, le problème ZIP CVE-2026-106070 et le problème de caractères génériques du système de fichiers CVE-2026-106071 ne touchent que 26.x, et les autres touchent les trois branches. Par exemple, le problème d’aléa exige un comportement particulier lié aux instantanés. Il ne prouve pas que chaque appel à crypto.randomUUID() produise des valeurs prévisibles. De même, les problèmes TLS portent sur des représentations précises de noms d’hôte et sur des conditions de validation des certificats ; il ne faut pas les présenter comme une défaillance générale du chiffrement TLS.

L’avis officiel de Node.js précise, pour chaque vulnérabilité, les branches concernées et les conditions techniques. Les équipes d’ingénierie devraient consulter ces détails lorsqu’elles évaluent leur propre exposition.

La sécurité applicative s’étend jusqu’au runtime

Un développeur peut écrire un code applicatif soigné, valider les entrées et tenir à jour les dépendances de l’application. Ces pratiques restent nécessaires, mais les applications dépendent aussi du comportement du runtime sur lequel elles reposent. Un client HTTP peut décompresser des données. Une bibliothèque TLS peut interpréter un nom d’hôte. Un résolveur DNS peut transformer un nom. Une API cryptographique peut s’appuyer sur un état créé au démarrage de l’application. Chacune de ces opérations peut influer sur une décision de sécurité.

Les vulnérabilités Node.js d’octobre illustrent plusieurs façons dont un comportement de bas niveau peut saper des hypothèses faites dans les couches supérieures d’une application. Le problème Brotli en offre un exemple particulièrement concret, car des chercheurs ont démontré un chemin allant de données HTTP compressées ordinaires jusqu’à l’exécution de code dans un environnement Node.js testé. Cela ne rend pas toute application Node.js exploitable. Cela montre en revanche pourquoi les équipes doivent comprendre quelles fonctionnalités du runtime leurs applications utilisent réellement.

Les récentes vulnérabilités PHP2Shell analysées par TechiesJournal offrent une leçon voisine venue d’un autre runtime, même si les mécanismes techniques sous-jacents et les conditions d’exposition diffèrent. Dans les deux écosystèmes, un code applicatif sûr ne peut pas, à lui seul, compenser une faille de sécurité mémoire non corrigée dans le runtime qui l’exécute.

Les étapes immédiates : corriger, cartographier et vérifier

L’action immédiate est simple : identifier les déploiements Node.js concernés et les faire passer aux versions corrigées applicables, à savoir 22.23.4, 24.22.1 ou 26.12.1, ou à des versions prises en charge plus récentes qui contiennent les correctifs. En parallèle, les développeurs et les équipes de sécurité devraient repérer où des données compressées non fiables atteignent les fonctions de décompression du runtime, y compris par les réponses HTTP sortantes et par les middlewares de corps de requête configurés. Les équipes d’infrastructure devraient vérifier le runtime réellement déployé dans les conteneurs, sur les hôtes et dans les environnements managés, plutôt que de se fier uniquement aux versions prévues dans la configuration du gestionnaire de sources.

Si des indices de comportement suspect existent, examinez-les à l’aide des journaux (logs) de l’application, des informations du runtime et de la télémétrie de sécurité pertinente. Un plantage de processus ou une erreur de décompression ne constitue pas, à lui seul, une preuve de compromission. Il n’y a pas lieu de supposer que toutes les applications Node.js ont été attaquées. Il n’y a pas non plus de raison valable de retarder une mise à jour de sécurité du runtime disponible au seul motif qu’aucune preuve publique d’exploitation à grande échelle n’est apparue.

La leçon principale dépasse Brotli.

Les applications héritent des frontières de sécurité de leurs runtimes. Savoir où des données non fiables franchissent ces frontières fait partie de la compréhension de la surface d’attaque réelle de l’application.

Pour aller plus loin

Recherches examinées le 23 octobre 2026. L’activité des menaces, la disponibilité des correctifs et les recommandations des éditeurs peuvent évoluer rapidement : vérifiez les sources primaires avant d’agir.

Sources des éditeurs, des chercheurs et des organismes publics

• Node.js, October 21, 2026 Security Releases, projet Node.js, 21 octobre 2026 : l’avis principal, qui couvre les dix CVE, les branches concernées, les descriptions techniques et les correctifs publiés.
• Node2Shell: From Brotli Data to Remote Code Execution, Imperva Threat Research, 22 octobre 2026 : le détail des expériences d’exécution de code rapportées, la build de Node.js testée, les chemins d’exposition par les requêtes et les réponses, la comparaison avec la version corrigée et les limites.
• Detect and Report Invalid Stream Earlier, commit du code source amont de Google Brotli : la preuve, au niveau du code, des modifications apportées à la gestion des erreurs du décodeur.
• Node.js Multiple Vulnerabilities, Hong Kong Computer Emergency Response Team Coordination Centre, 22 octobre 2026 : un bulletin de sécurité complémentaire qui résume l’impact et les versions de sécurité recommandées.

Cet article distingue les avis des éditeurs, les résultats expérimentaux rapportés et les recommandations pratiques d’ingénierie. L’exposition propre à chaque déploiement et l’activité ultérieure des menaces doivent être réévaluées avant d’agir.

À lire aussi sur TechiesJournal

• Vulnérabilités critiques de PHP : qui est concerné, ce qui pourrait arriver et comment corriger en toute sécurité, TechiesJournal, octobre 2026 : la vulnérabilité de runtime voisine dans PHP, et comment la corriger en toute sécurité.
• Node.js, Docker et Go : trois changements discrets qui peuvent casser votre pipeline (en anglais), TechiesJournal, octobre 2026 : d’autres changements du runtime Node.js et des conteneurs qui affectent les pipelines de livraison.