← Toutes les ressources

Faille Brotli : Node.js puis .NET corrigés en urgence (25/10/2026)

Publié le 27 octobre 2026 · 7 min de lecture · CyberNovaLabs.io

Une faille Brotli a provoqué deux correctifs séparés en quatre jours, chez Node.js puis chez Microsoft. Le défaut n'appartient à aucun des deux : il vient d'une bibliothèque de Google que l'un et l'autre embarquent. Pour une PME, la bonne question n'est pas « est-ce que j'utilise Node.js ? » mais « que contient le logiciel que je fais tourner, et qui le met à jour ? ».

En bref

Le 21 octobre 2026, le projet Node.js a publié une mise à jour de sécurité corrigeant 11 CVE, dont quatre de gravité élevée^[1]. L'une d'elles est la faille Brotli CVE-2026-111497 : des données compressées malformées écrivent au-delà d'une mémoire tampon interne de huit octets, ce qui peut provoquer un plantage, la divulgation de mémoire du processus ou l'exécution de code à distance^[1]. Le 25 octobre, Microsoft a diffusé une mise à jour .NET hors cycle pour la même CVE^[2]. Le défaut n'est ni dans Node.js ni dans .NET : il est dans le décodeur Brotli de Google que les deux embarquent.

Ce qui s'est passé, dans l'ordre

Quatre dates, quatre acteurs, un seul bug. C'est la chronologie qu'il faut avoir en tête avant d'appeler son prestataire.

Au 26 octobre, Rapid7 n'avait connaissance d'aucune exploitation dans la nature, et la CVE ne figurait pas au catalogue des vulnérabilités activement exploitées de la CISA^[4]. C'est une fenêtre de calme, pas une dispense : les mêmes semaines, les failles critiques de PHP sont passées de la publication à l'exploitation de masse en quelques jours.

Pourquoi un seul bug donne trois avis qui ne se ressemblent pas

Observez les intitulés. Le CERT-FR a classé l'affaire sous « Node »^[3]. Microsoft l'a publiée sous « .NET »^[2]. Le NCSC néerlandais a parlé du « décodeur Brotli de Google »^[5]. Trois entrées, trois vocabulaires, un seul défaut.

La conséquence est très concrète pour une PME : si votre veille consiste à surveiller le nom de votre éditeur, vous avez vu un avis sur trois. Et si votre prestataire vous a répondu « nous ne faisons pas de Node.js », il a répondu à côté, parce que la question portait sur une bibliothèque, pas sur un langage. Les versions Brotli amont concernées sont les 1.0.3 avant 1.0.10, les 1.1.0 avant 1.1.1 et les 1.2.0 avant 1.2.1^[4] : c'est ce numéro-là qu'il faut chercher dans l'inventaire, pas le nom commercial.

C'est le même mécanisme que pour l'accès distant de votre prestataire informatique : le composant qui vous expose n'est presque jamais celui que vous avez acheté.

Êtes-vous vraiment exposé ? Le critère est précis

Sur ce point, l'analyse de Rapid7 est plus utile que l'alerte générale. La présence d'un décodeur vulnérable n'établit pas à elle seule l'exposition : il faut que l'application décompresse effectivement des données Brotli fournies par un tiers non fiable^[4]. Beaucoup de systèmes embarquent la bibliothèque sans jamais traiter de contenu compressé venu de l'extérieur.

Trois questions suffisent à trancher, et elles s'adressent à celui qui a écrit ou qui maintient votre application :

1. Notre application décompresse-t-elle du Brotli envoyé par un utilisateur, un client ou une interface tierce ? Si la réponse est non et qu'elle est démontrée, l'urgence tombe d'un cran.
2. Quelle version exacte de Node.js et de .NET tourne en production aujourd'hui ? Pas la version du projet, celle du serveur qui répond.
3. Quels autres services acceptent du contenu compressé en entrée ? Un formulaire de dépôt de fichiers, une API publique, un webhook : ce sont eux qui transforment une bibliothèque vulnérable en exposition réelle.

Une réponse honnête à ces trois questions vaut mieux qu'un tableau de bord vert. Et une réponse absente est, elle-même, le résultat : elle signifie que personne ne tient l'inventaire.

« Corrigé » est un numéro de version, pas une date

Le détail le plus instructif de la semaine se cache dans la mise à jour Microsoft du 25 octobre. Elle contient deux correctifs réédités, CVE-2026-70197 et CVE-2026-102870, parce que la livraison du 13 octobre ne les avait pas entièrement résolus^[2].

Autrement dit : « nous avons appliqué les mises à jour d'octobre » n'est pas une preuve. Un parc peut avoir reçu le correctif du 13 octobre, affiché « à jour », et rester vulnérable à deux défauts sur quatre. La seule formulation qui vaut quelque chose est un numéro de version comparé à la liste de l'éditeur. Exigez-le par écrit, avec la date du relevé.

Si cela tourne à l'incident : votre interlocuteur n'est pas le même selon le pays

CyberNovaLabs.io travaille aux Pays-Bas, en Belgique, en France et au Luxembourg, et c'est précisément là que la mécanique se complique. Une exécution de code à distance sur un serveur applicatif n'est plus un sujet technique : elle devient un sujet de déclaration.

• Belgique : le Centre pour la Cybersécurité Belgique (CCB) est l'autorité nationale et le point de contact des entités concernées par la loi NIS2.
• Pays-Bas : le NCSC, qui a justement publié son appel à corriger le 23 octobre^[5], et la RDI pour la surveillance de la Cyberbeveiligingswet.
• France : l'ANSSI, dont le CERT-FR a émis l'avis du 22 octobre^[3].
• Luxembourg : l'ILR comme autorité de contrôle, avec le CIRCL comme équipe de réponse.

Les délais et le périmètre dépendent de votre statut d'entité, et ce statut ne se devine pas : faites-le confirmer avant d'en avoir besoin. Si vous éditez du logiciel ou si vous intervenez chez des clients, notre guide sur NIS2 pour les éditeurs de logiciels et les prestataires IT aux Pays-Bas détaille la question du périmètre. Nous ne donnons pas de conseil juridique : la référence reste le texte national et l'autorité de votre pays.

Chez CyberNovaLabs.io

Cette semaine illustre une faiblesse ordinaire des PME : personne ne sait dire, en une minute, ce que contient le logiciel qui fait tourner l'activité. Nous construisons et nous maintenons des applications métier sur mesure, avec l'inventaire des composants et la procédure de mise à jour écrits dès le départ — voyez notre page logiciel sur mesure. Si vous êtes vous-même prestataire informatique ou MSP et que vous devez porter ce discours à vos propres clients, nous aidons aussi à remplir l'agenda commercial sur ce terrain : voyez la prise de rendez-vous B2B pour prestataires IT et MSP. Pour en parler sans engagement, écrivez-nous en deux lignes : nous répondons avec des questions précises, pas avec un devis générique.

Sources

1. Node.js — Wednesday, October 21, 2026 Security Releases (projet Node.js, 21/10/2026)
2. .NET October 2026 out-of-band security updates (Microsoft, dotnet/announcements #496, 25/10/2026)
3. CERTFR-2026-AVI-1367 — Multiples vulnérabilités dans Node (CERT-FR / ANSSI, 22/10/2026)
4. CVE-2026-111497: Critical out-of-bounds write in the Node.js Brotli decoder (Rapid7, 26/10/2026)
5. NCSC adviseert om lek in Google Brotli-decoder meteen te patchen (Security.NL, 23/10/2026)

À lire aussi