Le 27 octobre 2026, CISA a ajouté CVE-2026-111497 à son catalogue des vulnérabilités exploitées connues (KEV), en s’appuyant sur des indices d’exploitation active. Pour Node.js, le correctif est intégré aux versions 22.23.4, 24.22.1 et 26.12.1 des branches 22.x, 24.x et 26.x.
Ce que l’inscription au catalogue KEV change
L’inscription de CVE-2026-111497 signale des indices d’exploitation active et donne une raison de prioriser l’évaluation des systèmes concernés. CISA encourage les organisations à traiter les vulnérabilités du catalogue selon les risques et à donner la priorité à leur correction.
La faille, parfois appelée Broccoli2Shell, Node2Shell ou HTTP2Shell, est une écriture hors limites dans le décodeur Brotli intégré à Node.js. Un changement de bloc malformé était interprété comme une demande temporaire de données supplémentaires au lieu d’une erreur de format. Le décodeur en flux continu ajoutait alors des octets à un tampon interne de huit octets.
Selon le projet Node.js, des données compressées malformées peuvent provoquer un plantage, divulguer la mémoire du processus ou potentiellement permettre une exécution de code à distance (RCE). Le projet classe l’impact comme élevé.
Versions de Node.js corrigées
Le projet Node.js a publié les correctifs le 21 octobre 2026. La version à déployer dépend de la branche utilisée :
| Branche Node.js | Version corrigée |
| 22.x | 22.23.4 |
| 24.x | 24.22.1 |
| 26.x | 26.12.1 |
Les versions de Node.js en fin de vie sont également concernées lorsqu’une mise à jour de sécurité est publiée, précise le projet. Les équipes qui utilisent un runtime intégré à une image ou à une application autonome doivent aussi reconstruire cet artefact : mettre à jour le runtime partagé ne remplace pas automatiquement la copie embarquée.
Les chemins qui exposent le décodeur
L’exposition suppose que des données Brotli contrôlées par un attaquant atteignent un décodeur vulnérable. Le risque vient donc du décodage de données non fiables, pas du simple fait de compresser des données en Brotli.
Un appel direct à node:zlib peut déclencher le décodage. Dans Node.js, fetch() décompresse automatiquement les réponses Brotli. Sysdig signale aussi qu’Express 5 avec body-parser 2 peut décompresser des corps de requête lorsque l’inflation Brotli est configurée. Un serveur HTTP Node.js de base ne décode pas automatiquement un corps Brotli du seul fait de le recevoir.
Pour repérer les chemins concernés, examinez les appels directs au décodeur, les réponses traitées par fetch(), les réglages du middleware et de l’application, ainsi que les runtimes inclus dans les conteneurs et les applications autonomes. La version déployée compte, mais le chemin par lequel des données non fiables arrivent au décodeur compte aussi.
Ce que le test d’Imperva a montré
Dans un compte rendu publié le 22 octobre, Imperva rapporte avoir obtenu une exécution de code avec l’image officielle Node.js 24.22.0 pour Linux arm64. Les essais portaient sur le décodage de réponses par fetch() et sur le traitement de requêtes avec Express 5 et body-parser configuré. Plusieurs tentatives ont été nécessaires ; les mêmes entrées ont été rejetées par Node.js 24.22.1.
Ce résultat situe la démonstration dans une configuration précise. Il aide à comprendre pourquoi un contrôle de version doit s’accompagner d’un examen des voies de décompression réellement utilisées par l’application.
Mettre à jour et redéployer
Mettez à jour le runtime ou la bibliothèque Brotli concernés, puis actualisez les fichiers de verrouillage des dépendances. Si une image ou une application autonome embarque le runtime, reconstruisez-la avant de la redéployer. Redémarrez ensuite les services et contrôlez la version du processus en cours d’exécution.
Bloquer les corps Brotli ou désactiver leur décompression peut réduire l’exposition sur les requêtes entrantes. Cette mesure ne protège pas un client vulnérable qui décode une réponse contrôlée par un attaquant. De même, retirer br de l’en-tête Accept-Encoding ne suffit pas à empêcher un serveur d’envoyer une réponse Brotli.