CVE-2026-111497 : un seul bug Brotli, neuf runtimes et l'agent Codex qui l'a découvert

Ce qui complique la situation avec CVE-2026-111497, c’est qu’il ne s’agit pas d’une vulnérabilité dans un seul produit. Il s’agit d’une écriture hors limites dans le décompresseur Brotli de Google, et la même faille est accessible via au moins huit runtimes et proxys distincts qui intègrent la bibliothèque — Node.js, .NET et ASP.NET Core, Brotli et brotlicffi de Python, Bun, Envoy, Istio, et l’implémentation pure Go. L’évaluation de Wiz place 91 % des environnements cloud à risque et note que 82 % d’entre eux exposent Node.js publiquement. CISA l’a ajouté au catalogue des vulnérabilités exploitées connues, et Microsoft a publié un correctif d’urgence pour .NET et Visual Studio.

La seconde moitié de l’histoire, c’est qui l’a découverte : Khai Tran et Sylvie Mayer d’OpenAI Codex Security, selon l’article de Wiz et les crédits amont. Il s’agit d’une équipe d’agents de sécurité IA, et la faille qu’elle a trouvée se situe dans la bibliothèque de décompression la plus largement intégrée du web.

Ce que fait le bug

Brotli est ce que presque toutes les piles HTTP décompressent lorsqu’un serveur envoie code>Content-Encoding: br/code>. Un flux compressé malformé provoque une écriture hors limites pendant la décompression, et le score CVSS v4 est de 9,2. La plage affectée est Brotli 1.0.3 à 1.2.0, corrigée dans 1.0.10, 1.1.1 et 1.2.1.

Ce qui en fait un programme plutôt qu’un ticket, c’est que la bibliothèque est intégrée sous forme de copie vendorisée, liée statiquement ou réimplémentée dans chaque runtime, si bien que le correctif arrive via un train de publication différent dans chaque cas — et parfois pas du tout, car la distribution standard d’un langage possède sa propre copie.

La liste des correctifs, qui est la partie utile

Tous les chiffres ci-dessous proviennent du résumé des avis de Wiz et des versions publiées des projets respectifs, consultés le 30 octobre 2026.

• Google Brotli / libbrotli — versions affectées 1.0.3–1.2.0, à l’exclusion des rétroportages corrigés ; corrigé dans 1.0.10, 1.1.1, 1.2.1.

• Python Brotli — versions 1.0.3–1.2.0 concernées ; corrigé dans la version 1.2.1. brotlicffi — versions 1.0.3–1.2.0.x concernées ; corrigé dans la version 1.2.1.0.

• Node.js — versions 22.x, 24.x et 26.x concernées ; corrigé dans les versions 22.23.4, 24.22.1 et 26.12.1.

• Bun — versions 1.0.21–1.4.3 concernées ; corrigé dans la 1.4.4.

• Envoy Proxy — versions concernées : 1.36.11, 1.37.7, 1.38.5, 1.39.2 ; corrigé dans les versions 1.36.12, 1.37.8, 1.38.6, 1.39.3 et 1.40.0.

• Istio — versions affectées : 1.29.0–1.29.8, 1.30.0–1.30.5, 1.31.0–1.31.1 ; corrigé dans 1.29.9, 1.30.6 et 1.31.2.

• andybalholm/brotli (Go) — affecté avant la v1.2.7 ; corrigé dans la v1.2.7.

La ligne Node.js est celle qui décide de la semaine de la plupart des gens. Un service sur 22.22.x est exposé via sa pile HTTP même si son code applicatif ne mentionne jamais Brotli, car la décompression se produit avant l’appel de votre gestionnaire. Cela explique aussi les trois noms que l’industrie lui a attribués : Node2Shell pour le chemin Node, HTTP2Shell pour le chemin proxy documenté par Check Point, et Brotli2Shell de JFrog pour la vue d’ensemble plus large.

Pourquoi « 91 % » est le chiffre avec lequel il faut débattre

Les chiffres de Wiz décrivent les parcs cloud des clients de Wiz, et non l’internet. Le décompte des environnements qui contiennent quelque part une bibliothèque vulnérable n’est pas un décompte des services exploitables, et l’écart est important : un Brotli embarqué dans une application de bureau qui ne décompresse jamais une entrée non fiable est un constat, pas une vulnérabilité. La version utile de cette statistique est plus étroite — les services qui acceptent des entrées compressées provenant de sources non fiables, soit essentiellement tout point de terminaison HTTP public se terminant par code>br/code>

Deux éléments rendent l’exploitation plausible plutôt que théorique : l’ajout par la CISA au catalogue KEV implique une exploitation observée, et des opérateurs de pots de miel ont consigné des tentatives. Lorsqu’une faille bascule dans la colonne « exploité dans la nature », le délai de correctif cesse d’être votre calendrier de gestion des changements pour devenir celui de quelqu’un d’autre.

