Node2Shell : corriger la faille Node.js et le prouver lors de l'audit

L'essentiel en bref

• Node2Shell (CVE-2026-111497) est une écriture hors limites (out-of-bounds write) dans le décodeur Brotli de Node.js, accessible via le module node:zlib. Sans authentification et à distance, un attaquant peut faire planter le processus, lire le contenu de la mémoire ou exécuter du code. Node.js classe la faille en sévérité « High » ; un score CVSS de 9,2 est également rapporté.
• Node2Shell est corrigée depuis le 21 octobre 2026 dans Node.js 26.12.1, 24.22.1 et 22.23.4. Node.js 25, 23, 20 et les versions plus anciennes ne reçoivent aucun correctif, car ces branches sont en fin de vie.
• La cause se trouve dans la bibliothèque Brotli de Google, corrigée dans les versions 1.2.1, 1.1.1 et 1.0.10. C'est pourquoi Bun, .NET, Envoy, Istio, les clients HTTP Python, FFmpeg, Apache Arrow et ClickHouse sont également concernés.
• Un code d'exploitation est public sur GitHub, ELLIO a signalé des tentatives d'attaque le 26 octobre 2026 et l'agence américaine CISA classe la faille comme activement exploitée depuis fin octobre. Les agences fédérales américaines doivent corriger avant le 10 novembre 2026.
• La vulnérabilité seule n'est pas un incident à notifier au titre de NIS2. Dans un SMSI selon ISO 27001, la réponse relève de la mesure A.8.8 ; lors du prochain audit, vous devez pouvoir présenter l'inventaire, la décision, la date du correctif et la preuve.

‍

Le 21 octobre 2026, le projet Node.js a publié des mises à jour de sécurité pour une faille désormais connue sous le nom de Node2Shell. Cette faille Node.js ne se trouve pas dans un paquet npm, mais dans le décodeur Brotli fourni avec chaque installation de Node.js. Sont donc concernés les applications web et les API, mais aussi les serveurs de build, les runners de CI et les images de conteneurs qui exécutent Node.js.

Après PHP2Shell, Node2Shell est la deuxième faille de ce type en quelques semaines à toucher directement un environnement d'exécution très répandu. Contrairement à PHP2Shell, elle dépasse largement un seul projet, car le défaut se trouve dans une bibliothèque que de nombreux autres produits utilisent aussi.

Cet article s'adresse aux responsables du SMSI, aux directions informatiques et aux équipes conformité, pas aux développeurs. Il explique ce qu'est la faille, comment savoir si vous êtes concerné directement ou via vos prestataires, et ce que Node2Shell implique pour les entreprises disposant de la certification ISO 27001 ou soumises à NIS2.

Qu'est-ce que Node2Shell ?

Node2Shell est une vulnérabilité du décodeur Brotli de Node.js. Brotli est un format de compression que les serveurs web et les navigateurs utilisent pour transmettre des données plus légères. Lorsqu'une application traite des données Brotli manipulées via le module intégré node:zlib, le décodeur écrit au-delà de la fin d'un tampon interne. C'est ce qu'on appelle une écriture hors limites.

Les conséquences vont du plantage du processus à l'exécution de code malveillant à distance (remote code execution), en passant par la divulgation du contenu de la mémoire. Les attaquants n'ont besoin ni d'identifiants ni d'un accès au réseau interne. Node.js classe la faille en sévérité « High ». Des articles, par exemple de GCN, citent en outre un score CVSS de 9,2, sans préciser qui l'a attribué.

Pourquoi la faille dépasse-t-elle Node.js ?

La cause ne se trouve pas dans Node.js, mais dans Brotli, une bibliothèque open source de Google. Node.js intègre cette bibliothèque, tout comme de nombreux autres produits. La presse spécialisée parle donc aussi de Brotli2Shell. Selon Help Net Security, sont notamment concernés, outre Node.js, Bun, .NET, Envoy, Istio, les clients HTTP Python, FFmpeg, Apache Arrow et ClickHouse.

L'historique est frappant. La correction de la bibliothèque Brotli a été intégrée dès le 27 février 2026, mais sans nouvelle version ni avis de sécurité. La modification est restée lisible publiquement pendant huit mois avant la sortie des versions corrigées 1.2.1, 1.1.1 et 1.0.10. Les équipes qui ne mettent à jour leurs dépendances qu'à partir des versions officielles n'avaient aucun moyen de récupérer le correctif pendant cette période.

Comment la situation a-t-elle évolué ?

Le 21 octobre 2026, Node.js a rendu la faille publique et publié le jour même des versions corrigées. Peu après, un code de preuve de concept est apparu sur GitHub. Le 26 octobre, la société de threat intelligence ELLIO a signalé des tentatives d'attaque enregistrées par ses capteurs sur Internet.

