Une faille de sécurité dans Node.js peut transformer des données compressées malveillantes en exécution de code à distance (RCE). Des chercheurs ont démontré l’attaque contre un runtime non modifié, ce qui suscite des inquiétudes pour les applications qui traitent des données Brotli non fiables.
Imperva a révélé sa preuve de concept Node2Shell le 22 octobre 2026, démontrant l’exécution de code sur Node.js 24.22.0 fonctionnant sous Linux arm64. Répertoriée sous le nom CVE-2026-111497, la vulnérabilité concerne les branches 22, 24 et 26 de Node.js. Les correctifs de sécurité ont été publiés le 21 octobre.
Les applications utilisant le middleware Express ou l’fetch() API intégrée à Node.js peuvent rencontrer le décodeur vulnérable sans l’appeler directement. L’exposition dépend de la possibilité pour des données Brotli contrôlées par un attaquant d’atteindre le code concerné.
L’exposition à Node2Shell dépasse le simple code de décompression personnalisé
Node2Shell exploite une écriture hors limites dans le décodeur Brotli intégré à Node.js. Des données compressées malformées peuvent corrompre la mémoire et potentiellement provoquer des plantages, une divulgation d’informations ou une exécution de code. Les risques de sécurité mémoire associés ont également entraîné la publication de mises à jour de sécurité d’OpenSSL, bien que les vulnérabilités reposent sur des mécanismes différents.
L’analyse du 26 octobre d’Akamai fait état d’un score CVSS v4.0 de 9,2 (critique), tandis que Node.js qualifie la faille de gravité élevée.
Selon les recherches d’Imperva, l’exposition peut se produire par trois voies :
- Middleware Express 5 : Les analyseurs de requêtes configurés peuvent décompresser les corps de requête encodés en Brotli.
- Node.js
fetch(): Les applications peuvent décompresser des réponses Brotli malveillantes provenant de serveurs non fiables. node:zlib: Les services qui décompressent directement des flux Brotli contrôlés par un attaquant peuvent atteindre le décodeur vulnérable.
« Le bug est propre à l’implémentation et n’affecte pas tous les serveurs exécutant Node.js par défaut », a déclaré Yordan Ganchev, spécialiste principal du renseignement sur les menaces chez watchTowr.
Ganchev a averti que des dépendances pouvaient introduire des chemins de décompression négligés. Des risques similaires liés aux dépendances sont apparus dans une vulnérabilité de téléversement d’images HEIC de WordPress, où un logiciel de traitement d’images pouvait exposer les serveurs à une RCE.
La démonstration d’Imperva sous Linux arm64 a nécessité plusieurs tentatives. Les chercheurs n’ont pas établi une fiabilité comparable de l’exploitation sur les autres plateformes, bien que la vulnérabilité sous-jacente ne soit pas limitée à Linux arm64.
Versions corrigées de Node.js et priorités d’atténuation
L’avis de sécurité de Node.js répertorie les versions corrigées suivantes :
| Branche Node.js | Version minimale corrigée |
|---|---|
| 22.x | 22.23.4 |
| 24.x | 24.22.1 |
| 26.x | 26.12.1 |
Les entreprises doivent installer la version corrigée applicable, ou une version ultérieure également corrigée. Les installations non prises en charge doivent être migrées vers des branches prises en charge. La mise à jour d’Express ou de body-parser seule ne corrige pas la faille du runtime.
Les équipes de sécurité doivent donner la priorité à six mesures :
- Inventorier les applications exposées : Vérifier les versions de Node.js sur les serveurs, les conteneurs et les charges de travail serverless. Identifier Express,
fetch(), ainsi que lesnode:zlibchemins de décompression. - Corriger et vérifier les déploiements : Mettre à niveau les runtimes, reconstruire les images de conteneurs concernées et confirmer que les processus de production utilisent des binaires corrigés.
- Désactiver la décompression inutile : Configurer l’option de body-parser d’Express
inflatesurfalselorsque les corps de requête compressés ne sont pas nécessaires. - Limiter le trafic non fiable : Bloquer temporairement les requêtes entrantes
Content-Encoding: brlorsque cela est approprié et limiter les connexions sortantes inutiles. Le filtrage entrant ne protège pas lesfetch()réponses. - Limiter les conséquences d’une compromission : Segmenter les services et restreindre les privilèges des applications, l’accès au système de fichiers et les identifiants cloud.
- Surveiller les plans de réponse aux incidents et les tester : Examiner les plantages inexpliqués, les erreurs de décompression, les processus enfants inattendus et les connexions suspectes. Mettre en corrélation les journaux des applications et du réseau, et tester les plans de réponse aux incidents.
Le filtrage périmétrique n’offre qu’une protection temporaire. De précédentes attaques de contournement du WAF PeopleSoft ont démontré que des systèmes vulnérables pouvaient rester exposés lorsque le filtrage remplace l’application des correctifs.
Ganchev a recommandé d’examiner les journaux contenant « Decompression failed », même si ces erreurs ne prouvent pas une exploitation. Les équipes de sécurité doivent identifier les applications qui traitent des données Brotli non fiables et vérifier que des runtimes Node.js corrigés sont utilisés en production.
Pour en savoir plus : le deuxième correctif RCE critique de GitLab en octobre montre pourquoi les administrateurs doivent continuer à vérifier les mises à jour de sécurité, même après avoir appliqué des correctifs antérieurs.