Qu'est-ce que Node2Shell exactement ?

Node2Shell est le nom donné par la communauté sécurité à CVE-2026-111497, une vulnérabilité critique (CVSS 9.2) dans le décodeur Brotli utilisé par Node.js. Un flux de données compressé au format Brotli, conçu de façon malveillante, peut provoquer une écriture hors limites (buffer overflow) qui corrompt la mémoire adjacente du décodeur, pouvant aller jusqu'à l'exécution de code à distance.

Mon site Node.js est-il automatiquement vulnérable si j'utilise Express ou Next.js ?

Pas nécessairement : la faille touche le décodeur Brotli intégré à Node.js lui-même, pas Express ou Next.js directement. Mais si votre serveur accepte et décompresse des requêtes compressées en Brotli (comportement par défaut de nombreux frameworks et reverse proxies), vous êtes exposé si votre version de Node.js n'est pas à jour.

Pourquoi ma version Node.js n'apparaît-elle pas dans les en-têtes de mon site ?

C'est volontaire et c'est une bonne pratique : contrairement à PHP, Node.js n'expose pas sa version par défaut dans les réponses HTTP. Cela rend la vérification à distance plus difficile — c'est pourquoi, en l'absence de version lisible, un scanner honnête doit indiquer une présence probable plutôt que d'inventer un numéro de version.

La mise à jour Node.js va-t-elle interrompre mon service ?

Les correctifs de cette faille (22.23.4, 24.22.1, 26.12.1) sont des mises à jour mineures au sein de leur branche respective, pas des sauts de version majeure : elles ne changent pas le comportement du runtime, seulement le code du décodeur Brotli. Le risque de régression est donc faible, mais un redémarrage du service applicatif est nécessaire pour charger le nouveau binaire.

Node2Shell (CVE-2026-111497) : comment corriger ?

Pour corriger Node2Shell, mettez à jour Node.js vers la version 22.23.4, 24.22.1 ou 26.12.1 selon votre branche (22.x, 24.x ou 26.x). Node2Shell est le nom donné par la communauté sécurité à CVE-2026-111497, une faille critique (CVSS 9.2) du décodeur Brotli intégré à Node.js, révélée le 21 octobre 2026 par la fondation Node.js. Elle permet l'exécution de code à distance via un flux de données compressé malveillant.

Qu'est-ce que Node2Shell ?

Node2Shell désigne une vulnérabilité de type « buffer overflow » (écriture hors limites) dans le décodeur Brotli (c/dec/decode.c) utilisé par Node.js pour décompresser les flux de données au format Brotli — un format de compression courant pour les échanges HTTP, alternative à gzip. Selon la description officielle, un attaquant distant non authentifié peut construire un flux Brotli spécialement conçu pour corrompre la mémoire adjacente au décodeur, ce qui peut provoquer un déni de service, une fuite de données en mémoire, ou dans le pire cas l'exécution de code arbitraire. Le nom « Node2Shell » a été popularisé par l'entreprise de sécurité Imperva, qui a documenté la chaîne complète menant de la donnée Brotli à l'exécution de code.

Mon site Node.js est-il vulnérable à Node2Shell ?

Contrairement à PHP, Node.js n'expose pas sa version dans les en-têtes HTTP par défaut — c'est une bonne pratique de sécurité, mais cela complique la vérification à distance. Si votre site est construit avec Next.js, Express ou un framework Node.js équivalent, et que vous ne connaissez pas la version Node.js active sur votre serveur, voici comment la retrouver :

Accès serveur (SSH) : exécutez node -v directement sur le serveur ou dans votre pipeline de déploiement.
Panneau d'hébergement ou plateforme (Vercel, Render, Railway, VPS managé) : la version Node.js est généralement affichée dans les réglages du projet ou de l'environnement d'exécution.
Scan passif : à défaut d'une version lisible, un scanner honnête comme ScanMonSite déduit la présence de Node.js (via Express, Next.js ou une bannière explicite) et vous indique que la version doit être vérifiée manuellement, plutôt que de deviner un numéro inexistant.

Quelles versions Node.js sont corrigées ?

