Corrections Brotli de Microsoft .NET rejoignent l’analyse Node.js Python

Les bibliothèques de compression sont censées être la plomberie discrète d’internet : elles prennent des données volumineuses et les rendent moins agressives pour les factures de bande passante. Puis l’une d’elles se retrouve avec une faille de corruption de mémoire, et soudain la plomberie débarque dans le canal d’incident avec un petit badge CVE. Le dernier cas en date concerne Brotli, l’algorithme de compression largement utilisé de Google, et Microsoft vient maintenant de publier des correctifs .NET d’urgence dans un défilé de correctifs déjà bien chargé.

Ce n’est pas le genre amusant de réutilisation dans un écosystème, où tout le monde gagne des performances gratuites et une présentation de conférence de bon goût. C’est l’autre genre, où le même composant vulnérable résonne à travers les environnements d’exécution, les clients, les serveurs et n’importe quel service sur mesure que quelqu’un a construit il y a trois trimestres et nommé d’après une constellation. La leçon pratique est ennuyeuse, ce qui signifie qu’elle est importante : corrigez l’environnement d’exécution, mais sachez aussi ce que vos applications embarquent.

Le bug caché dans la couche de compression

Selon le blog .NET de Microsoft, l’entreprise a publié des mises à jour de sécurité hors cycle pour .NET 8, .NET 9, .NET 10 et .NET 11 Release Candidate 3, avec une recommandation de mettre à jour dès que possible. Microsoft indique que cette publication corrige CVE-2026-111497 dans l’algorithme de décompression Brotli, ainsi que CVE-2026-114148, un problème de propriété des tarballs .NET sous Linux affectant .NET 8, 9, 10 et 11. Bonne nouvelle venue du service « tout n’est pas en feu » : Microsoft précise aussi que .NET Framework n’est pas affecté.

Sergiu Gatlan, de BleepingComputer, a rapporté que CVE-2026-111497 est une faille de gravité critique causée par une écriture hors limites dans le décodeur Brotli. Traduction : lorsque du code vulnérable décompresse des données, une entrée mal formée peut pousser le décodeur à écrire là où il ne devrait pas, ce qui transforme un bug bien rangé de traitement de données en corruption de mémoire de processus. Les notes de correctif ont rarement une bande-son, mais celle-ci a une ligne de basse.

Où Microsoft affirme que les applications .NET sont exposées

Selon le blog .NET de Microsoft, les applications peuvent être affectées lorsqu’elles traitent des données compressées avec Brotli via la décompression des requêtes ASP.NET Core, la décompression automatique des réponses par HttpClient, ou les API Brotli de System.IO.Compression. C’est un album des plus grands succès de l’écosystème développeur : requêtes web entrantes, clients HTTP sortants et API de compression directes. La bonne nouvelle, selon Microsoft, est que la décompression des requêtes et la décompression automatique des réponses ne sont pas activées par défaut.

BleepingComputer a également rapporté que des exploits de preuve de concept pour cette faille ont été publiés sur GitHub, tandis qu’aucune exploitation malveillante dans la nature n’a été signalée. Cette distinction compte. Les acteurs malveillants n’ont pas besoin d’un tapis rouge, mais du code de preuve de concept public réduit l’effort nécessaire pour tester, adapter et automatiser l’exploitation contre des cibles exposées. Si vous exploitez des services .NET exposés à internet qui acceptent du contenu compressé, c’est ici que le modèle de risque cesse d’être théorique et commence à réclamer une fenêtre de maintenance.

L’effet de vague dans l’écosystème est la vraie histoire

Dans une autre couverture du problème HTTP2Shell plus large, BleepingComputer a signalé des versions corrigées pour Google Brotli, Node.js, Python Brotli et Python brotlicffi. Le même rapport indiquait que les logiciels potentiellement affectés incluent des clients HTTP Python comme urllib3[brotli], requests, httpx et aiohttp[speedups] lorsqu’ils sont configurés avec un décodeur Brotli vulnérable, ainsi que d’autres applications et outils utilisant des implémentations Brotli vulnérables. Donc oui, la vulnérabilité a la portée d’une dépendance que tout le monde a invitée à la fête sans s’attendre à ce qu’elle commence à mâchouiller les câbles.

C’est pourquoi les mises à jour des environnements d’exécution comptent autant que les correctifs applicatifs. Un projet peut très bien ne jamais appeler Brotli directement dans son propre code, tout en héritant quand même du risque via un framework, une bibliothèque HTTP, un paquet optionnel d’accélération ou une dépendance native embarquée. Les chaînes d’approvisionnement logicielles modernes ressemblent moins à de beaux arbres généalogiques qu’à des discussions de groupe où une hypothèse compromise réveille tout le monde.

Ce que cela signifie réellement pour vous

Selon BleepingComputer, mettre à jour la bibliothèque Brotli du système peut ne pas protéger complètement les applications qui embarquent leur propre copie de la bibliothèque. C’est le détail que les administrateurs devraient coller sur leur écran, idéalement par-dessus le dernier e-mail d’un fournisseur promettant que tout était centralisé. Si vous ne pouvez pas appliquer immédiatement les mises à jour .NET, BleepingComputer indique que les mesures d’atténuation temporaires incluent le blocage des requêtes entrantes compressées avec Brotli via un proxy ou un pare-feu, ou la désactivation du décodage Brotli jusqu’à ce que l’application des correctifs soit possible.

Ce que cela signifie réellement pour vous : mettez d’abord à jour les environnements d’exécution .NET pris en charge, puis faites l’inventaire des endroits où Brotli est activé ou embarqué dans vos services. Vérifiez la décompression des requêtes ASP.NET Core, la décompression automatique des réponses par HttpClient et l’utilisation directe de System.IO.Compression. Ensuite, regardez au-delà de Microsoft, car Node.js, Python et d’autres projets dépendants de Brotli font partie du même rayon d’impact.

La conclusion constructive n’est pas de paniquer chaque fois qu’une bibliothèque de compression reçoit une CVE, aussi tentant que cela puisse être pour ceux d’entre nous qui fonctionnent au café et à la confiance périmée. C’est de traiter les composants partagés des environnements d’exécution comme des actifs de premier plan dans la gestion des correctifs, et non comme un décor d’arrière-plan. Surveillez les avis de suivi des environnements d’exécution de langages et des mainteneurs de paquets, et rendez la visibilité des dépendances ennuyeuse avant que la prochaine mise à jour d’urgence ne tente de la rendre passionnante.