Node2Shell : après PHP2Shell, une faille dans Node.js permet d'exécuter du code à distance

Décidément, cette semaine d'octobre 2026 commence à ressembler à un véritable marathon pour les administrateurs système. À peine les correctifs de PHP2Shell publiés, voilà qu'un autre composant majeur du Web se retrouve sous les projecteurs. Cette fois, il ne s'agit plus du langage PHP, mais de Node.js, l'environnement JavaScript utilisé pour faire fonctionner d'innombrables sites, applications Web et services en ligne.

Le 21 octobre, l'équipe de développement de Node.js a publié une nouvelle série de versions de sécurité corrigeant dix vulnérabilités. La plus préoccupante porte la référence CVE-2026-111497 et concerne une bibliothèque de compression appelée Brotli. Son exploitation peut permettre à un attaquant de perturber un serveur, d'accéder à certaines informations en mémoire et, dans les conditions les plus graves, d'exécuter du code à distance.

Le lendemain, le spécialiste de la cybersécurité Imperva a publié une démonstration montrant que cette dernière conséquence n'était pas simplement théorique. Ses chercheurs sont parvenus à exécuter du code sur une version officielle vulnérable de Node.js, sans modifier artificiellement le logiciel pour faciliter l'attaque.

Comme pour PHP2Shell, le problème se situe à un niveau particulièrement sensible : celui du moteur logiciel utilisé par les applications. Mais les deux affaires possèdent des origines techniques différentes, et il serait trompeur de les présenter comme une seule attaque touchant plusieurs langages.

Node2Shell : le problème se cache dans la décompression Brotli

Pour comprendre cette nouvelle faille, il faut d'abord revenir sur une technologie que nous utilisons quotidiennement sans même connaître son nom.

Brotli est un système de compression développé notamment par Google. Il permet de réduire la taille de certaines données envoyées sur Internet afin d'accélérer leur transfert et d'économiser de la bande passante. Lorsqu'un serveur transmet du contenu compressé, le logiciel qui le reçoit doit ensuite le décompresser pour retrouver les données originales.

Node.js intègre son propre décodeur Brotli. Celui-ci peut être utilisé directement par une application, mais aussi indirectement par certains outils et bibliothèques qui prennent en charge les échanges HTTP. C'est particulièrement pratique pour les développeurs : ils n'ont pas besoin de gérer eux-mêmes toutes les subtilités de la compression.

Le problème découvert dans CVE-2026-111497 concerne la manière dont ce décodeur traite certaines données spécialement construites. Dans des circonstances particulières, il peut continuer son travail alors qu'une partie du flux compressé est invalide et provoquer une écriture en dehors de la zone mémoire prévue.

En informatique, ce type de défaut est appelé out-of-bounds write, ou écriture hors limites. Il peut entraîner un plantage, mais aussi corrompre des données internes au programme. Si un attaquant parvient à contrôler suffisamment cette corruption mémoire, les conséquences peuvent aller jusqu'à l'exécution d'instructions malveillantes.

Et c'est précisément pour cette raison que la vulnérabilité mérite une attention immédiate. Le problème ne se trouve pas dans un projet JavaScript particulièrement mal développé : il existe dans un composant fourni avec Node.js lui-même.

Une attaque confirmée sur une version officielle de Node.js

Dans son analyse technique publiée le 22 octobre, l'équipe d'Imperva explique avoir reproduit une exécution de code à distance sur Node.js 24.22.0, à partir d'une image officielle Linux ARM64.

Les chercheurs ont utilisé des données Brotli malveillantes traitées par une application de test. Dans leurs expérimentations, le programme a fini par exécuter des instructions qu'il n'était pas censé lancer. L'équipe précise que cette démonstration n'a nécessité ni version volontairement affaiblie de Node.js ni outil de débogage intégré à l'application ciblée.

Les résultats sont particulièrement intéressants parce qu'ils couvrent deux scénarios : une application recevant une requête HTTP compressée, mais aussi un programme récupérant une réponse compressée depuis un serveur distant. Dans les deux cas, les données peuvent atteindre le même décodeur vulnérable.

Imperva indique avoir notamment testé des configurations utilisant Express 5 et body-parser 2, deux composants largement employés dans les applications Node.js. Les chercheurs précisent cependant que leurs essais n'ont pas couvert toutes les plateformes ni toutes les configurations possibles, et que l'exécution de code ne réussissait pas à chaque tentative.

Autre résultat essentiel : les mêmes données malveillantes ont été rejetées par Node.js 24.22.1, la version corrigée.

Il faut enfin distinguer ces tests d'une campagne de piratage réelle. À la date de rédaction de cet article, les éléments publics vérifiés ne permettent pas d'affirmer que Node2Shell fait déjà l'objet d'une exploitation généralisée contre des serveurs en production. En revanche, la démonstration confirme que le risque d'exécution de code existe dans certaines conditions réelles de déploiement.

Express, Next.js, API : qui doit réellement s'inquiéter ?

