La vulnérabilité Brotli touche .NET et Node.js : vérifier et mettre à jour les applications

Une application peut recevoir du trafic HTTPS ordinaire tout en traitant une entrée dangereuse si elle décompresse des données Brotli fournies par l’utilisateur. Le 25 octobre 2026, Microsoft a publié des mises à jour .NET hors calendrier pour corriger un dépassement de tampon dans le décodeur Brotli ; la vulnérabilité est référencée CVE-2026-111497. Node.js a intégré un correctif pour cette même vulnérabilité dans une version de sécurité distincte publiée le 21 octobre. Pour les développeurs, la première étape consiste à repérer le chemin qui mène des données externes au décodeur, puis à mettre à jour le runtime et à reconstruire ou redémarrer l’application.

D’après la description de Microsoft, la vulnérabilité .NET peut permettre à un attaquant non authentifié de lire ou d’altérer la mémoire du processus, ce qui peut entraîner une divulgation de données, un déni de service ou une élévation de privilèges. Des correctifs sont disponibles pour .NET 8, 9 et 10, ainsi que pour .NET 11 Release Candidate 3. Pour .NET 8, les versions indiquées sont le runtime 8.0.33 et les SDK 8.0.133 ou 8.0.427. .NET Framework n’est pas concerné par cette vulnérabilité.

Dans quels cas existe-t-il une exposition ?

Le risque apparaît lorsqu’une application transmet un flux Brotli non fiable à un décodeur vulnérable. Dans .NET, cela peut se produire avec la décompression des requêtes ASP.NET Core, la décompression automatique des réponses via HttpClient ou l’appel direct aux API de System.IO.Compression, par exemple BrotliStream et BrotliDecoder. L’avis de sécurité .NET énumère ces cas et précise que la décompression des requêtes entrantes et la décompression automatique des réponses sont désactivées par défaut.

L’inventaire des paquets n’est que le début de la vérification. Repérez les configurations du middleware et des clients HTTP, les appels directs au décodeur et les composants tiers qui acceptent des données compressées. Déterminez si ces données proviennent de clients, de webhooks, de proxys ou d’API externes, et quelles limites de taille et de durée de traitement s’appliquent avant la décompression. Cela permet de localiser les endroits où du code vulnérable reçoit des données contrôlées depuis l’extérieur.

Mettre à jour .NET

Installez la mise à jour correspondant à la branche utilisée : .NET 8 — 8.0.33, .NET 9 — 9.0.22, .NET 10 — 10.0.14 ; pour .NET 11, utilisez Release Candidate 3. Pour les applications dépendantes du framework, installez le runtime mis à jour et redémarrez l’application. Les applications autonomes doivent être reconstruites et publiées à nouveau : la mise à jour du runtime sur l’hôte ne remplace pas la copie intégrée à l’application. Reconstruisez les conteneurs et déployez-les avec des images .NET à jour.

Pour NativeAOT, utilisez également les SDK et les paquets runtime mis à jour lors d’une nouvelle publication. Si vous ne pouvez pas encore déployer le correctif, désactivez temporairement Brotli sur les chemins d’entrée identifiés qui acceptent des données non fiables. Vérifiez les requêtes ordinaires et les intégrations : désactiver la compression peut modifier le traitement des clients qui envoient des corps compressés.

Vérifier Node.js et les dépendances système

Le projet Node.js a signalé la vulnérabilité le 21 octobre : le décodeur Brotli intégré à Node.js 22.x, 24.x et 26.x est concerné. La version de sécurité de Node.js indique les versions corrigées : 22.23.4, 24.22.1 et 26.12.1, respectivement. Mettez à jour la branche prise en charge que vous utilisez et redémarrez le service. Selon la description du projet, le problème survient lorsque l’application décompresse des données fournies par un attaquant avec node:zlib ; une corruption de mémoire peut provoquer un arrêt brutal, une divulgation de mémoire ou l’exécution de code à distance.

Vérifiez également les dépendances fournies séparément de Node.js ou .NET installés sur le système. Comparez les versions de Brotli dans les conteneurs et les artefacts de compilation, puis recommencez la vérification après le déploiement. Dans votre CI, épinglez l’image de base mise à jour et intégrez le contrôle des versions des bibliothèques vulnérables au processus de compilation habituel.

Étapes à suivre

1. Dressez la liste des applications, SDK, runtimes, conteneurs et compilations NativeAOT qui utilisent Brotli.
2. Repérez les endroits où des données externes sont traitées par décompression automatique ou par appel direct au décodeur.
3. Mettez à jour .NET, Node.js et les bibliothèques fournies séparément vers des versions corrigées ; reconstruisez les applications autonomes et les conteneurs.
4. Redémarrez les processus et vérifiez les versions dans l’environnement en cours d’exécution, pas seulement dans les fichiers du projet.
5. En attendant le déploiement du correctif, limitez le traitement des données Brotli non fiables sur les chemins vulnérables identifiés.

La priorité dépend de deux facteurs combinés : la présence d’un composant vulnérable et la possibilité de lui transmettre un flux compressé spécialement conçu. La mise à jour corrige le défaut, tandis que la cartographie des points d’entrée permet de vérifier que le correctif a bien été appliqué aux processus, aux compilations autonomes et aux conteneurs.