Broccoli2Shell prouve que le code le plus risqué est celui que vous n’avez pas choisi

Quelle bibliothèque décompresse les données que reçoit votre serveur ? Si vous ne savez pas répondre en moins d’une minute, Broccoli2Shell est aussi votre problème, que vous ayez ou non déjà tapé le mot « Brotli » dans votre code.

La faille, référencée CVE-2026-111497, est une écriture hors limites dans le décodeur Brotli de Google. Selon Strobes, elle touche les versions 1.0.3 à 1.2.0 de Brotli et obtient un score de 9,2 (critique) sur CVSS 4.0. Comme les clients et serveurs HTTP décodent automatiquement Content-Encoding: br, elle atteint Node.js, Python, Bun et d’autres environnements via le trafic web ordinaire. Node.js a publié des correctifs le 21 octobre dans les versions 22.23.4, 24.22.1 et 26.12.1, comme le rapportent Qualys et d’autres. Le nom a changé plusieurs fois (Node2Shell, HTTP2Shell, Broccoli2Shell), toujours pour la même CVE.

Le changement de nom est la vraie histoire

Strobes fait une remarque pertinente: le surnom a changé trois fois en quatre jours, et chaque nom reflétait qui, selon le secteur, était exposé. On est passé d’un correctif d’environnement d’exécution à un problème de dépendances et de chaîne d’approvisionnement. Nous pensons que cette évolution est la leçon. Le code vulnérable se trouve dans une bibliothèque C que de nombreux projets embarquent, lient ou héritent. Personne ne l’a « installée » par choix. Elle est arrivée avec l’environnement d’exécution, le client HTTP ou l’image.

C’est pourquoi il s’agit d’une infrastructure invisible. Semgrep note que le bug ne se trouve ni dans un paquet npm nommé brotli, ni dans body-parser lui-même. Pourtant, body-parser transmet au décodeur des données compressées contrôlées par l’attaquant. Votre scanner de dépendances peut rester muet alors que le problème se situe une couche plus bas. Strobes signale aussi un suivi public, tenu par des chercheurs indépendants, qui recense les projets dont les copies embarquées n’étaient toujours pas corrigées le 24 octobre, dont l’environnement d’exécution.NET, l’extension brotli de PHP et la gem brotli de Ruby. Mettre à jour votre distribution ne change rien pour un logiciel qui embarque sa propre copie privée.

L’exposition dépend des chemins, et le pire est le chemin sortant

Tous les services Node ne sont pas exposés de la même façon, et mieux vaut le dire clairement pour éviter la panique. Semgrep souligne que l’application doit exécuter une version concernée, utiliser un analyseur compatible Brotli, avoir la décompression activée et exposer une route où il est monté. Selon Strobes, Express 5 avec body-parser 2.x décode par défaut les corps de requête Brotli, si bien qu’un simple app.use(express.json) peut placer le décodeur face à du trafic anonyme.

Le chemin que nous trouvons le plus inquiétant est celui que personne ne surveille: les réponses que votre propre code va chercher. Le fetch intégré de Node décode Brotli automatiquement, et selon Strobes, urllib3, aiohttp et httpx en Python font de même lorsqu’un paquet Brotli est installé, même si votre code ne l’importe jamais. Webhooks, aperçus de liens, « import depuis une URL », robots d’exploration et agents IA qui naviguent: autant de portes par lesquelles un tiers peut entrer. Strobes ajoute qu’aucun WAF ne verra ce chemin. Le WAF de Vercel, d’après TuxCare, bloque la route entrante mais pas les réponses récupérées ailleurs.

Le patch héroïque ne passe pas à l’échelle; les inventaires, si

La réaction habituelle consiste à passer un week-end à enchaîner les mises à jour en urgence. Pour Node 22, 24 et 26, cela fonctionne: le correctif est, selon TuxCare, ennuyeux. Mais TuxCare prévient aussi que Node.js 20, 18 et les versions antérieures ne reçoivent rien du projet amont, et le parc que vous avez oublié est précisément celui qui mord. Il y a ensuite le piège du redémarrage: un processus en cours d’exécution garde l’ancien décodeur en mémoire.

La chronologie devrait aussi nous inquiéter. TuxCare, citant The Hacker News, indique que le changement correctif est entré dans le code source de Brotli en février 2026, mais n’a été livré dans une version de sécurité que le 21 octobre. Strobes ajoute que personne ne l’avait relié à l’exécution de code à distance avant octobre. Un correctif public est une carte, comme l’a écrit un auteur sur Medium. Strobes indique que des preuves de concept publiques existent, et d’après TuxCare, aucune exploitation dans la nature n’avait été signalée au 22 octobre. Nous considérerions ce calme comme temporaire, non comme rassurant.

La même semaine a apporté PHP2Shell, que Semgrep décrit comme une faille présente dans PHP depuis plus de dix ans, et Google Cloud affirme que les applications sous PHP 7.4 y restent vulnérables. Deux divulgations touchant des environnements d’exécution à un jour d’intervalle ne prouvent pas que la sécurité s’est effondrée; Semgrep lui-même dit que la tendance de fond se construit depuis des années. Mais elles montrent le peu de temps dont nous disposons pour déterminer ce que nous exploitons.

Notre verdict

Patchez maintenant, évidemment. Puis faites le travail ingrat qui vous protège vraiment: tenez un inventaire qui descend sous les manifestes de paquets et couvre les environnements d’exécution, les bibliothèques natives embarquées, les images de base des conteneurs, les runners CI et chaque endroit où votre code récupère une URL contrôlée par quelqu’un d’autre. Mettez au rebut les environnements d’exécution en fin de vie plutôt que d’espérer. Nous nous attendons à voir arriver tôt ou tard le prochain bug de décompression, et l’équipe capable de répondre en quelques minutes à « où exécutons-nous cela ? » battra celle qui compte les plus beaux exploits de patching.