Broccoli2Shell : la faille Brotli de Node2Shell touche aussi Python, .NET et Linux

Node2Shell, HTTP2Shell, Broccoli2Shell : trois noms pour une seule faille, et une liste de logiciels affectés qui s'allonge de jour en jour. Après Node.js, c'est au tour de Python, de .NET et de plusieurs distributions Linux de publier des correctifs pour cette vulnérabilité liée à Brotli. Voici ce qu'il faut retenir.

Si vous suivez assidûment les contenus publiés sur IT-Connect, vous avez sûrement vu passer mon article à propos de Node2Shell, la faille Brotli qui expose Node.js à une exécution de code à distance. À ce moment-là, le problème semblait surtout concerner Node.js. Ce n’est plus le cas.

La vulnérabilité en question, associée à la référence CVE-2026-111497, se situe dans le décodeur C de Brotli, la bibliothèque de compression de Google. Elle affecte les versions 1.0.3 à 1.2.0, et elle a été corrigée par les versions 1.0.10, 1.1.1 et 1.2.1. Puisqu'il s'agit d'un composant tiers utilisé par différents outils, Node.js n'est donc pas le seul en cause : tout logiciel qui décompresse des données Brotli contrôlées par un attaquant avec une version vulnérable est potentiellement exposé. GitHub lui attribue un score CVSS 4.0 de 9,2, soit une sévérité critique, là où le projet Node.js la classe en sévérité élevée.

Ceci explique aussi la valse des noms. HTTP2Shell rappelle que les clients et serveurs HTTP sont affectés, même si la faille n'a rien de spécifique à HTTP/2. Broccoli2Shell vient d'un trait d'humour du chercheur Juliano Rizzo : "Node2Shell est un nom affreux. Je l'appelle Broccoli", a-t-il écrit sur X. Le site indépendant broccoli2shell.com recense depuis l'état des correctifs, projet par projet.

Tandis qu'à l'origine, cette vulnérabilité découverte dans Node.js par OpenAI Codex Security a été surnommée Node2Shell. Dans tous les cas, on parle de la même faille de sécurité. Pour autant, cette faille traînait depuis un petit moment, tout comme son correctif : il figurait dans le code de Brotli depuis février 2026, mais, d'après Aikido, personne ne l'avait identifié comme un correctif de sécurité.

Aucune version ne l'a intégré avant celle publiée le 21 octobre.

Python, .NET, Linux : qui est concerné ?

Essayons d'évoquer maintenant les composants et systèmes impactés par cette vulnérabilité :

• Python : les paquets Brotli et brotlicffi, qui compilent le même décodeur C, ont été patchés en 1.2.1 et 1.2.1.0. Deux versions disponibles depuis les 22 et 23 octobre 2026. Attention, votre code n'a pas besoin de les importer : urllib3 (donc requests), aiohttp et httpx avec l'extra brotli s'en servent automatiquement dès qu'ils sont installés, comme l'explique Aikido.

• .NET : Microsoft a publié le 25 octobre des mises à jour hors bande pour .NET 8.0.33, 9.0.22, 10.0.14 et .NET 11 RC3. La firme de Redmond évoque un risque de divulgation d'informations, de déni de service ou d'élévation de privilèges, pour les applications qui décompressent du Brotli via ASP.NET Core, HttpClient ou System.IO.Compression. "La décompression des requêtes et la décompression automatique des réponses ne sont pas activées par défaut.", précise Microsoft.

• Distributions Linux : d'après le suivi d'Aikido au 26 octobre, Debian 12 et 13, Alpine et Amazon Linux 2023 disposent d'un paquet libbrotli corrigé. Ubuntu a suivi le 26 octobre avec une version qui corrige les versions 22.04, 24.04, 26.04 et 26.10. Chez Fedora, la version 1.2.1 est en test pour les versions 43 à 45. Côté Red Hat, le bulletin de sécurité confirme que RHEL 7 à 10 sont concernés, mais aucun correctif n'est encore disponible.

• Copies embarquées : certains logiciels intègrent directement le code de Brotli dans leur propre binaire, au lieu d'utiliser la bibliothèque installée sur le système. Mettre à jour le paquet libbrotli de votre distribution ne change donc rien pour eux : il faut attendre une nouvelle version du logiciel lui-même. Au 26 octobre, broccoli2shell.com listait encore comme non corrigés DuckDB, Apache Arrow (build embarqué), 7-Zip-zstd, p7zip, EDK II et woff2 (build via Makefile).

Mettre à jour ne suffit pas

Installer le correctif est la première étape, mais une autre doit suivre : le redémarrage ou la reconstruction, selon le contexte. Un processus conserve l'ancien décodeur jusqu'à son redémarrage, et une image de conteneur reste vulnérable tant qu'elle n'est pas reconstruite puis redéployée. Côté .NET, les applications autonomes doivent être republiées, car elles embarquent leur propre runtime. C'est la même logique que pour PHP2Shell, comme je l'expliquais dans mon article sur la vérification et la mise à jour des conteneurs PHP sous Docker.

Si la mise à jour immédiate est impossible, deux mesures réduisent l'exposition :

• Python : désinstaller Brotli et brotlicffi. Les clients HTTP se rabattent alors sur gzip et deflate.

• Requêtes entrantes : rejeter les corps de requête envoyés avec l'en-tête Content-Encoding: br au niveau du proxy, du répartiteur de charge ou du WAF.

Limite : ces mesures ne protègent pas les réponses que votre application va chercher, et retirer br de l'en-tête Accept-Encoding n'y change rien, car un serveur malveillant peut envoyer du Brotli malgré tout. Pour Node.js, seule la mise à jour du runtime règle le problème.

Ajouter IT-Connect à mes
sources préférées

Cofondateur d'IT-Connect et Microsoft MVP "Cloud and Datacenter Management". Mon obsession depuis près de 15 ans ? Rendre l'administration système et la cybersécurité accessibles, que vous soyez junior ou confirmé. Plus qu'un métier, l'IT est pour moi une véritable passion. J’accompagne au quotidien les sysadmins et les professionnels de l’IT dans leur montée en compétences et leur veille technique.