Node.js se retrouve derrière de nombreuses applications modernes. Il permet d'exécuter du JavaScript côté serveur, de développer des interfaces de programmation, d'héberger certains sites et de faire fonctionner différents outils utilisés dans les projets Web.

Des environnements comme Express, certaines applications Next.js ou des services développés sur mesure peuvent donc utiliser une version de Node.js concernée. Mais cela ne signifie pas que tous ces projets sont automatiquement exploitables dès qu'ils sont connectés à Internet.

La condition importante est la suivante : l'application doit traiter des données Brotli qu'un attaquant peut influencer.

C'est possible lorsqu'un serveur décompresse des requêtes entrantes à l'aide d'un middleware configuré pour accepter Brotli. Cela peut également se produire lorsqu'une application récupère des réponses HTTP compressées avec une fonction comme fetch() et traite des contenus provenant d'une source non fiable.

En revanche, un serveur HTTP Node.js minimal ne décompresse pas automatiquement toutes les requêtes Brotli simplement parce qu'il les reçoit. La présence de la version vulnérable constitue un problème à corriger, mais l'exploitabilité concrète dépend du fonctionnement de l'application.

Cette distinction est importante, notamment pour les développeurs qui utilisent Express. Le problème ne signifie pas que toutes les versions d'Express sont intrinsèquement compromises. Dans les configurations étudiées, Express permet surtout à des données compressées d'atteindre le composant vulnérable intégré à Node.js.

Et c'est pourquoi mettre simplement à jour une dépendance npm ne constitue pas nécessairement une solution. Le correctif principal concerne l'environnement Node.js lui-même.

Dix vulnérabilités corrigées, dont quatre jugées de gravité élevée

La faille Brotli n'est pas la seule correction publiée le 21 octobre. Dans son bulletin officiel de sécurité, le projet Node.js détaille dix vulnérabilités au total, dont quatre classées de gravité élevée, trois de gravité moyenne et trois de gravité faible.

Parmi les autres problèmes importants, on retrouve des défauts de vérification des certificats TLS. Ceux-ci peuvent, dans certaines conditions, conduire Node.js à considérer comme valide un certificat qui ne correspond pas correctement au serveur contacté, notamment lorsque l'adresse IP est exprimée sous une forme inhabituelle.

Une autre vulnérabilité concerne les recherches DNS. La présence d'un caractère nul dans un nom de domaine peut provoquer sa troncature lors du traitement par dns.resolve, avec des conséquences potentielles sur les vérifications effectuées par certaines applications.

Les correctifs couvrent également des problèmes plus spécifiques concernant les connexions HTTP persistantes, la génération de valeurs aléatoires dans certaines applications empaquetées et les permissions d'accès aux fichiers. Ces dernières failles concernent notamment le modèle de permissions expérimental de Node.js.

À cela s'ajoutent plusieurs mises à jour de composants intégrés, dont OpenSSL, c-ares, Undici et différentes informations relatives aux autorités de certification.

Concernant Node2Shell, un point peut prêter à confusion : Node.js classe officiellement CVE-2026-111497 comme une vulnérabilité de gravité élevée (High), alors que son enregistrement dans les bases CVE lui attribue un score CVSS 4.0 de 9,2/10, correspondant à la catégorie critique. Il s'agit de deux méthodes de qualification différentes, et non de deux failles distinctes.

Dans tous les cas, l'exécution de code à distance constitue un risque suffisamment sérieux pour justifier une intervention rapide.

Quelles versions installer pour corriger Node2Shell ?

La bonne nouvelle est que les correctifs sont déjà disponibles. L'équipe Node.js a publié trois versions de sécurité le 21 octobre 2026.

Pour les installations utilisant Node.js 22, il faut passer au minimum à la version 22.23.4. Les utilisateurs de Node.js 24 doivent installer la 24.22.1, tandis que ceux qui utilisent la branche 26 doivent passer à la 26.12.1.

Infographie originale GeekParadize — Les trois branches de Node.js corrigées contre CVE-2026-111497 depuis le 21 octobre 2026. Les versions plus anciennes arrivées en fin de vie nécessitent une migration ou un support spécifique.

Ces numéros correspondent aux premières versions corrigées de chaque branche. Naturellement, les versions de maintenance ultérieures qui incluent le correctif conviennent également.

La situation se complique pour les projets encore installés sur d'anciennes branches de Node.js. Les versions 20 et antérieures, ainsi que les branches impaires arrivées en fin de vie, ne bénéficient plus des correctifs officiels habituels. Les administrateurs concernés doivent donc envisager une migration vers une branche toujours maintenue, sauf s'ils disposent d'un support spécifique fournissant des correctifs adaptés.

Sur un ordinateur ou un serveur, la commande node -v permet d'afficher la version de Node.js accessible depuis le terminal. Mais attention, cette information ne suffit pas toujours : un service peut utiliser un autre exécutable, une version différente installée par un gestionnaire d'environnements ou même une image Docker contenant un ancien Node.js.

Il faut donc vérifier la version réellement utilisée par l'application en production, pas uniquement celle du poste de développement. Les conteneurs doivent être reconstruits puis redéployés avec une image corrigée, et les processus Node.js concernés doivent être redémarrés après la mise à jour.

