Node2Shell : Node.js corrige une faille critique du décodeur Brotli
Le 21 octobre 2026, le projet Node.js a publié des correctifs pour dix vulnérabilités, dont une faille du décodeur de compression Brotli, surnommée « Node2Shell », qui peut permettre l’exécution de code à distance. Cette affaire rappelle qu’une faille située dans une brique embarquée d’un logiciel ne se corrige pas en mettant à jour ses seules dépendances.
Ce que le projet Node.js a corrigé
Node.js est un environnement d’exécution du langage JavaScript, très utilisé pour construire des serveurs web. Le 21 octobre 2026, le projet a diffusé une série de versions de sécurité : la 22.23.4, la 24.22.1 et la 26.12.1. Selon l’avis publié sur le site du projet, ces versions corrigent dix vulnérabilités (CVE), dont quatre de gravité « haute », trois de gravité « moyenne » et trois de gravité « basse ». Le niveau le plus élevé est donc « haut » pour chacune des trois lignes maintenues.
Parmi elles figure la CVE-2026-111497, intitulée « écriture hors limites dans le décodeur Brotli, pouvant permettre l’exécution de code à distance ». Elle touche les lignes 22, 24 et 26. Le signalement est crédité à l’équipe OpenAI Codex Security (Khai Tran et Sylvie Mayer), et le correctif aux contributeurs mcollina et aduh95.
Un défaut dans la façon de lire des données compressées
Brotli est un format de compression de données développé par Google, couramment employé pour réduire la taille des pages et des réponses échangées sur le web. Node.js l’intègre à son module node:zlib, qui décompresse les données reçues.
Selon l’avis du projet, le défaut tient à la gestion d’une donnée mal formée : le décodeur signalait un « changement de bloc » invalide comme un simple besoin temporaire de données supplémentaires, au lieu d’une erreur de format définitive. Le décodeur en flux continuait donc d’ajouter des octets à un tampon interne de huit octets, et finissait par écrire au-delà de sa limite. Une telle écriture hors limites corrompt la mémoire du processus ; elle peut provoquer un plantage, la divulgation de contenu mémoire, voire l’exécution de code. La condition d’attaque est qu’un assaillant puisse fournir à une application des données Brotli que celle-ci décompresse avec node:zlib.
Exploitation : ce qui est établi, et ce qui ne l’est pas
Selon l’éditeur HeroDevs, qui commente l’affaire dans un billet daté du 23 octobre 2026, une première démonstration publique est apparue le 22 octobre. Elle n’a obtenu une exécution de code que sur une version volontairement affaiblie ; une version standard produisait un plantage et une lecture mémoire limitée. L’équipe d’Imperva, qui a baptisé la faille « Node2Shell », a rapporté une exécution de code sur l’image officielle de Node.js 24.22.0 pour Linux arm64, par la fonction fetch() et par une application Express 5 utilisant body-parser 2.x. HeroDevs précise que cette exploitation n’était pas fiable à chaque tentative, que les autres architectures et les lignes 22 et 26 n’ont pas été testées, et que la version 24.22.1 rejette l’entrée piégée.
Toujours d’après ce billet, la faille ne figurait pas au catalogue des vulnérabilités exploitées de la CISA (agence américaine de cybersécurité) et aucune exploitation dans la nature n’était signalée au 23 octobre. Il convient de noter que HeroDevs vend du support pour les versions en fin de vie : son éclairage n’est pas désintéressé.
Pourquoi mettre à jour npm ne suffit pas
HeroDevs indique que la faille réside dans le décodeur de Google (versions 1.0.3 à 1.0.9, 1.1.0 et 1.2.0 de Brotli, corrigées en 1.0.10, 1.1.1 et 1.2.1), mais que Node.js en embarque sa propre copie, dans son répertoire deps/brotli. La faille se trouve donc dans le binaire de l’environnement d’exécution, et non dans le paquet npm « brotli », sans rapport. Mettre à jour ses dépendances ne change rien : il faut remplacer Node.js lui-même, reconstruire les images de conteneurs et les exécutables qui l’embarquent, puis redémarrer les processus.
Le cas des versions en fin de vie est plus délicat. Le projet rappelle que ces versions sont toujours touchées lorsqu’une version de sécurité paraît et qu’il faut passer à une version maintenue. HeroDevs affirme avoir vérifié que toutes les lignes en fin de vie, de la 20.x à la 12.x, embarquent le décodeur vulnérable et ne bénéficient d’aucun correctif amont ; la voie d’entrée par fetch() a été confirmée sur les versions 20.20.2 et 18.20.8.
Pour comprendre
- La compression réduit la taille des données ; la décompresser exige de lire des données externes, donc potentiellement hostiles.
- Un algorithme de décodage doit traiter toute entrée, y compris malformée, sans jamais sortir de sa zone mémoire.
- Un logiciel assemble souvent des composants tiers embarqués, que seule une mise à jour du logiciel complet corrige.
vous devez être connecter pour déposer un commentaire connecter