Node2Shell (CVE-2026-111497) : quels systèmes sont exposés et que faire maintenant

Quels systèmes la CVE-2026-111497 de Brotli expose réellement, l’urgence de chaque cas et comment corriger, reconstruire, redémarrer et atténuer sans attendre.

Mis à jour le 27 octobre 2026

La CVE-2026-111497, surnommée « Node2Shell » ou « HTTP2Shell », est une faille de corruption mémoire dans le décompresseur Brotli. Brotli est la compression br utilisée partout sur le web. La faille se trouve dans les versions 1.0.3 à 1.2.0 de la bibliothèque Brotli de Google [1]. Node.js embarque cette bibliothèque, et le projet Node.js a classé le problème en sévérité élevée (High) pour les branches 22.x, 24.x et 26.x [2]. Le même décodeur est livré dans des paquets Python, des bibliothèques système Linux, des applications de bureau et des outils de développement : l’exposition réelle dépasse donc largement les « serveurs Node.js ».

Cet article s’adresse aux équipes qui doivent déterminer rapidement si elles sont exposées et par quoi commencer.

Ce que fait la vulnérabilité

Le décodeur gère mal un « block switch » malformé dans le flux compressé. Il interprète l’erreur comme « j’ai besoin de plus de données » au lieu de « ces données sont invalides », et continue d’ajouter des octets à un petit tampon interne de taille fixe jusqu’à écrire au-delà de sa fin [2]. Un attaquant capable d’amener votre application à décompresser un flux Brotli forgé peut corrompre la mémoire du processus. Cela peut entraîner :

• Un plantage (déni de service). C’est le résultat le plus fiable.
• Une fuite de mémoire du processus. Des réponses ou des journaux pourraient exposer des fragments de secrets, de jetons ou de données d’autres utilisateurs.
• Une possible exécution de code à distance. Node.js mentionne la RCE parmi les impacts possibles [2]. La première preuve de concept publique n’obtenait l’exécution de code que sur un build volontairement affaibli, mais des chercheurs ont depuis signalé une exécution de code, encore peu fiable, sur un build officiel et non modifié de Node.js 24.22.0 [3].

Aucune authentification n’est nécessaire : l’attaquant doit seulement faire parvenir des octets jusqu’au décodeur. C’est pourquoi le score CVSS 4.0 est de 9.2 (Critical) [1]. La question clé pour chaque système n’est donc pas « utilisons-nous Brotli ? » mais « une partie non fiable peut-elle nous faire décompresser du Brotli ? »

Cas d’usage typiques et risques associés

Cas 1 : API exposées sur Internet qui acceptent des corps de requête compressés (priorité maximale)

Certains serveurs d’API Node.js, BFF, passerelles d’API et points de terminaison de téléversement décompressent les corps de requête envoyés avec Content-Encoding: br. D’autres font de même via un middleware. Risque : n’importe quel client anonyme sur Internet peut envoyer un corps forgé. Les effets vont de plantages à répétition du service, un DoS peu coûteux, jusqu’à la fuite de mémoire d’un processus qui détient des données de session et des clés d’API. Urgence : absolue. Appliquez le correctif aujourd’hui et, d’ici là, bloquez les corps de requête br en périphérie.

Cas 2 : Services qui récupèrent du contenu externe (priorité élevée)

Les consommateurs de webhooks, crawlers et scrapers, services d’aperçu de liens et RSS, intégrations de paiement ou SaaS, ainsi que les agents d’IA qui naviguent sur le web, émettent tous des requêtes HTTP sortantes. De nombreux clients HTTP envoient Accept-Encoding: br et décompressent automatiquement la réponse. En Python, urllib3 et requests le font dès que le paquet Brotli ou brotlicffi est installé, même si votre code ne l’importe jamais. aiohttp fait de même, tout comme httpx lorsqu’il est installé avec son extra brotli [4]. Risque : un serveur distant malveillant, compromis ou usurpé peut attaquer votre backend via sa réponse. L’attaquant n’a même pas besoin d’atteindre votre réseau : c’est vous qui l’appelez. Urgence : élevée. Corrigez en priorité là où les destinations ne sont pas entièrement de confiance.