Pour les services hébergés sur des plateformes gérées, il convient de consulter les communications de l'hébergeur afin de déterminer si le moteur Node.js a déjà été mis à jour.

En cas d'utilisation d'une version de Node.js fournie par une distribution Linux, certains correctifs peuvent également être intégrés dans les paquets système sans que leur numéro corresponde exactement à celui de la version publiée en amont. Le bulletin de sécurité du fournisseur reste donc la référence.

Un pare-feu peut aider, mais il ne répare pas Node.js

Comme souvent face à une vulnérabilité importante, plusieurs entreprises de cybersécurité ont rapidement annoncé des protections supplémentaires.

Vercel a publié le 21 octobre un bulletin consacré à CVE-2026-111497, expliquant avoir ajouté des règles de pare-feu applicatif destinées à bloquer certaines tentatives d'exploitation transitant par les requêtes entrantes. Imperva a également développé des signatures destinées à détecter les tentatives correspondant aux scénarios observés pendant ses recherches.

Ces mesures peuvent réduire l'exposition pendant le déploiement des mises à jour. Mais elles ne remplacent pas l'installation du correctif.

La raison est assez simple : la faille ne concerne pas uniquement les requêtes envoyées directement vers un site. Elle peut également être atteinte lorsque l'application décompresse une réponse provenant d'un autre serveur. Une protection placée devant le site ne voit pas nécessairement tous les échanges effectués par celui-ci vers l'extérieur.

Il est possible de limiter temporairement l'acceptation des requêtes Brotli dans certaines applications, lorsque leur architecture le permet. Cette mesure peut réduire un vecteur d'attaque, mais elle ne protège pas automatiquement tous les usages du décodeur.

La priorité reste donc de corriger Node.js, puis de vérifier que chaque service utilise réellement la version attendue.

Après PHP2Shell, le rappel est particulièrement brutal

Difficile de ne pas faire le rapprochement avec PHP2Shell, dont nous avons parlé récemment sur GeekParadize. Dans les deux cas, une vulnérabilité touche un composant fondamental utilisé par de nombreuses applications Web, et non une simple extension installée par quelques administrateurs distraits.

Mais les mécanismes diffèrent. Les failles de PHP concernent plusieurs erreurs de gestion de mémoire à l'intérieur du moteur PHP. Node2Shell, de son côté, repose sur un défaut du décodeur Brotli intégré à Node.js. Les correctifs de l'un ne protègent donc absolument pas contre les vulnérabilités de l'autre.

Autre point commun intéressant : l'intelligence artificielle a participé à ces nouvelles recherches en sécurité. Le bulletin officiel Node.js crédite notamment OpenAI Codex Security pour le signalement de CVE-2026-111497, tandis que plusieurs équipes spécialisées ont travaillé à confirmer les conséquences de la vulnérabilité.

Ce n'est pas la preuve que toutes les futures failles seront découvertes automatiquement par des IA. Mais l'évolution des outils de recherche accélère manifestement certaines étapes, depuis l'analyse du code jusqu'à la reproduction des problèmes.

Pour les administrateurs, cette vitesse constitue une difficulté supplémentaire. Entre la publication d'une vulnérabilité et l'apparition de démonstrations concrètes, il peut désormais s'écouler très peu de temps. La période pendant laquelle un serveur vulnérable peut raisonnablement attendre son prochain cycle de maintenance semble donc se réduire.

L'affaire met également en lumière la complexité des dépendances logicielles. Une application JavaScript peut utiliser une bibliothèque de compression sans que son développeur ait jamais écrit une seule ligne de code concernant Brotli. Pourtant, c'est parfois cette petite brique invisible qui devient le point d'entrée le plus dangereux.

Une mise à jour à effectuer avant le prochain week-end

Node2Shell ne signifie pas que tous les sites utilisant Node.js sont déjà compromis, ni qu'une simple connexion Internet suffit à exécuter du code sur n'importe quel serveur. Les conditions d'exploitation existent, elles ont été démontrées sur des configurations précises et elles demandent d'être examinées sérieusement.

Mais avec des correctifs disponibles pour toutes les branches actuellement maintenues, la meilleure décision reste assez évidente. Les administrateurs doivent vérifier leur version de Node.js, identifier les applications qui traitent des données Brotli non fiables et déployer rapidement les versions corrigées.

Pour les développeurs, c'est également l'occasion de faire le ménage dans les anciennes images Docker, les services oubliés et les environnements de préproduction qui peuvent conserver des dépendances obsolètes pendant des mois.

La succession de PHP2Shell et de Node2Shell en quelques jours rappelle finalement quelque chose d'essentiel : la sécurité d'un site ne se limite pas à son code, ses mots de passe ou ses extensions. Elle dépend également de toutes les couches logicielles chargées de le faire fonctionner.

Et lorsqu'un simple mécanisme de décompression peut devenir une porte d'entrée vers un serveur, mieux vaut s'assurer qu'elle a été correctement refermée.