Fin octobre, l'agence américaine de cybersécurité CISA a ajouté Node2Shell à son catalogue des vulnérabilités activement exploitées. Les agences fédérales américaines doivent corriger la faille avant le 10 novembre 2026. Ce délai ne s'impose pas aux entreprises européennes. Il sert toutefois de limite extrême : ce qui n'est toujours pas corrigé après cette date se justifie difficilement face à un auditeur.

Quelles versions de Node.js sont concernées ?

Sont concernées les branches 22, 24 et 26 de Node.js antérieures aux versions de sécurité du 21 octobre 2026, ainsi que toutes les branches en fin de vie. Pour tous les autres produits intégrant un décodeur Brotli, c'est la version de la bibliothèque fournie qui compte.

Les versions du tableau sont des minimums. Node.js a annoncé de nouvelles versions de sécurité pour le 11 novembre 2026. Installez donc la dernière version corrective de votre branche, et pas seulement la version indiquée ci-dessus. Tous les détails figurent dans l'avis de sécurité du projet Node.js.

Une idée reçue fréquente : « Nous n'utilisons pas Node.js, donc nous ne sommes pas concernés. » La faille Brotli se trouve aussi dans des produits auxquels personne n'associe Node.js. Les paquets Windows de PHP en sont un exemple : ils intègrent Brotli et ont donc été recompilés le 26 octobre. Ce que cela signifie pour les serveurs PHP est expliqué dans notre article sur PHP2Shell. Les distributions Linux livrent aussi Brotli sous forme de paquet distinct, que vous mettez à jour via les mises à jour système habituelles.

Que doivent faire les entreprises maintenant ?

La tâche la plus importante est d'obtenir une vue complète des endroits où Node.js et d'autres logiciels intégrant un décodeur Brotli tournent dans votre entreprise. Node.js se cache souvent là où aucun inventaire de serveurs ne regarde : dans les pipelines de build, les images de conteneurs et les outils que les équipes de développement exploitent elles-mêmes.

1. Établir l'inventaire (jour 1, exploitation IT et développement). Recensez chaque environnement d'exécution Node.js avec sa version : serveurs, images de conteneurs, runners de CI et serveurs de build, outils internes et environnements de préproduction. Vérifiez aussi les autres produits du tableau, comme Envoy ou Istio dans votre service mesh.
2. Appliquer les correctifs (jours 1 à 2, développement). Passez au minimum à 22.23.4, 24.22.1 ou 26.12.1, idéalement à la dernière version corrective. Pour Bun, le minimum est 1.4.4.
3. Reconstruire les images et redémarrer les processus (jour 2, DevOps). Une mise à jour ne prend effet que lorsque le processus en cours utilise la nouvelle version. Les conteneurs qui pointent vers un tag d'image figé avec une ancienne version de Node.js restent vulnérables tant que vous n'avez pas reconstruit et redéployé l'image.
4. Remplacer les versions en fin de vie (semaine 1, direction informatique). Ce qui tourne encore sous Node.js 20, 23 ou 25 ne recevra plus de correctif. Planifiez le passage à la version 22, 24 ou 26 et fixez une date.
5. Rejeter provisoirement les requêtes Brotli (immédiatement, réseau ou exploitation). En attendant le correctif, vous pouvez rejeter au niveau du reverse proxy ou du load balancer les requêtes portant l'en-tête « Content-Encoding: br ». Cette mesure ne protège que contre les requêtes entrantes. Elle ne couvre pas les réponses compressées en Brotli que votre application récupère elle-même auprès d'autres serveurs.
6. Interroger vos fournisseurs (semaine 1, RSSI et achats). Demandez par écrit à vos fournisseurs SaaS, hébergeurs et agences si leurs systèmes étaient concernés et à quelle date ils ont appliqué le correctif. Cela vaut aussi pour les services cloud managés, où le fournisseur met à jour l'environnement d'exécution.
7. Documenter et escalader en cas de doute (en continu, RSSI). Notez quand vous avez appris l'existence de la faille, quels systèmes étaient concernés et quand vous avez appliqué le correctif. En cas d'indices de compromission, par exemple des plantages inexpliqués de processus Node.js depuis le 21 octobre, votre processus de réponse aux incidents s'enclenche.

L'erreur la plus fréquente après une journée de correctifs : « Le paquet est à jour, donc c'est réglé. » La nouvelle version de Node.js est bien installée sur le serveur, mais l'ancien processus continue de tourner jusqu'à son redémarrage. De même, Kubernetes fait souvent encore tourner un pod avec l'ancienne image alors que la nouvelle se trouve depuis longtemps dans le registre. Ne vous arrêtez donc pas à « Avons-nous appliqué le correctif ? ». Demandez : « Quelle version tourne en ce moment ? »