Cas 3 : Applications de bureau, agents de code IA et CLI avec runtime embarqué

Les applications Electron, les CLI basées sur Bun ou Node et les outils de développement IA embarquent leur propre copie du runtime. Mettre à jour le paquet node du système ne les corrige pas. Mettre à jour l’application sur disque ne corrige pas non plus les copies déjà en cours d’exécution : les processus de longue durée conservent l’ancien runtime en mémoire jusqu’à leur redémarrage. Risque : ces outils détiennent souvent des identifiants et récupèrent du contenu externe, ce qui combine le cas 2 avec un processus privilégié. Urgence : élevée pour les outils qui récupèrent du contenu non fiable. Mettez-les à jour, puis redémarrez-les effectivement. Nous avons détaillé le piège du « mis à jour, mais exécute toujours l’ancien code » dans HTTP2Shell : pourquoi mettre à jour un binaire ne corrige pas les processus en cours d’exécution.

Cas 4 : Images de conteneurs et artefacts CI/CD

Les images construites FROM node:22, node:24 ou node:26 avant le correctif contiennent toujours le runtime vulnérable, même si l’hôte est corrigé. Il en va de même pour les wheels Python empaquetés et les dépendances vendorisées. Risque : le code vulnérable revient à chaque déploiement et à chaque événement d’autoscaling tant que l’image n’est pas reconstruite. Urgence : élevée pour les images derrière les cas 1 et 2. Reconstruisez plutôt que de simplement redémarrer.

Cas 5 : Bibliothèques système Linux, polices et traitement d’images

Les distributions fournissent le décodeur sous forme de bibliothèque partagée, par exemple libbrotli1 sur Ubuntu/Debian. Il est utilisé par curl et libcurl lorsque la compression est activée, par FreeType pour les polices web WOFF2 et, indirectement, par des outils de traitement d’images et de documents comme Pillow. Risque : les systèmes qui effectuent le rendu de polices ou de documents téléversés par les utilisateurs, ou qui récupèrent du contenu externe avec curl --compressed, peuvent être atteints par des données Brotli non fiables. Un serveur qui ne transmet jamais de données externes à ces bibliothèques présente une exposition pratique faible. Urgence : moyenne dans la plupart des cas, mais élevée pour les services de rendu de documents ou de traitement des fichiers téléversés. Ubuntu a publié des paquets brotli corrigés pour 22.04, 24.04, 26.04 et 26.10 [1]. Pour RHEL, Oracle Linux et les autres distributions, consultez le bulletin de votre éditeur concernant le paquet brotli plutôt que de présumer d’un statut.

Cas 6 : Systèmes uniquement internes avec des entrées de confiance (priorité moindre)

Certains services ne décompressent du Brotli qu’à partir de données que vous produisez vous-même, comme des caches internes ou vos propres artefacts de build. Le risque est moindre, mais pas nul : un attaquant qui a déjà pris pied peut exploiter la faille pour progresser davantage. Urgence : corrigez lors du prochain cycle habituel.

Que faire : étapes de réponse

Étape 1 : Identifier où Brotli est décodé (dès aujourd’hui)

• Node.js : vérifiez node -v sur chaque hôte, ainsi que dans chaque image de conteneur et chaque runner CI. Recherchez dans le code et les configurations brotliDecompress, createBrotliDecompress et les middlewares d’analyse du corps qui décompressent br.
• Runtimes embarqués : recensez les applications Electron, CLI Bun/Node et agents d’IA utilisés, et notez la version du runtime que chacun embarque, pas seulement la version de l’application.
• Python : pip show Brotli brotlicffi dans chaque environnement et chaque image. Recherchez httpx[brotli] et les dépendances transitives dans les lockfiles et les SBOM.
• Paquets du système : dpkg -l | grep brotli ou rpm -qa | grep brotli, puis identifiez les processus qui chargent réellement la bibliothèque.
• Priorisez à l’aide des cas ci-dessus : tout ce qui est accessible à des entrées non fiables (cas 1, 2, 3, et 5 avec téléversements) passe en premier.