La découverte est la partie dont la demi-vie est plus longue.

L’équipe de sécurité d’un modèle de frontière a trouvé une vulnérabilité de sûreté de la mémoire dans une bibliothèque de décompression parcourue par des milliers de personnes pendant une décennie. Ce n’est pas une histoire sur un fournisseur qui aurait été ingénieux ; c’est un constat sur la couverture. L’analyse statique est appliquée à Brotli depuis des années, des harnais de fuzzing existent, et le bug a survécu aux deux — tandis qu’un agent conçu pour lire le code avec intention l’a trouvé et a produit un correctif accepté en amont.

L’asymétrie joue dans les deux sens. La même capacité qui détecte cette classe de bugs la détectera dans le code que vous livrez. Pour quiconque exploite le codage agentique, la question n’est pas de savoir si l’agent peut repérer une écriture hors limites ; c’est de savoir si la découverte vous parvient avant de parvenir à quelqu’un d’autre.

Que faire, dans l’ordre qui compte

Appliquez les correctifs aux environnements d’exécution que vous utilisez réellement. La liste de bibliothèques ci-dessus constitue la référence ; commencez par celles qui terminent le trafic public.

• Ensuite, cherchez les copies intégrées. Les images de base de conteneurs, les binaires statiques, les builds WASM et les wheels de langages embarquent chacun leur propre Brotli, et aucun d’eux n’apparaîtra dans un audit du gestionnaire de paquets de l’application. Un scanner d’inventaire au niveau du dépôt, publié cette semaine, parcourt un système de fichiers et évalue chaque copie de Node, Bun et Brotli qu’il trouve, ce qui constitue un point de départ plus rapide que d’en inventer un.

• Reconstruisez plutôt que de corriger, lorsque c’est possible. Remplacer une bibliothèque liée statiquement dans un artefact déjà construit est le cas typique où l’on livre accidentellement un binaire à moitié corrigé.

• Si vous utilisez Envoy ou Istio en périphérie, considérez les correctifs du proxy comme la priorité absolue de l’ensemble : le proxy décompresse pour le compte de tout ce qui se trouve derrière lui.

• Vérifiez séparément votre parc .NET. Le correctif de Microsoft couvre .NET et Visual Studio, et la version correcte est une mise à jour du runtime plutôt qu’une modification de référence de package.

Où cela se situe pour nos lecteurs

L'essentiel de ce que couvre ce blog concerne les capacités des modèles, leur prix et leur routage. Cela a sa place ici à cause d'une seule ligne : le défaut a été trouvé par un agent IA, et la catégorie de système qui trouve de tels bugs est celle que nos lecteurs intègrent dans leurs pipelines. Un agent d'analyse de dépôt qui s'exécute en CI sur vos dépendances est désormais un contrôle de sécurité, et c'est le même environnement d'exécution d'agent qui écrit votre code.

Le pare-feu d’agents d’OrcaRouter évalue les appels d’outils et MCP avant leur exécution, ce qui constitue le contrôle limitant le rayon d’impact d’un agent ; il ne rend pas correctes les conclusions d’un agent, et rien dans cette CVE ne permet d’affirmer que le routage d’un modèle réduit le risque de chaîne d’approvisionnement. L’enseignement utile à tirer de la semaine est plus restreint et vérifiable : si vous avez donné à un agent un accès en lecture au dépôt pour trouver des bugs, vérifiez que les correctifs qu’il propose sont épinglés, et vérifiez que l’environnement d’exécution sous-jacent à votre propre pile a dépassé la plage 1.0.3–1.2.0.

Le schéma à retenir, c’est que la vulnérabilité se trouvait dans du code que personne n’avait choisi. Brotli est arrivé comme dépendance transitive d’une fonctionnalité d’exécution, a été corrigé à huit endroits selon des calendriers distincts, et continuera d’arriver dans des images de base construites avant cette semaine. La réponse à la chaîne d’approvisionnement consiste surtout à appliquer la discipline consistant à retrouver les copies que vous n’avez pas installées.

Note de sourçage : la matrice des versions affectées et corrigées, la liste des environnements d’exécution et les chiffres d’exposition de 91 %/82 % proviennent du récapitulatif de l’avis de Wiz consulté le 30 octobre 2026, et les versions corrigées correspondent aux publications des projets eux-mêmes. Le score CVSS v4 de 9,2 provient de l’enregistrement CVE. L’attribution de la découverte à Khai Tran et Sylvie Mayer d’OpenAI Codex Security provient de l’article de Wiz et des crédits amont. L’inscription KEV de la CISA et le correctif .NET de Microsoft correspondent aux annonces de leurs organisations respectives ; aucun des deux n’a été lu ici comme document primaire au-delà du récapitulatif de l’avis. La description du scanner d’inventaire est la description fournie par un projet GitHub tiers.