Si vous pensiez que le département marketing en sécurité prenait congé pour le reste de la semaine d'Halloween après PHP2Shell, j'ai une mauvaise nouvelle. Dans les heures suivant la publication des avis PHP le 21 octobre, une deuxième vulnérabilité a été baptisée sur les réseaux sociaux : « Node2Shell ».

Cette fois, la cible est CVE-2026-111497 (), une vulnérabilité de niveau élevé à critique divulguée dans la mise à jour de sécurité Node.js du 21 octobre 2026. Tout comme son cousin PHP2Shell, le nom accrocheur fait beaucoup de travail (Node.js lui-même n'a jamais utilisé le terme « Node2Shell » dans son avis), et une fois encore, la vraie histoire se cache sous le battage médiatique : une faille de corruption mémoire native en C/C++ enfouie sous un langage de script à mémoire sécurisée, prête à remettre à un attaquant les clés de l'identité de service que détient votre environnement d'exécution.

Examinons ce que confirment réellement le registre CVE et les avis officiels, où se situe la véritable exposition, et pourquoi cette semaine est une leçon magistrale en matière de risque lié aux identités de charges de travail.

Ce que dit réellement le registre CVE

Malgré le costume « 2Shell » assorti, CVE-2026-111497 n'est pas un bogue d'injection JavaScript, ni une vulnérabilité exclusive à Node.js. Il s'agit d'une écriture hors limites (CWE-787) dans la bibliothèque de compression Brotli (versions 1.0.3 à 1.2.0) de Google, que Node.js intègre dans son environnement d'exécution.

Voici les faits vérifiés à ce jour :

• La faille : Lorsque le décodeur Brotli traite un flux compressé malformé et conçu à des fins malveillantes, il ne s'arrête pas sur une entrée invalide et écrit au-delà de la fin de son tampon mémoire alloué (corrigé via le commit Brotli amont 0ed4268a).

• Le score : Le registre CVE de Google lui attribue un score CVSS v4.0 de 9,2 (Critique), tandis que l'avis de sécurité Node.js le classe Élevé et avertit explicitement que l'impact inclut l'exécution de code à distance (RCE).

• Les conditions préalables : Votre application est exposée si elle décompresse des données Brotli non fiables. Cela se produit directement si votre code appelle les méthodes de décompression Brotli de node:zlib (zlib.brotliDecompress, createBrotliDecompress) sur des charges utiles fournies par l'utilisateur, ou automatiquement lorsque la fonction native fetch() de Node (Undici) reçoit une réponse HTTP avec Content-Encoding: br provenant d'un serveur amont non fiable ou contrôlé par un attaquant.

• Le rayon de souffle au-delà de Node : Comme le bogue réside dans Brotli en amont, Bun (corrigé dans la version 1.4.4) et les paquets Python Brotli / brotlicffi (corrigés dans la version 1.2.1) ont également publié des mises à jour d'urgence le 22 octobre.

• Versions Node affectées et corrigées : Node.js a corrigé la faille le 21 octobre dans v22.23.4, v24.22.1 et v26.12.1. Fait crucial, Node.js 20 et les versions antérieures ont atteint leur fin de vie et ne recevront pas de correctifs en amont. Cela crée un angle mort opérationnel considérable, étant donné le nombre de conteneurs de production et de fonctions sans serveur qui fixent encore Node 20.

• Statut d'exploitation : Bien que plusieurs dépôts de preuves de concept (PoC) soient apparus sur GitHub le 22 octobre et que des chercheurs aient démontré une exécution de code intermittente sur des conteneurs Node 24 non corrigés, le catalogue Known Exploited Vulnerabilities (KEV) de la CISA () indique toujours que l'exploitation active est « nulle ».

La rivalité entre cousins : pourquoi Node2Shell est encore plus sournois pour l'IAM

Si PHP2Shell était une attaque frontale contre les serveurs web traditionnels et modernes, Node2Shell cible le tissu conjonctif des architectures infonuagiques modernes : les passerelles API, les mandataires de filtrage SSRF, les processeurs de webhooks, les couches Backend for Frontend (BFF) et les orchestrateurs d'agents IA qui exécutent fetch() sur des URL externes pour le compte des utilisateurs.

Et que d'autre figurait dans ce même lot de sécurité Node.js du 21 octobre ?

• CVE-2026-105482 : Une faille de troncature de résolution DNS (dns.resolve*) via des octets NUL incorporés permettant à un attaquant de passer un contrôle de liste d'autorisation pour un domaine tout en interrogeant un autre.

• CVE-2026-106069 et CVE-2026-105483 : Deux contournements de vérification du nom d'hôte TLS (tls.checkServerIdentity) impliquant des adresses IP non canoniques et en pleine largeur Unicode.

• CVE-2026-106073 : Un contournement dans fs.realpathSync contre le modèle de permissions intégré de Node.

En combinant tout cela, on voit la chaîne idéale pour un attaquant : contourner une liste d'autorisation d'URL ou un contrôle TLS pour inciter un service Node.js à récupérer un point de terminaison contrôlé par l'attaquant, retourner une charge utile Content-Encoding: br malveillante, déclencher l'écriture hors limites Brotli dans le code C natif, et franchir directement le bac à sable de JavaScript.

Le butin en matière d'identité dans un processus Node.js

Une fois qu'un exploit atterrit dans un processus Node.js, l'attaquant n'a pas besoin de déposer un web shell .php classique sur le disque (MITRE ATT&CK T1505.003) puisque process.env est déjà présent en mémoire. Dans les environnements de microservices et sans serveur modernes, un environnement d'exécution Node compromis est une mine d'or pour les identités :

• Prolifération de process.env : Entrez dans presque n'importe quel conteneur Node.js et videz les variables d'environnement. Vous y trouverez AWS_SECRET_ACCESS_KEY, DATABASE_URL, STRIPE_SECRET_KEY, des clés de signature JWT internes et des jetons OAuth tiers en texte clair en mémoire.

• Identité de charge de travail infonuagique et métadonnées : Si ce service Node s'exécute dans Kubernetes ou ECS sans délimitation stricte du rôle de pod ou de tâche, ou sur EC2 avec IMDSv1 activé (), un attaquant qui détourne le processus Node hérite immédiatement du rôle IAM infonuagique attaché au nœud de calcul.

• Confiance sortante par défaut : Contrairement aux processus PHP traditionnels qui ont rarement besoin d'appeler des URL externes, les services Node sont conçus pour communiquer avec tout le monde. Une charge utile malveillante s'exécutant dans le binaire node se fond parfaitement dans le trafic HTTPS sortant normal, à moins d'appliquer un filtrage de sortie strict et des jetons à courte durée de vie liés à une audience.

Ce qu'il faut faire avant lundi

Premièrement, corrigez l'environnement d'exécution, pas seulement votre package.json. Comme Brotli est compilé dans le binaire Node.js lui-même, npm audit fix ne vous sauvera pas. Vous devez reconstruire vos images de conteneur de base et mettre à niveau les environnements d'exécution vers Node.js 22.23.4, 24.22.1 ou 26.12.1 (et Bun 1.4.4 ou Brotli 1.2.1 selon le cas). Si vous êtes toujours sur Node 20, c'est votre signal d'alarme indiquant que la fin de vie signifie une RCE non corrigée.

Deuxièmement, si vous ne pouvez pas corriger un service ce soir et qu'il récupère des URL externes non fiables ou accepte des téléversements compressés, supprimez br des en-têtes Accept-Encoding sortants et bloquez les Content-Encoding: br entrants au niveau de votre WAF ou mandataire inverse jusqu'à la mise à jour de l'environnement d'exécution.

Enfin, utilisez PHP2Shell et Node2Shell comme exercice de simulation à double utilité pour votre équipe d'identité. Deux langages entièrement différents et deux bogues mémoire C natifs ont été publiés le même jour, et les deux se terminent par la même question : « Lorsque l'environnement d'exécution est piégé pour exécuter le code d'un inconnu, quelles permissions avons-nous laissées traîner pour qu'il en hérite ? »

Réduisez le rôle IAM, sortez les secrets à longue durée de vie de process.env et auditez vos identités machine. La semaine prochaine, il y aura un autre bogue « 2Shell », et il ne se souciera pas du langage dans lequel vous avez écrit votre application.