Faille du décodeur Brotli de Node.js permettant l'exécution de code à distance dans les builds officiels

Des chercheurs en sécurité d'Imperva ont démontré une vulnérabilité critique d'exécution de code à distance dans le runtime officiel Node.js. En soumettant des données de compression Brotli spécifiquement élaborées au décodeur intégré, ils ont réussi à exécuter du code arbitraire sur un build standard Linux arm64 de Node.js 24.22.0. L'équipe Node.js a divulgué cette faille, suivie sous la référence CVE-2026-111497, et a publié des correctifs le 21 octobre, exhortant les développeurs à mettre à jour toute application traitant des flux Brotli non fiables.

Ce qui s'est passé

La démonstration, baptisée « Node2Shell », marque une escalade significative par rapport aux tentatives précédentes de preuve de concept. Les chercheurs antérieurs n'avaient réussi à exécuter du code que sur des builds de test volontairement affaiblis, tandis que les builds standards se contentaient de planter ou permettaient des lectures mémoire limitées. L'équipe d'Imperva, cependant, a exécuté son exploit sur une image officielle de Node.js 24.22.0 sans débogueurs ni modifications personnalisées. Bien que l'exploit ne soit pas déterministe et ait nécessité plusieurs tentatives pour réussir dans leur environnement Linux arm64, il a confirmé qu'une exécution complète du code est possible sur des configurations de production.

Cette vulnérabilité affecte un large éventail d'applications car elle réside dans le décodeur Brotli intégré à Node.js lui-même. Elle impacte les lignes de release actives 22.x, 24.x et 26.x. Le risque est présent chaque fois qu'une application décode des données compressées en Brotli, ce qui peut se produire de deux manières principales : lors de la lecture d'une réponse compressée via l'API fetch() intégrée, ou lorsque un middleware décode explicitement un corps de requête compressé. Par exemple, les parsers de corps Express 5 gèrent désormais Brotli aux côtés de gzip et deflate, ce qui signifie que de nombreux services backend modernes sont exposés s'ils traitent des requêtes entrantes provenant de sources non fiables.

Imperva a testé ce vecteur en utilisant Express 5.0.0 à 5.3.0 et body-parser 2.0.0 à 2.3.0, reproduisant l'exécution de code via les chemins de requête et de réponse. Un serveur HTTP Node.js simple n'est pas vulnérable par défaut, sauf s'il utilise un middleware ou des appels explicites pour décoder le corps. Au 22 octobre, aucun rapport d'exploitation active dans la nature n'avait été signalé, mais la disponibilité d'une preuve de concept fonctionnelle sur des builds officiels augmente l'urgence du patching.

Comment cela fonctionne

La cause profonde réside dans la manière dont le décodeur Brotli intégré gère les transitions d'état invalides au sein d'un flux compressé. Un flux Brotli annonce les types de blocs qu'il utilisera au fur et à mesure du décodage. Dans l'entrée malveillante élaborée par Imperva, le flux atteignait un changement de bloc que sa propre structure excluait explicitement comme impossible. Au lieu de rejeter cette contradiction, le décodeur vulnérable l'a interprétée comme une demande d'entrée supplémentaire et a continué le traitement dans un état invalide.

Lorsque le décodeur continue dans cet état corrompu, il échoue à appliquer les vérifications de limites appropriées. Des tests utilisant un sanitizer de mémoire ont révélé que cette erreur logique conduit à une écriture hors limites (out-of-bounds write), où des données sont écrites au-delà des limites prévues du buffer. Cette corruption mémoire crée une ouverture permettant à un attaquant d'injecter et d'exécuter du code. Le projet Node.js a résolu le problème en important un patch amont de la bibliothèque Brotli. Ce correctif garantit que le décodeur s'arrête immédiatement et renvoie une erreur de format lorsqu'il rencontre de telles contradictions structurelles impossibles, empêchant ainsi l'état invalide de se produire.

Détails clés

• ID de la vulnérabilité : CVE-2026-111497 affecte le décodeur Brotli intégré dans Node.js.
• Versions affectées : Les lignes de release actives 22.x, 24.x et 26.x sont vulnérables ; les versions en fin de vie comme 20.x ne reçoivent pas de correctifs.
• Vecteur d'attaque : Données Brotli élaborées envoyées via les corps de requêtes HTTP (décodés par un middleware) ou reçues via les réponses fetch().
• Fiabilité de l'exploit : La preuve de concept d'Imperva a nécessité plusieurs tentatives pour réussir sur Linux arm64 et n'a pas été testée sur d'autres architectures.
• Statut du correctif : Les patchs ont été publiés le 21 octobre ; la version 24.22.1 rejette les données malveillantes en toute sécurité.
• Aucune solution de contournement à l'exécution : L'avis indique qu'il n'y a aucune modification de configuration dans Node.js pour atténuer ce problème ; la mise à jour est le seul remède.

Pourquoi c'est important

Pour les ingénieurs logiciels et les responsables techniques, cette vulnérabilité met en lumière un risque caché dans les chaînes de dépendances. Parce que la faille se trouve dans le runtime lui-même plutôt que dans un paquet npm tiers, les outils d'inventaire de paquets standards peuvent ne pas la signaler. Les développeurs supposent souvent que les bibliothèques de compression sont des utilitaires sûrs de bas niveau, mais cet incident prouve qu'elles peuvent constituer une voie directe vers l'exécution de code à distance. Les services qui proxifient des API externes ou acceptent des téléchargements d'utilisateurs sont particulièrement à risque s'ils décompressent automatiquement le contenu sans validation stricte.

L'absence de solution de contournement à l'exécution signifie que les équipes opérationnelles ne peuvent pas simplement activer ou désactiver un feature flag pour rester protégées. Si votre infrastructure repose sur des images de conteneurs ou des artefacts pré-construits, vous devez vous assurer que le binaire Node.js sous-jacent est mis à jour. Cela nécessite souvent de reconstruire et de redéployer les services, et non seulement de les redémarrer. De plus, des plateformes comme Vercel ont ajouté des règles de pare-feu d'applications web (WAF) pour bloquer les attaques entrantes, mais celles-ci ne protègent pas contre les réponses Brotli malveillantes récupérées par votre serveur depuis d'autres hôtes, laissant la voie sortante vulnérable jusqu'à ce que le patch soit appliqué.

Ce que vous pouvez faire

• Mettez à jour toutes les instances Node.js vers les dernières versions corrigées des lignes 22.x, 24.x ou 26.x immédiatement.
• Auditez vos images de conteneurs et vos pipelines CI/CD pour vous assurer que le binaire Node.js de base est mis à jour, et non seulement le code de l'application.
• Identifiez les services utilisant Express 5 ou body-parser qui acceptent des corps de requêtes non fiables et priorisez leur patching.
• Revoyez l'utilisation de l'API fetch() intégrée pour vous assurer que les réponses provenant de serveurs externes non fiables sont traitées avec prudence.
• Migrez toute application encore exécutée sur des versions en fin de vie comme 20.x vers une ligne de release prise en charge afin de recevoir les correctifs de sécurité.
• Surveillez les logs pour détecter des plantages inhabituels ou des erreurs mémoire dans les services manipulant des données compressées, ce qui pourrait indiquer une tentative d'exploitation.