La vulnérabilité CVE-2026-111497 se trouve dans le décodeur Brotli intégré à Node.js. Elle est liée à une écriture hors limites en mémoire (out-of-bounds write), un défaut qui survient lorsqu’un programme écrit des données au-delà de la zone mémoire prévue.
Brotli est un algorithme de compression développé par Google, utilisé pour réduire la taille des données échangées sur le Web. Node.js embarque un décodeur permettant aux applications de traiter ces données compressées.
Le problème apparaît lorsqu’un flux Brotli spécialement conçu amène le décodeur vulnérable à poursuivre le traitement dans un état invalide. Cette situation peut corrompre la mémoire du processus et, dans certaines conditions, ouvrir la voie à l’exécution de code arbitraire.
Pourquoi cette vulnérabilité est-elle dangereuse ?
Un service Node.js peut rencontrer des données Brotli non fiables dans deux situations principales :
- Lorsqu’il décompresse le corps d’une requête HTTP envoyée par un client.
- Lorsqu’il récupère une réponse HTTP auprès d’un autre serveur et que le client HTTP décompresse automatiquement le contenu.
Dans les deux cas, le risque dépend de la possibilité pour un attaquant de contrôler les données soumises au décodeur. La simple présence de Node.js ou la réception d’une requête HTTP ne suffit donc pas, à elle seule, à établir qu’une application est exploitable.
Les applications utilisant des fonctions de décompression explicites, le module node:zlib, ou des composants intermédiaires chargés de décoder les requêtes doivent être examinées en priorité.
Imperva démontre l’exécution de code sur une version officielle de Node.js
L’évolution majeure de cette affaire est la démonstration publiée par l’équipe de recherche d’Imperva le 22 octobre 2026, puis relayée par The Hacker News le 23 octobre.
Les premiers essais publics avaient montré qu’une entrée Brotli spécialement construite pouvait provoquer un plantage et, dans certains cas, une lecture limitée de la mémoire sur une version standard. Ils n’avaient pas démontré de manière concluante l’exécution de code sur une compilation officielle non modifiée.
Imperva a ensuite indiqué avoir réussi à exécuter du code contrôlé par l’attaquant dans une application utilisant l’image officielle Node.js 24.22.0 pour Linux ARM64, sans débogueur ni binaire spécialement modifié. L’équipe a testé des chemins impliquant des corps de requêtes Express et des réponses récupérées depuis un serveur distant. Le test a nécessité plusieurs tentatives et n’a pas été réalisé sur toutes les architectures ni sur toutes les branches de Node.js. Source : Imperva Threat Research.
La même entrée malveillante a été rejetée par la version corrigée Node.js 24.22.1, sans exécution de code.
Cette démonstration confirme que la faille peut dépasser le simple déni de service sur au moins une configuration officielle vulnérable. Elle ne signifie toutefois pas que toutes les applications Node.js vulnérables sont automatiquement exploitables dans les mêmes conditions.
Quelles versions de Node.js sont vulnérables ?
Les mises à jour de sécurité du 21 octobre 2026 corrigent CVE-2026-111497 dans plusieurs branches prises en charge.
| Branche Node.js | Versions vulnérables | Première version corrigée |
|---|---|---|
| Node.js 22.x | Versions antérieures à 22.23.4 | 22.23.4 |
| Node.js 24.x | Versions antérieures à 24.22.1 | 24.22.1 |
| Node.js 26.x | Versions antérieures à 26.12.1 | 26.12.1 |
| Node.js 20.x et antérieures | Versions hors support concernées | Migrer vers une branche prise en charge |
Les numéros indiqués correspondent aux versions correctives signalées dans les avis publiés à la date de rédaction. Il convient de consulter le bulletin officiel de sécurité Node.js avant toute mise à niveau.
Les versions en fin de vie constituent un cas particulier : elles ne bénéficient pas nécessairement d’un correctif dédié. Les organisations qui les utilisent doivent planifier une migration vers une branche prise en charge plutôt que de conserver un runtime obsolète.
La menace dépasse Node.js : Bun, Python et les proxys réseau concernés
Les recherches publiées le 24 octobre 2026 indiquent que la vulnérabilité se trouve dans le décodeur Brotli partagé ou intégré par plusieurs logiciels. Elle ne se limite donc pas au runtime Node.js.
Les produits et composants signalés comprennent notamment :
- Bun, avec un correctif annoncé dans la version 1.4.4 ;
- Les bibliothèques Python
Brotlietbrotlicffi, corrigées respectivement dans les versions 1.2.1 et 1.2.1.0 ; - Envoy et Istio, lorsque la décompression Brotli est activée et que la version utilisée est affectée ;
- Certaines versions de cdxgen, notamment des exécutables autonomes et des images.
Les versions correctives dépendent de chaque projet. Pour la bibliothèque Brotli en C, les versions corrigées mentionnées sont 1.0.10, 1.1.1 et 1.2.1, selon la branche concernée. Source : The Hacker News, synthèse du 24 octobre.
Cette distinction est importante : le fait que la vulnérabilité touche une bibliothèque commune ne prouve pas que chaque logiciel qui l’intègre est exploitable de la même façon. L’exposition dépend de la version embarquée, du chemin de décompression et de la possibilité de contrôler les données traitées.
Comment vérifier et sécuriser les applications concernées ?
Les équipes techniques doivent procéder à un inventaire dépassant les seuls serveurs visibles dans leurs outils de gestion de dépendances.
1. Vérifier la version réellement exécutée
Sur chaque serveur ou conteneur concerné, commencez par relever la version du runtime :
node -vEffectuez ce contrôle dans l’environnement réellement déployé. Une version présente sur le poste de développement ne garantit pas que le conteneur de production utilise le même binaire.
Examinez également les fichiers Dockerfile, .nvmrc, package.json, les contraintes de version du runtime et les pipelines CI/CD.
2. Identifier les chemins de décompression Brotli
Recherchez les applications qui :
- utilisent
node:zlibpour décompresser des flux Brotli ; - acceptent des corps de requêtes compressés ;
- utilisent Express 5 ou des composants de traitement de corps de requêtes capables de décoder Brotli ;
- appellent
fetch()vers des serveurs dont les réponses ne sont pas entièrement maîtrisées.
L’analyse doit inclure les dépendances et les bibliothèques embarquées. Un outil comme npm audit ne remplace pas la vérification du runtime Node.js lui-même.
3. Mettre à jour, reconstruire et redéployer
Installez la version corrigée correspondant à la branche utilisée. Ensuite, reconstruisez les images de conteneurs et redéployez les services concernés.
Un simple redémarrage ne suffit pas si l’image ou le binaire utilisé reste vulnérable. Après le déploiement, vérifiez de nouveau la version avec node -v dans l’environnement actif.
Pour les logiciels intégrant leur propre copie de Brotli, appliquez également les mises à jour fournies par leur éditeur.
4. Réduire temporairement l’exposition si la mise à jour est retardée
Les mesures suivantes peuvent limiter certains chemins d’attaque, mais elles ne remplacent pas le correctif :
- Bloquer les requêtes entrantes utilisant
Content-Encoding: brlorsque l’application n’a pas besoin de recevoir des corps compressés en Brotli. - Désactiver, lorsque cela est possible, la décompression automatique des réponses Brotli provenant de serveurs non fiables.
- Utiliser les règles de filtrage d’un pare-feu applicatif (WAF) si elles sont disponibles et adaptées au chemin d’attaque.
- Exécuter les processus Node.js avec un compte système non privilégié et limiter les secrets accessibles au processus.
Il faut notamment retenir qu’un WAF qui filtre les requêtes entrantes ne protège pas nécessairement une application qui décompresse une réponse Brotli malveillante reçue depuis un serveur distant.
Les détails des mesures temporaires sont présentés dans les analyses d’Imperva et de The Hacker News.
Des attaques réelles ont-elles été confirmées ?
Au 24 octobre 2026, les sources consultées indiquent qu’aucune exploitation de CVE-2026-111497 dans des attaques réelles n’a été signalée. Les démonstrations d’Imperva établissent la faisabilité de l’exécution de code dans une configuration de test, mais ne constituent pas une preuve de compromission effective d’entreprises ou de serveurs sur Internet.
Cette distinction ne doit pas conduire à minimiser le risque. La disponibilité d’une démonstration fonctionnelle sur une compilation officielle augmente l’urgence des mises à jour, particulièrement pour les services accessibles depuis Internet et les applications qui décompressent des données fournies par des tiers.
Les responsables de sécurité doivent surveiller les erreurs et plantages inhabituels des processus, les anomalies de requêtes HTTP et les comportements inattendus des applications. En cas d’indice de compromission, il convient d’isoler le système concerné, de préserver les journaux et de suivre la procédure de réponse aux incidents de l’organisation.
Conclusion
La vulnérabilité Node2Shell (CVE-2026-111497) met en évidence les risques liés au traitement de données compressées non fiables. Le défaut du décodeur Brotli peut provoquer une corruption mémoire et, comme l’a démontré Imperva sur une version officielle de Node.js, permettre l’exécution de code à distance dans certaines conditions.
Les versions corrigées de Node.js sont disponibles, mais la réponse de sécurité doit aussi couvrir les conteneurs, les dépendances, les bibliothèques Brotli intégrées à d’autres logiciels et les composants réseau comme Envoy ou Istio.
La priorité est de mettre à jour les runtimes et les bibliothèques concernés, de reconstruire les environnements déployés et de limiter temporairement la décompression de données Brotli non fiables lorsque la mise à jour ne peut pas être immédiate.
SOURCE : Cyber Security News