Qu'exige NIS2 face à une faille comme Node2Shell ?

Sous NIS2, la gestion des vulnérabilités est une obligation explicite. L'article 21, paragraphe 2, de la directive exige des mesures relatives à la sécurité de la chaîne d'approvisionnement (point d) et à la sécurité de l'acquisition, du développement et de la maintenance des systèmes, y compris le traitement des vulnérabilités (point e).

Où en est la France ?

À la date du 10 novembre 2026, la France n'a pas encore transposé NIS2. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité, adopté par le Sénat en mars 2025, est examiné en séance publique à l'Assemblée nationale depuis le 9 novembre 2026. Les obligations de NIS2 ne s'appliquent donc pas encore aux entreprises françaises au titre du droit national.

Cela ne rend pas le sujet théorique. Les entreprises françaises qui exercent des activités dans des États membres ayant déjà transposé la directive, comme l'Allemagne, y sont soumises. Et les opérateurs de services essentiels restent tenus par le régime NIS 1 de 2018, sous la supervision de l'ANSSI.

Quand l'obligation de notification s'applique-t-elle ?

Une vulnérabilité seule n'est pas un incident de sécurité. Le fait que vos systèmes aient utilisé une version vulnérable de Node.js ne déclenche aucune notification. L'obligation porte sur un incident important, par exemple si des attaquants ont exploité Node2Shell pour voler des données ou mettre un service hors ligne.

Dans ce cas, l'article 23 de NIS2 prévoit une alerte précoce dans les 24 heures suivant la prise de connaissance de l'incident important, une notification d'incident dans les 72 heures et un rapport final au plus tard un mois après cette notification.

Que faut-il attendre des fournisseurs et des clients dans la chaîne d'approvisionnement ?

Node2Shell est un cas typique de chaîne d'approvisionnement. Beaucoup d'entreprises exploitent elles-mêmes peu de Node.js, mais utilisent des produits SaaS, des sites web conçus par des agences et des services d'hébergement qui reposent dessus. Vous ne pouvez pas corriger ces services vous-même ; vous devez demander leur statut et documenter la réponse.

L'inverse vaut aussi pour vous. Si vos clients relèvent de NIS2, leurs équipes achats et sécurité vous demanderont dans les semaines à venir comment vous avez réagi à Node2Shell. Si vous pouvez alors présenter les versions, les dates de correctif et le statut de vos propres fournisseurs, vous répondez au questionnaire en une seule fois. Les questions et clauses contractuelles à prévoir, même si votre entreprise n'est pas elle-même concernée, sont détaillées dans notre article sur NIS2 dans la chaîne d'approvisionnement.

Comment traiter Node2Shell dans un SMSI selon ISO 27001 ?

Dans un SMSI selon ISO 27001:2022, Node2Shell est un cas d'école pour plusieurs mesures de l'annexe A. Au centre se trouve la mesure A.8.8, la gestion des vulnérabilités techniques : vous devez obtenir à temps les informations sur les vulnérabilités, évaluer votre exposition et prendre les mesures appropriées.

D'autres mesures entrent en jeu. A.5.9 exige un inventaire des actifs, sans lequel vous ne savez pas partout où Node.js tourne. A.8.9 couvre la gestion des configurations, donc aussi la question de savoir quelle version d'image tourne en production. A.5.19 à A.5.22 couvrent les relations avec les fournisseurs, des clauses contractuelles au suivi des prestataires. A.5.24 à A.5.26 encadrent la gestion des incidents, de la planification à la réponse en passant par l'évaluation. La façon dont ces mesures de l'annexe A de l'ISO 27001 s'articulent est expliquée dans un article dédié.

Que veulent voir les auditeurs ?

Lors du prochain audit de surveillance, la question viendra : comment votre entreprise a-t-elle réagi à Node2Shell ? Un auditeur attend quatre éléments : un inventaire des systèmes concernés, une décision d'évaluation documentée, la date du correctif par système et la preuve que la nouvelle version tourne effectivement. Pour les systèmes que vous n'avez pas pu corriger immédiatement, une exception justifiée et assortie d'un délai complète la liste.

Un exemple : une entreprise SaaS de 40 personnes exploite trois services sous Node.js 22 dans neuf images de conteneurs. Les runners de CI tournent encore sous Node.js 20 et une agence gère le site marketing. L'équipe reconstruit les images le jour de la publication et migre les runners de CI vers Node.js 24 la semaine suivante, car la version 20 ne reçoit plus de correctif. L'agence confirme par e-mail que son hébergeur a appliqué le correctif. Si des tickets horodatés et la confirmation de l'agence sont rattachés au processus de gestion des vulnérabilités, la question de l'auditeur trouve vite sa réponse.

