Sentrix

Analyse · Vulnérabilités

Brotli : une faille critique dans une bibliothèque partout

Alerte AL26-027 : une faille critique de Google Brotli, exploitée et inscrite au KEV, touche Node.js, .NET, Envoy et d'autres. Où la trouver, comment suivre.

Par Sentrix · Publié le 2026-11-02

Le 28 octobre 2026, le Centre canadien pour la cybersécurité a publié l'alerte AL26-027 sur CVE-2026-111497, une vulnérabilité critique de la bibliothèque de compression Google Brotli. Google avait publié les correctifs le 21 octobre, et la CISA a inscrit la faille à son catalogue des vulnérabilités exploitées (KEV) le 27 octobre. Brotli n'est pas un produit qu'on installe : c'est un composant intégré dans des serveurs web, des environnements d'exécution et des mandataires. Le correctif arrive donc par autant de fournisseurs.

Ce que disent les sources

Le Centre canadien pour la cybersécurité. L'alerte s'adresse aux professionnels et gestionnaires des TI. Elle décrit une écriture hors limites (CWE-787) dans le décodeur Brotli, exploitable à distance sans authentification, qui peut mener à une corruption de mémoire, à une divulgation d'information, à l'arrêt du processus ou à l'exécution de code arbitraire. Elle nomme les technologies qui intègrent Brotli : « Node.js, Microsoft .NET, PowerShell, Bun, Envoy Proxy, Istio », ainsi que « les paquets Python Brotli et brotlicffi », et demande d'évaluer toute application qui en dépend.

Google, dans le projet Brotli. Les versions 1.0.10, 1.1.1 et 1.2.1 sont parues le 21 octobre 2026, chacune avec la même note : « CVE-2026-111497: out-of-bounds write permits remote code execution ». Le dossier CVE, publié le 22 octobre par Google comme autorité de numérotation, vise les versions 1.0.3 à 1.2.0 et attribue un score CVSS 4.0 de 9,2, critique.

La CISA. L'entrée KEV, ajoutée le 27 octobre 2026, fixe une échéance au 10 novembre 2026 pour les agences fédérales américaines et précise : « This vulnerability affects an open-source component, third-party library, protocol, or proprietary implementation that could be used by different products. » L'usage par des rançongiciels y est marqué « Unknown ».

Node.js. Le projet a publié le 21 octobre 2026 les versions 22.23.4, 24.22.1 et 26.12.1, qui corrigent le décodeur Brotli intégré à Node.js.

Pourquoi ça compte

Une faille dans un produit se corrige en une mise à jour. Une faille dans une bibliothèque se corrige en autant de mises à jour qu'il y a de logiciels qui l'embarquent, chacune au rythme de son fournisseur. Une organisation peut très bien n'avoir jamais installé Brotli et l'exécuter quand même dans son application Node.js, son maillage de services Istio, un outil d'administration en PowerShell ou un produit commercial qui ne l'affiche nulle part.

L'inventaire se complique aussi par couches. Un paquet Python brotli ou brotlicffi peut être épinglé dans un fichier de dépendances, une image de conteneur peut contenir une copie système de la bibliothèque en plus de celle de Node.js, et un produit commercial peut embarquer la sienne. Chaque copie a sa version et son propre chemin de correctif. Mettre à jour le système d'exploitation ne corrige pas la copie intégrée à une application, et l'inverse est aussi vrai.

Le correctif publié par Google ne protège rien tant que chaque fournisseur ne l'a pas intégré et que vous n'avez pas déployé sa version. Entre les deux, la faille est exploitée : c'est ce que dit l'inscription au KEV.

Ce que nous en pensons chez Sentrix

  1. Chercher Brotli dans vos SBOM, pas seulement dans vos serveurs. Une nomenclature logicielle permet de répondre en une requête « où tournons-nous une version 1.0.3 à 1.2.0 ? ». Si vos fournisseurs ne vous en remettent pas, notre article sur ce qu'il faut demander dans un SBOM donne la liste.
  2. Commencer par ce qui est exposé à Internet. C'est la priorité du Centre : serveurs web, mandataires et API qui reçoivent du contenu compressé de l'extérieur.
  3. Tenir un registre des avis fournisseurs. Pour chaque produit concerné : la version touchée, l'avis du fournisseur, la version corrigée et la date de déploiement. Une case vide est un suivi à faire, pas une absence de risque.
  4. Corriger selon l'échéance KEV. L'inscription du 27 octobre déclenche la décision tout de suite, avec une date cible mesurable, comme le décrit notre service vulnérabilités et correctifs et notre article sur la priorisation avec le catalogue KEV.
  5. Documenter la mesure temporaire. Si un fournisseur tarde, appliquez la recommandation du Centre sur le contenu non fiable, avec un propriétaire et une date de revue.

La prochaine étape

Cette semaine, interrogez vos SBOM et vos inventaires pour Brotli, puis dressez la liste des fournisseurs dont vous attendez encore un correctif. Les produits sans réponse sont votre priorité. Si vous voulez faire cet exercice avec nous, contactez-nous.

Sources

Questions fréquentes

Q01
Quelles versions de Brotli sont touchées ?
Les versions de Google Brotli de 1.0.3 jusqu'avant 1.0.10, de 1.1.0 jusqu'avant 1.1.1 et de 1.2.0 jusqu'avant 1.2.1, selon le Centre et le dossier CVE. Les versions corrigées sont 1.0.10, 1.1.1 et 1.2.1, publiées le 21 octobre 2026. Le Centre canadien pour la cybersécurité recommande de passer à la version corrigée de votre branche. Pour un produit qui intègre Brotli, c'est la mise à jour de ce produit qui compte, pas celle de la bibliothèque seule.
Q02
La faille est-elle inscrite au catalogue KEV ?
Oui. La CISA a ajouté CVE-2026-111497 à son catalogue des vulnérabilités exploitées le 27 octobre 2026, avec une échéance au 10 novembre 2026 pour les agences fédérales américaines. Le catalogue indique un usage par des rançongiciels « Unknown », c'est-à-dire non établi à ce jour. Une inscription au KEV veut dire que l'exploitation est observée, donc que le correctif ne peut pas attendre le cycle mensuel.
Q03
Que faire si un fournisseur n'a pas encore de correctif ?
Le Centre recommande, si la mise à jour n'est pas possible tout de suite, d'empêcher les applications touchées de traiter du contenu compressé Brotli provenant de sources non fiables. Il demande aussi de surveiller les arrêts inattendus et les comportements anormaux des processus. Documentez la mesure retenue, son propriétaire et la date de revue, puis appliquez le correctif dès qu'il paraît.

Parlons de votre programme de conformité.

Dernière mise à jour :