Brotli2Shell (CVE-2026-111497) : ce que les entreprises doivent savoir dès maintenant sur Node2Shell et HTTP2Shell
27 octobre 2026
Brotli2Shell en bref
Brotli2Shell (CVE-2026-111497), également appelée Node2Shell ou HTTP2Shell, est une vulnérabilité critique du décodeur Brotli de Google, très répandu. En tant qu’autorité de numérotation CVE compétente, Google lui attribue la note CVSS v4.0 9.2. Elle a été divulguée le 21 octobre 2026 avec la mise à jour de sécurité de Node.js. Des données compressées en Brotli spécialement préparées peuvent corrompre la mémoire du processus, divulguer le contenu de la mémoire, faire planter des processus et, dans le pire des cas, permettre l’exécution de code sans authentification. La faille ne se situe pas dans une application isolée, mais dans une bibliothèque intégrée à Node.js, Bun, .NET, des paquets Python, Envoy, Istio, des bibliothèques Java, des bases de données et des outils multimédias. Notre point de situation détaillé, avec matrice des versions, vérification de version, plan en 7 points et contrôle d’exposition : https://brotli2shell.wiz.vamisec.com/en/
Ce qui se passe techniquement : une valeur de retour, deux significations
Brotli est un format de compression que les serveurs web et les CDN utilisent pour réduire la taille des contenus. Le décodeur fonctionne en flux et, lorsqu’il manque de données d’entrée, accumule des octets dans un tampon interne de huit octets. Lors d’un changement de bloc impossible, la fonction DecodeBlockTypeAndLength() renvoyait la même valeur que lorsque des données d’entrée manquaient. Le décodeur prenait donc l’erreur de format pour une pause, ajoutait d’autres octets et écrivait au-delà de la fin du tampon. Selon des analyses, le neuvième octet écrase le champ de longueur du tampon, ce qui rend les écritures suivantes contrôlables. La faille a été découverte par Khai Tran et Sylvie Mayer d’OpenAI Codex Security. Fait notable : le correctif figure dans le code source public de Brotli depuis le 27 février 2026, mais les versions incluant le correctif ne sont parues que le 21 octobre. Les projets reposant sur des versions figées de Brotli sont restés vulnérables pendant près de huit mois.
Quels produits sont concernés et quelles versions apportent le correctif
Google Brotli est concerné de la version 1.0.3 à la version 1.2.0 ; la faille est corrigée dans les versions 1.0.10, 1.1.1 et 1.2.1. Versions de produits corrigées : Node.js 22.23.4, 24.22.1 et 26.12.1, Bun 1.4.4, .NET 8.0.33, 9.0.22 et 10.0.14, les paquets Python brotli 1.2.1 et brotlicffi 1.2.1.0, Envoy 1.36.12, 1.37.8, 1.38.6, 1.39.3 et 1.40.0, Istio 1.29.9, 1.30.6 et 1.31.2 ainsi que Brotli4j 1.24.0. Node.js 20 et les branches plus anciennes ne reçoivent pas de correctif ; selon Microsoft, .NET Framework n’est pas concerné. Pour ClickHouse et libjxl, par le biais duquel FFmpeg est également concerné, des correctifs ont été fusionnés, mais pas encore publiés. DuckDB et Apache Arrow ne disposent pas encore de correctif (état au 27 octobre 2026). Les modules Brotli de nginx et d’Apache se limitent à la compression et ne sont pas concernés ; les sources actuelles de Chrome et de Firefox utilisent des révisions de Brotli de mars et avril 2026 intégrant le correctif ; la première version publiée des navigateurs qui l’inclut n’a pas été communiquée.
Trois chemins vers le décodeur : requêtes, réponses et fichiers
Un système est exploitable dès lors qu’il décompresse des données Brotli provenant d’une source non fiable. Premièrement, les requêtes entrantes avec Content-Encoding: br, par exemple via Express 5 avec body-parser 2, la décompression des requêtes d’ASP.NET Core ou les filtres Brotli d’Envoy. Deuxièmement, les réponses de serveurs externes : fetch() dans Node.js, HttpClient dans .NET avec décompression activée et les clients Python dotés d’un paquet Brotli installé décompressent automatiquement. Imperva a démontré l’exécution de code contre Node.js par ces deux chemins. Les webhooks, les aperçus de liens, les robots d’indexation et les agents IA dotés d’outils web qui consultent des URL choisies par l’utilisateur sont donc également menacés. Troisièmement, des fichiers tels que JPEG XL ou Parquet. Un WAF ne protège que le sens entrant, et il ne suffit pas de retirer br de l’en-tête Accept-Encoding, car un serveur malveillant peut quand même envoyer des données Brotli.
Situation au 27 octobre 2026 : exploits publics, exploitation non confirmée
Plusieurs exploits circulent sur GitHub. Avec eux, l’exécution de code ne réussit généralement que dans des conditions ajustées, alors qu’un plantage s’obtient facilement. Le 26 octobre, ELLIO a signalé du trafic d’exploitation visant Node.js 24.22.0 sur ses propres capteurs et y voit la première exploitation observée dans la nature. Tenable ne l’a pas confirmé de manière indépendante, Rapid7 n’avait connaissance d’aucune exploitation, et la faille ne figure pas dans le catalogue KEV de la CISA. Le CERT-Bund allemand la recense dans l’avis WID-SEC-2026-4117 avec une gravité moyenne. Selon Akamai, 61 % des réseaux utilisent des versions de Node.js concernées ; selon Wiz, 91 % des environnements cloud comportent des ressources vulnérables.
Ce que les entreprises devraient faire dès maintenant
Nous recommandons un plan en 7 points, de l’extérieur vers l’intérieur : 1. Identifier où Brotli est décompressé, en commençant par les systèmes exposés sur Internet. 2. Rejeter les requêtes avec Content-Encoding: br au niveau du WAF, du CDN ou du reverse proxy et désactiver les filtres Brotli dans Envoy et Istio. 3. Corriger en priorité les services accessibles de l’extérieur et ceux qui consultent des URL externes, reconstruire les images et redémarrer les processus. 4. Traiter ensuite les systèmes internes, les pipelines de données et les outils. 5. Dès le premier jour, exiger des rapports écrits de la part des fournisseurs. 6. Analyser le code et les images avec les scanners open source de JFrog et de Trail of Bits, examiner les plantages survenus depuis le 21 octobre et renouveler les identifiants d’accès en cas d’indices de compromission. 7. Tout documenter et vérifier les obligations de notification. Détails et commandes d’inventaire : https://brotli2shell.wiz.vamisec.com/en/#actions
Obligations de notification au titre de NIS2, du RGPD, de DORA et du Cyber Resilience Act
Une vulnérabilité non exploitée n’est pas, à elle seule, soumise à notification. Si elle a été exploitée, des obligations de notification peuvent s’appliquer au titre de NIS2 et de la loi allemande sur le BSI, du RGPD ou, pour les entités financières, de DORA. Depuis le 11 septembre 2026, les fabricants qui livrent Brotli ou un environnement d’exécution tel que Node.js dans leurs propres produits doivent notifier les vulnérabilités activement exploitées via la plateforme de notification de l’ENISA, conformément au Cyber Resilience Act. Les délais courent à partir du moment où vous avez connaissance de l’incident.
Comment VamiSec vous accompagne
En tant que membre de la Wiz Partner Alliance, VamiSec vérifie rapidement si Brotli2Shell vous concerne : de l’extérieur avec Wiz ASM, le Wiz Red Agent et VamiRedteam, et de l’intérieur via des connecteurs Wiz en lecture seule pour le cloud et Kubernetes ainsi qu’avec les scanners de JFrog et de Trail of Bits dans vos dépôts. Vous recevez une liste de constats priorisée et un plan d’action. Vous pouvez demander ce contrôle via https://brotli2shell.wiz.vamisec.com/en/#exposure-check ou par e-mail à wiz@vamisec.com. En cas de soupçon de compromission, notre CSIRT est joignable 24 heures sur 24 à l’adresse csirt@vamisec.com.
Tous les liens et sources
Point de situation et contrôle d’exposition : https://brotli2shell.wiz.vamisec.com/en/ · Fiche CVE : https://www.cve.org/CVERecord?id=CVE-2026-111497 · Avis de sécurité Node.js : https://nodejs.org/en/blog/vulnerability/october-2026-security-releases · Correctif Brotli : https://github.com/google/brotli/commit/0ed4268a4401abcb4472096340477cf4af7d1a2b · .NET : https://github.com/dotnet/announcements/issues/494 · Imperva : https://www.imperva.com/blog/node2shell-from-brotli-data-to-remote-code-execution/ · JFrog : https://research.jfrog.com/post/brotli2shell-beyond-node2shell-and-http2shell/ · Wiz : https://www.wiz.io/blog/cve-2026-111497-brotli-rce-node-js · CERT-Bund : https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2026-4117 · Aperçu indépendant des produits : https://broccoli2shell.com/
Questions fréquentes sur Brotli2Shell
Qu’est-ce que Brotli2Shell ?
Brotli2Shell est l’un des noms de CVE-2026-111497, une vulnérabilité critique du décodeur Brotli de Google, notée CVSS v4.0 9.2. La même faille est également connue sous les noms Node2Shell, HTTP2Shell et Broccoli2Shell. Des données Brotli spécialement préparées peuvent corrompre la mémoire et, dans le pire des cas, permettre l’exécution de code.
Quelles versions sont sûres ?
Brotli 1.0.10, 1.1.1 et 1.2.1, Node.js 22.23.4, 24.22.1 et 26.12.1, Bun 1.4.4, .NET 8.0.33, 9.0.22 et 10.0.14, les paquets Python brotli 1.2.1 et brotlicffi 1.2.1.0 ainsi que les versions corrigées d’Envoy, d’Istio et de Brotli4j. Les distributions rétroportent souvent le correctif sans nouveau numéro de version ; c’est alors le changelog du paquet qui fait foi.
Suis-je concerné si je n’utilise pas Node.js ?
C’est possible, oui. La faille se trouve dans le décodeur Brotli lui-même, qu’embarquent aussi Bun, .NET, des paquets Python, Envoy, Istio, des bibliothèques Java, des bases de données comme ClickHouse et DuckDB, Apache Arrow et FFmpeg. Ce qui compte, c’est de savoir si un composant décompresse des données Brotli provenant d’une source non fiable.
Brotli2Shell est-elle déjà exploitée ?
Au 27 octobre 2026, aucune exploitation contre de véritables victimes n’a été confirmée. Des exploits publics existent, et ELLIO a signalé du trafic d’attaque sur ses propres capteurs. La faille ne figure pas dans le catalogue KEV de la CISA. Traitez néanmoins les systèmes accessibles comme s’ils étaient attaqués.
Un WAF protège-t-il contre Brotli2Shell ?
En partie seulement. Les règles WAF de Cloudflare, Vercel ou Imperva couvrent les requêtes entrantes ; par défaut, la règle de Cloudflare se contente de journaliser. Aucun WAF ne voit les réponses de serveurs externes que vos services récupèrent et décompressent. Le correctif reste nécessaire.
Où trouver des détails et un accompagnement ?
Le point de situation détaillé réunit la matrice des versions, la vérification de version, les commandes d’inventaire, le plan en 7 points et une FAQ ; vous pouvez également y demander le contrôle d’exposition de VamiSec : https://brotli2shell.wiz.vamisec.com/en/
Vous avez des questions sur la sécurité IT de votre organisation ?
Première consultation gratuite →