La faille Brotli, référencée CVE-2026-111497, est un bug du décodeur de la bibliothèque de compression Brotli de Google qui peut aller jusqu’à l’exécution de code à distance. Elle touche tout logiciel qui décompresse des données Brotli venues de l’extérieur : Node.js d’abord, puis Python, .NET, plusieurs distributions Linux et des proxys. Des correctifs existent pour la plupart de ces logiciels. Pour être protégé, il faut les installer, puis redémarrer ou reconstruire ce qui tourne en production.
CVE-2026-111497 : une seule faille dans Brotli, trois noms
Brotli est un format de compression sans perte créé par Google. Les serveurs web l’utilisent pour alléger les pages, et un navigateur l’annonce par l’en-tête Content-Encoding : br. La faille se trouve dans le décodeur écrit en C, de la version 1.0.3 à la version 1.2.0. Google a publié les versions corrigées 1.0.10, 1.1.1 et 1.2.1 le 21 octobre.
Le bug tient à une fonction, DecodeBlockTypeAndLength, qui renvoie un simple « vrai » ou « faux ». Face à une transition de bloc invalide dans un flux compressé, le décodeur ne s’arrête pas et continue d’écrire dans un tampon interne de 8 octets. Ce débordement, une écriture hors limites, provoque une corruption mémoire. Selon le cas, cela donne une fuite de données, un plantage ou l’exécution du code de l’attaquant.
Le nom Node2Shell vient de ce que la faille a d’abord été présentée comme un problème de Node.js. Elle est devenue HTTP2Shell quand il est apparu que tout service décompressant du Brotli reçu de l’extérieur était exposé. Le chercheur Juliano Rizzo a tranché à sa façon : « Node2Shell est un nom affreux. Je l’appelle Broccoli ». Ce surnom a donné le troisième nom.
La découverte revient à OpenAI Codex Security. Contrairement à ce qu’on lit parfois, la faille n’a pas été introduite en février : c’est le correctif qui a été intégré au code de Brotli le 27 février, sans être reconnu comme correctif de sécurité. Côté gravité, Google attribue un score CVSS 4.0 de 9,2 (critique), Red Hat un score de 8,1, et Node.js la classe « haute ». L’avis GitHub GHSA-9v8h-qqgm-4m35 et une preuve d’exploitation publique sont parus le 22 octobre. Imperva a démontré une exécution de code sur Node.js 24.22.0 (Linux arm64).
Au 23 octobre, aucune exploitation active n’était connue et la faille ne figurait pas au catalogue des vulnérabilités exploitées de la CISA. Le NCSC néerlandais juge la probabilité d’exploitation moyenne et les dommages potentiels importants. Ces constats sont datés : vérifiez les avis officiels avant de baisser la garde. Ne confondez pas non plus cette faille avec les deux failles critiques de PHP surnommées PHP2Shell (CVE-2026-109618 et CVE-2026-109619), qui sont distinctes et demandent leurs propres correctifs.
Qui est concerné : Node.js, Python, .NET, Linux et au-delà
Utiliser Brotli ne rend pas un site vulnérable à lui seul. Il faut que des données Brotli malveillantes atteignent un décodeur vulnérable. Le risque existe dans les deux sens : un attaquant envoie une requête marquée Content-Encoding : br, ou votre application appelle un serveur malveillant qui lui répond en Brotli. Les clients fetch() de Node.js, requests/urllib3 et aiohttp décodent ces réponses automatiquement. Vous pouvez donc être exposé sans avoir jamais activé Brotli vous-même.
Node.js, Next.js et Bun
Node.js embarque sa propre copie de Brotli. Les versions corrigées sont sorties le 21 octobre :
- branche 22 : 22.23.4
- branche 24 : 24.22.1
- branche 26 : 26.12.1
Une application Next.js peut être exposée par son runtime Node.js, même si son propre code ne contient aucune faille. Express 5.0.0 à 5.3.0 est concerné via express.json(). Bun est corrigé en version 1.4.4.
Python et .NET
En Python, les paquets Brotli (1.2.1, le 22 octobre) et brotlicffi (1.2.1.0, le 23 octobre) sont corrigés. urllib3, requests, httpx, aiohttp et Scrapy s’en servent automatiquement dès qu’ils sont installés, y compris comme dépendance transitive, c’est-à-dire installés par un autre paquet sans que vous les ayez demandés. Au 23 octobre, les bases de vulnérabilités ne reliaient pas encore la faille à ces paquets : un outil d’analyse peut donc ne rien signaler.
Pour .NET, Microsoft a publié le 25 octobre des mises à jour hors calendrier : 8.0.33, 9.0.22, 10.0.14 et .NET 11 RC3, pour ASP.NET Core et HttpClient. La décompression des requêtes et des réponses n’y est pas activée par défaut, ce qui limite l’exposition sans dispenser de la mise à jour. Les décodeurs Brotli réécrits en Java, JavaScript, C#, Rust et Go ne sont pas vulnérables, mais .NET a dû être corrigé. C’est donc le décodeur réellement utilisé qui compte, pas le langage.
Distributions Linux, proxys et logiciels embarquant Brotli
Situation du paquet libbrotli au 26 octobre :
| Distribution | État |
|---|---|
| Debian 12 et 13, Alpine, Amazon Linux 2023 | Corrigé |
| Ubuntu 22.04, 24.04, 26.04 et 26.10 | Corrigé |
| Fedora 43 à 45 | Version 1.2.1 en test |
| RHEL 7 à 10 | Affecté, sans correctif |
Côté proxys, Envoy est corrigé en 1.40.0, 1.39.3, 1.38.6 et 1.37.8, Istio en 1.30.6 et 1.31.2. curl, Chromium et Firefox ont aussi publié des correctifs. Les pare-feu Palo Alto sous PAN-OS 11.2, 12.1 et 12.2 sont touchés quand le déchiffrement TLS inspecte du Brotli ; Palo Alto a évalué ce risque à 9,2 le 26 octobre. FFmpeg 8.1 et suivants le sont avec JPEG XL.
DuckDB, Apache Arrow, 7-Zip-zstd, p7zip, EDK II et woff2 embarquent leur propre copie de Brotli. Pour eux, mettre à jour la bibliothèque système ne suffit pas : il faut le correctif de chaque logiciel.
Corriger la faille : inventaire, mise à jour, redémarrage
Faire l’inventaire de ce qui tourne en production
Notez les versions réellement en service, pas celles de vos fichiers de configuration :
- La version du runtime Node.js (node -v) sur chaque serveur et dans chaque image.
- Les paquets Python installés, dépendances transitives comprises (pip show brotli brotlicffi).
- Les runtimes .NET (dotnet –list-runtimes).
- Le paquet libbrotli de la distribution.
- Les proxys, pare-feu et images de conteneurs.
Selon la pile courante en agence, voici où regarder :
| Pile | Ce qu’il faut vérifier |
|---|---|
| Site PHP (WordPress, PrestaShop) sur VPS Linux derrière un proxy | libbrotli de la distribution, version du proxy (Envoy, Istio, PAN-OS), services Node.js ou Python installés à côté |
| Front Next.js sous Node.js | Runtime en 22.23.4, 24.22.1 ou 26.12.1, Express 5, image Docker reconstruite |
| Scripts ou API en Python | Brotli 1.2.1 et brotlicffi 1.2.1.0, même installés indirectement |
| Application .NET | Runtime en 8.0.33, 9.0.22, 10.0.14 ou 11 RC3 |
Pour un site PHP, rien n’établit à ce jour que PHP, Apache ou Nginx soient vulnérables. Le risque vient des couches listées ci-dessus.
Mettre à jour, puis redémarrer ou reconstruire
C’est l’étape que beaucoup oublient. Un paquet mis à jour sur le disque ne change rien au processus qui tourne déjà en mémoire avec l’ancienne bibliothèque. Après le correctif, redémarrez les services Node.js, Python et .NET. Reconstruisez les images Docker et les binaires autonomes, qui contiennent leur propre copie des bibliothèques.
Un point à vérifier dans votre contrat d’infogérance : la mise à jour du système est souvent incluse, la reconstruction des conteneurs et le redémarrage des applications pas toujours. Demandez qui s’en charge, et sous quel délai.
Si vous ne pouvez pas mettre à jour tout de suite
Sur RHEL, par exemple, le correctif manquait encore au 26 octobre. En attendant :
- rejeter les requêtes Content-Encoding : br au niveau du proxy ou du WAF (pare-feu applicatif) ;
- utiliser express.json({ inflate : false }) dans les applications Express ;
- retirer br de l’en-tête Accept-Encoding des appels sortants ;
- désinstaller Brotli et brotlicffi en Python si vos clients HTTP peuvent s’en passer.
Ces mesures ont des limites. Le filtrage au proxy ne protège que les requêtes entrantes, pas les réponses que votre application va chercher ailleurs. Désactiver Brotli côté serveur web ne suffit pas si l’application décode du Brotli en interne. Surveillez ensuite les plantages et les comportements anormaux des services qui décompressent des données.
Ce que cette faille change pour la maintenance de vos sites
Le code d’un site peut être propre et l’application compromise quand même, par son runtime, une dépendance, le système, un conteneur ou le proxy. Et le correctif de Brotli est resté dans le code de février à octobre sans que personne n’y voie un enjeu de sécurité. Nous conseillons donc d’appliquer régulièrement les mises à jour de chaque couche, et pas seulement celles étiquetées « sécurité ».
Le rythme va s’accélérer : OpenAI, dont l’outil a trouvé cette faille, s’attend à une forte hausse des découvertes dans les prochains mois. Prévoyez une fenêtre de maintenance au moins mensuelle.