Les versions en fin de vie sont souvent le point où les audits bloquent. Une branche sans support n'est pas un problème ponctuel lié à cette faille, mais un risque durable qui a sa place dans votre registre des risques. Comment gérer une fin de support fixée à l'avance, notre article sur la fin de vie de PHP 8.2 le montre à l'exemple d'un autre environnement d'exécution.

Que prévoit le RGPD si des données personnelles sont concernées ?

Le RGPD s'applique indépendamment de NIS2. Si des attaquants ont accédé via Node2Shell à des données clients, des identifiants ou d'autres données à caractère personnel, il s'agit d'une violation de données à caractère personnel. Selon l'article 33 du RGPD, elle doit être notifiée à l'autorité de contrôle compétente dans les 72 heures, sauf si elle n'est pas susceptible d'engendrer un risque pour les personnes concernées.

Comme la faille permet aussi de lire le contenu de la mémoire, impliquez votre DPO tôt, et pas seulement une fois l'analyse technique terminée. Quand la notification est obligatoire et ce qui doit se passer dans la première heure, notre article sur la notification des violations de données l'explique.

Comment prouver la correction automatiquement ?

Après une faille comme Node2Shell, il ne suffit pas de corriger : vous devez aussi le prouver lors de l'audit. Selon Aikido Security, sa plateforme signale les versions de Node.js concernées dans les dépôts et les images de conteneurs, et son tableau de bord indique quels services utilisent encore un environnement d'exécution vulnérable. La première étape, l'inventaire, est ainsi couverte pour votre propre code.

Grâce à l'intégration entre Aikido et Kertos, Kertos lit chaque jour ces résultats ainsi que les délais de correction que vous avez fixés. Si aucun délai n'est dépassé, le contrôle est réussi et Kertos enregistre le résultat comme preuve pour les exigences correspondantes d'ISO 27001, de NIS2 et du rapport SOC 2. La connexion fonctionne en lecture seule et ne modifie rien dans Aikido.

Pour votre audit, cela signifie que la preuve de la date de découverte et de la date de correction d'une vulnérabilité naît là où le travail est fait. Les experts certifiés de Kertos vous aident à mettre en place vos processus de gestion des vulnérabilités, des fournisseurs et des incidents pour qu'ils tiennent aussi face à la prochaine faille critique. Si vous souhaitez voir à quoi cela ressemble dans votre environnement, réservez une démo.

Questions fréquentes

Qu'est-ce que Node2Shell ?

Node2Shell est le nom de CVE-2026-111497, une écriture hors limites dans le décodeur Brotli de Node.js. Sans authentification et à distance, un attaquant peut faire planter le processus, lire le contenu de la mémoire ou exécuter du code. Node.js a publié des versions corrigées le 21 octobre 2026.

Suis-je concerné par CVE-2026-111497 ?

Vous êtes concerné si vous utilisez Node.js 22, 24 ou 26 dans une version antérieure à 22.23.4, 24.22.1 ou 26.12.1, ou une branche en fin de vie. Comme la cause se trouve dans la bibliothèque Brotli de Google, Bun, .NET, Envoy, Istio, les clients HTTP Python, FFmpeg, Apache Arrow et ClickHouse peuvent aussi être concernés. Vérifiez également si vos fournisseurs SaaS et hébergeurs ont appliqué le correctif.

Quelle version de Node.js est sûre ?

Node.js 26.12.1, 24.22.1 et 22.23.4 sont les versions minimales qui corrigent Node2Shell. Node.js a annoncé de nouvelles versions de sécurité pour le 11 novembre 2026, utilisez donc la dernière version corrective de votre branche. Pour Bun, le minimum est la version 1.4.4.

Que faire si nous utilisons encore Node.js 20 ?

Node.js 20 est en fin de vie et ne reçoit aucun correctif pour Node2Shell, pas plus que les versions 23 et 25. Passez à Node.js 22, 24 ou 26 et, d'ici là, bloquez au niveau du proxy les requêtes portant « Content-Encoding: br ». Ce que vous ne pouvez pas migrer immédiatement doit être documenté dans votre registre des risques comme exception assortie d'un délai.

Dois-je notifier Node2Shell au titre de NIS2 ou du RGPD ?

Pas du seul fait que vos systèmes présentaient la vulnérabilité. Au titre de NIS2, seul un incident important doit être notifié : alerte précoce dans les 24 heures, notification d'incident dans les 72 heures et rapport final au plus tard un mois après. Si des données à caractère personnel sont concernées, le délai de 72 heures de l'article 33 du RGPD s'applique en plus.