Le correctif a été publié le 21 octobre 2026 pour les trois branches actives concernées :

Branche Node.js 22.x → corrigée en version 22.23.4
Branche Node.js 24.x → corrigée en version 24.22.1
Branche Node.js 26.x → corrigée en version 26.12.1

Aucune autre branche (23.x, 25.x, versions antérieures à 22) n'est documentée comme corrigée par l'avis officiel : si votre site tourne dessus, traitez la situation comme indéterminée et consultez directement l'avis Node.js pour le détail.

Pourquoi une faille dans la compression Brotli est-elle aussi grave ?

Brotli est un format de compression conçu par Google, massivement utilisé sur le web comme alternative plus efficace à gzip : la plupart des serveurs web et reverse proxies l'activent par défaut pour réduire la taille des réponses HTTP, et de nombreux clients HTTP l'annoncent automatiquement comme accepté (en-tête Accept-Encoding: br). Le décodeur Brotli fait donc partie du chemin de traitement d'un nombre considérable de requêtes, souvent sans que les équipes de développement n'y pensent explicitement — contrairement à une bibliothèque applicative qu'on choisit et audite consciemment. Un bug mémoire dans ce décodeur expose donc une surface d'attaque large et peu visible : selon la description technique de la faille, un flux Brotli conçu de façon malveillante peut corrompre la mémoire adjacente au décodeur lors de la décompression, avant même que le code applicatif ne reçoive la moindre donnée. C'est cette combinaison — composant omniprésent, activé par défaut, difficile à désactiver sélectivement — qui explique le score CVSS de 9.2 (critique) attribué à cette vulnérabilité.

Comment corriger Node2Shell étape par étape ?

Identifiez la version Node.js active sur votre serveur de production (node -v ou réglages de votre plateforme d'hébergement).
Si elle est antérieure à la version corrigée de sa branche, planifiez une mise à jour — via votre gestionnaire de version Node (nvm, fnm), l'image Docker de base de votre conteneur, ou les réglages de votre plateforme (Vercel, Render…).
Testez votre application sur un environnement de préproduction si possible : ce sont des mises à jour mineures au sein d'une même branche, le risque de régression est faible.
Redéployez et redémarrez le processus applicatif pour charger le binaire Node.js corrigé — une mise à jour du fichier source ne suffit pas, le runtime doit être effectivement relancé.
Vérifiez après coup que le service répond normalement.

Selon votre mode de déploiement

Vercel : la version Node.js se règle dans les paramètres du projet (Settings → General → Node.js Version) ; sélectionnez la version corrigée disponible, puis redéployez.
VPS avec PM2 ou systemd : mettez à jour le runtime via votre gestionnaire de version (nvm install 22.23.4 par exemple), pointez votre service vers ce binaire, puis redémarrez le processus (pm2 restart ou systemctl restart).
Conteneur Docker : changez le tag de l'image de base dans votre Dockerfile (ex. node:22-alpine pointe automatiquement vers la dernière version mineure de la branche 22 une fois l'image reconstruite) et redéployez une nouvelle image — un conteneur déjà démarré ne se met pas à jour tout seul.
Plateforme managée (Render, Railway…) : la version Node.js se règle généralement via un fichier de configuration du projet (package.json champ engines, ou variable d'environnement dédiée) — consultez la documentation de votre plateforme pour le nom exact du réglage.

Comment limiter le risque sur la durée côté Node.js ?

Node2Shell ne sera pas la dernière faille critique du runtime Node.js ou de ses dépendances. S'abonner au flux officiel des annonces de sécurité Node.js permet d'être informé dès la publication d'un correctif plutôt que de le découvrir après coup. Au niveau de l'infrastructure, limiter les versions Node.js utilisées en production aux branches LTS (Long Term Support) activement maintenues, automatiser la mise à jour des images de base dans vos pipelines de déploiement, et surveiller les avertissements npm audit sur vos dépendances complètent une hygiène de sécurité raisonnable pour une application Node.js exposée publiquement.

Pour les détails techniques complets, consultez l'avis officiel Node.js du 21 octobre 2026 ou la fiche CVE-2026-111497 sur NVD.