Brotli : une faille critique touche à la fois Node.js et .NET

Brotli est un format de compression créé par Google. Personne ne le choisit vraiment : il est simplement là, dans les serveurs web, les navigateurs, les passerelles et les environnements d'exécution qui font tourner vos applications. C'est précisément ce qui rend sa dernière faille si large.

La vulnérabilité CVE-2026-111497 se trouve dans le décodeur de la bibliothèque Brotli. Node.js et Google ont publié des correctifs le 21 octobre. Le 25 octobre, Microsoft a publié à son tour des mises à jour hors calendrier pour .NET. Selon la presse spécialisée, la liste des logiciels concernés continue de s'allonger.

Ce que l'on sait

Selon The Hacker News et Rapid7, il s'agit d'une écriture hors limites de la mémoire lors de la décompression d'un flux Brotli. Concrètement, des données compressées spécialement construites peuvent corrompre la mémoire du processus qui les décode.

• Gravité : Google, qui gère la bibliothèque, note la faille 9,2 sur 10 (CVSS 4.0). Node.js la classe « élevée », Microsoft et Red Hat lui attribuent 8,1.
• Impact : selon Microsoft, cité par Forbes, un attaquant non authentifié peut lire ou corrompre la mémoire du processus, avec un risque de fuite d'informations, de déni de service, voire d'exécution de code.
• Démonstration : selon The Hacker News, des chercheurs d'Imperva ont démontré l'exécution de code sur une version de Node.js non corrigée.
• Exploitation : au 26 octobre, Rapid7 indiquait ne pas avoir connaissance d'une exploitation active, et la faille ne figurait pas au catalogue des vulnérabilités exploitées de la CISA.

Pourquoi une faille de compression est sérieuse

Une API ou un serveur web accepte souvent des requêtes compressées pour gagner en bande passante. Si votre application décompresse automatiquement un corps de requête envoyé avec l'en-tête `Content-Encoding: br`, un attaquant peut lui faire traiter des données piégées sans compte ni action d'un utilisateur.

Le risque ne vient pas seulement de l'extérieur. Une application qui récupère des réponses compressées depuis un service tiers les décode aussi. Selon The Hacker News, retirer « br » de l'en-tête `Accept-Encoding` ne suffit pas à se protéger.

La difficulté, pour une entreprise, est l'inventaire. Brotli n'apparaît dans aucune liste d'applications métier : il est embarqué dans des environnements d'exécution, des images de conteneurs, des passerelles et des dépendances.

Les versions corrigées

D'après The Hacker News et Rapid7 :

• Node.js : 22.23.4, 24.22.1 et 26.12.1. Les branches arrivées en fin de vie, comme la 20.x, ne recevront pas de correctif.
• .NET : 8.0.33, 9.0.22, 10.0.14 et 11.0 RC3. Microsoft précise que .NET Framework n'est pas concerné.
• Bun : 1.4.4.
• Bibliothèque Brotli de Google : 1.0.10, 1.1.1 et 1.2.1.
• Envoy, Istio et les paquets Python Brotli et brotlicffi sont également concernés, avec leurs propres versions corrigées.

Après la mise à jour, pensez à redémarrer les services concernés : selon The Hacker News, c'est indispensable pour que le correctif soit pris en compte.

Les mesures à prendre maintenant

1. Inventorier. Recensez les serveurs, conteneurs et fonctions qui exécutent Node.js, .NET ou Bun, ainsi que vos passerelles Envoy ou Istio. N'oubliez pas les applications développées par des prestataires.
2. Mettre à jour en priorité ce qui est exposé. Une API accessible depuis Internet passe avant les outils internes.
3. Reconstruire, pas seulement installer. Selon Microsoft, les applications .NET autonomes doivent être recompilées et republiées, et les images de conteneurs reconstruites. Installer un nouvel environnement sur le serveur ne met pas à jour celui qui est embarqué dans l'application.
4. Mesure temporaire. Si une mise à jour n'est pas possible tout de suite, rejetez au niveau du proxy ou du pare-feu applicatif les requêtes envoyées avec `Content-Encoding: br`, et désactivez la décompression automatique dans les clients HTTP. Node.js ne propose pas de contournement officiel.
5. Surveiller. Des plantages répétés d'un processus Node.js ou .NET peuvent signaler des tentatives. Vérifiez que votre supervision ne les masque pas derrière des redémarrages automatiques.

Notre regard

PHP la semaine dernière, Brotli aujourd'hui : les failles les plus larges se logent dans des composants que personne ne voit. La rapidité de correction dépend moins de l'équipe sécurité que de la qualité de l'inventaire logiciel : savoir quelles applications embarquent quelles briques, et qui est capable de les reconstruire.

C'est ce que nous vérifions lors de nos audits applicatifs et de nos diagnostics d'exposition : ce qu'un attaquant peut atteindre depuis Internet, et les dépendances qui le rendent possible. Si vous voulez savoir où vous en êtes sur cette faille, contactez-nous.