Étape 2 : Corriger les composants concernés

• Node.js : passez en version 22.23.4, 24.22.1 ou 26.12.1 ou ultérieure [2].
• Python : Brotli>=1.2.1 ou brotlicffi>=1.2.1.0. Régénérez les lockfiles [4].
• Brotli upstream / code C vendorisé : 1.0.10, 1.1.1 ou 1.2.1, selon la branche [1].
• Paquets du système : appliquez la mise à jour de sécurité de votre distribution pour brotli / libbrotli.
• Applications de bureau et agents : passez aux versions de l’éditeur qui indiquent inclure le runtime corrigé. Si un éditeur n’a rien publié, considérez l’application comme non vérifiée plutôt que sûre.

Étape 3 : Reconstruire, redéployer et redémarrer

• Reconstruisez les images de conteneurs à partir d’images de base corrigées, puis redéployez-les. Redémarrer une ancienne image ne sert à rien.
• Redémarrez chaque processus de longue durée qui avait chargé la bibliothèque vulnérable : services Node, workers, sessions d’agents et tout ce qui est lié à la bibliothèque système. Pour les tâches avec état et les agents d’IA, videz ou transférez d’abord le travail afin de ne pas perdre d’événements ou d’approbations en file d’attente.

Étape 4 : Atténuer le risque pendant le déploiement des correctifs

• En entrée : rejetez au niveau du reverse proxy, du load balancer ou du WAF les corps de requête dont le Content-Encoding contient br, avant qu’un décodeur ne les traite.
• En sortie : retirer br de Accept-Encoding ne suffit pas à lui seul, car un serveur malveillant peut quand même envoyer du br. Rejetez aussi, ou refusez de décoder, les réponses qui arrivent avec Content-Encoding: br [4].
• Solution de repli en Python : là où la mise à jour doit attendre, désinstallez Brotli et brotlicffi pour que les clients cessent de décoder br. Testez d’abord, car certains serveurs continueront d’envoyer du br.

Étape 5 : Vérifier et surveiller les signes d’exploitation

• Confirmez la version du runtime depuis l’intérieur du processus ou du conteneur en cours d’exécution, et pas seulement via le gestionnaire de paquets.
• Analysez de nouveau les images et les SBOM pour vous assurer qu’aucune ancienne copie n’est encore intégrée de manière transitive.
• Examinez les journaux récents à la recherche de plantages inexpliqués, d’erreurs de segmentation ou de boucles de redémarrage dans les services qui traitent du br. Une série de plantages provenant d’une même source mérite d’être examinée comme une tentative d’attaque.
• Si un service fortement exposé a planté de manière inattendue avant d’être corrigé, envisagez de renouveler les secrets que détenait ce processus, car une divulgation de mémoire ne peut pas être exclue.

Synthèse

Situation	Risque	Action
Une API publique décode des corps de requête br	Critique	Corriger immédiatement ; bloquer br en périphérie
Le backend récupère des URL externes, des webhooks ou des pages web	Élevé	Corriger immédiatement ; refuser les réponses br
Applications Electron, agents d’IA ou CLI avec runtime embarqué	Élevé	Mettre à jour et redémarrer chaque instance en cours d’exécution
Anciennes images de conteneurs et artefacts CI	Élevé	Reconstruire à partir de bases corrigées et redéployer
Bibliothèque système utilisée pour les téléversements, les polices ou curl --compressed	Moyen–Élevé	Appliquer la mise à jour du système ; redémarrer les services qui la chargent
Données internes de confiance uniquement	Faible–Moyen	Corriger lors du prochain cycle

Corriger le paquet ne représente que la moitié du travail. L’exposition n’est éliminée que lorsqu’aucun processus en cours d’exécution, aucune image ni aucun runtime embarqué ne peut plus décoder du Brotli non fiable avec l’ancien code.

Références

• Node.js : mises à jour de sécurité d’octobre 2026
• Ubuntu : CVE-2026-111497
• Aikido : paquets Python vulnérables à Node2Shell
• Aikido : Node2Shell