Une nouvelle vulnérabilité de sécurité affectant Node.js attire l’attention sur une technologie largement utilisée dans l’infrastructure web : Brotli, un algorithme de compression qui contribue à accélérer le chargement des sites et des applications.
Référencée sous le numéro CVE-2026-111497, cette faille concerne le décodeur Brotli intégré à Node.js. Des données compressées spécialement conçues peuvent provoquer une corruption de mémoire dans un processus Node.js vulnérable, avec des conséquences potentiellement graves : interruption du service, exposition de données en mémoire ou, dans certaines circonstances, exécution de code à distance.
Les correctifs ont été publiés dans les mises à jour de sécurité de Node.js du 21 octobre 2026. Cette vulnérabilité concerne les versions non corrigées des branches Node.js 22.x, 24.x et 26.x.
Pour les entreprises qui exploitent des sites web, des API ou des applications côté serveur, la question essentielle n’est pas simplement de savoir si elles utilisent Brotli. Il faut déterminer si leur application peut traiter des données Brotli malveillantes à l’aide d’un décodeur vulnérable.
Cette distinction est particulièrement importante pour les applications développées avec Next.js et d’autres frameworks exécutés sur Node.js.
Brotli : qu’est-ce que c’est et pourquoi est-ce important ?
Brotli est un algorithme de compression développé par Google. Son objectif est de réduire la taille des ressources web afin de les transférer plus rapidement entre les serveurs et les navigateurs.
Les sites modernes utilisent régulièrement la compression pour distribuer leurs fichiers HTML, JavaScript, CSS, leurs polices et d’autres ressources. Des fichiers plus légers consomment moins de bande passante et peuvent améliorer sensiblement les temps de chargement, notamment lorsque la connexion Internet est limitée.
Brotli est aujourd’hui pris en charge par de nombreux navigateurs, serveurs web, réseaux de diffusion de contenu (CDN) et environnements applicatifs.
Mais la compression implique deux opérations distinctes : encoder les données et les décoder. Lorsqu’un logiciel décompresse des données, il doit interpréter correctement leur structure, y compris lorsque celles-ci sont malformées ou volontairement conçues pour provoquer un comportement inattendu.
C’est précisément ce qui rend la vulnérabilité de Node.js préoccupante.
Que sait-on de la vulnérabilité CVE-2026-111497 ?
CVE-2026-111497 est une vulnérabilité du décodeur Brotli fourni avec Node.js. Selon l’avis de sécurité officiel de Node.js, certaines données compressées malformées peuvent provoquer une écriture hors limites dans la mémoire interne du décodeur.
En termes simples, le logiciel peut écrire des données en dehors de la zone mémoire prévue pour une opération donnée.
Selon les conditions d'exploitation, une telle corruption de mémoire peut entraîner plusieurs conséquences :
Déni de service : le processus vulnérable peut planter, interrompant temporairement le fonctionnement de l'application.
Exposition de données : certaines informations présentes dans la mémoire du processus pourraient être divulguées.
Exécution de code à distance : dans certaines circonstances, un attaquant pourrait parvenir à exécuter du code au sein du processus compromis.
La faille a été classée comme présentant une gravité élevée dans l'avis de sécurité de Node.js.
Un point mérite toutefois d'être souligné : l'exploitation nécessite que des données Brotli contrôlées par un attaquant atteignent le décodeur vulnérable. Un site web n'est donc pas automatiquement vulnérable simplement parce qu'il diffuse ses ressources avec une compression Brotli.
Cette différence est essentielle pour évaluer le risque réel.
Pourquoi les applications Next.js peuvent-elles être concernées ?
Next.js est un framework React utilisé pour développer des sites web, des applications web et des expériences rendues côté serveur. Dans un déploiement classique sur Node.js, Next.js s'appuie sur cet environnement d'exécution pour accéder à des fonctionnalités fondamentales, notamment les communications réseau, le système de fichiers et les opérations de compression.
Une vulnérabilité dans le runtime peut donc affecter une application même lorsque son propre code ne contient aucune faille évidente.
Prenons un scénario simplifié :
Une application accessible depuis Internet reçoit des données provenant d'une source externe.
L'application ou l'une de ses dépendances tente de décompresser ces données avec le décodeur Brotli de Node.js.
Un attaquant transmet des données malformées conçues pour exploiter la vulnérabilité.
Le processus vulnérable peut subir une corruption de mémoire, avec des conséquences potentiellement plus graves.
L'exposition réelle dépend du fonctionnement de l'application, des bibliothèques utilisées et de l'environnement dans lequel elle est déployée.
Tous les sites Next.js sont-ils vulnérables ?
Non.
Un site Next.js qui se contente de servir des pages et des fichiers compressés ordinaires n'est pas automatiquement exposé à ce scénario d'attaque. Le problème concerne le décodage de données Brotli malveillantes, et non la simple diffusion de ressources compressées.
Cependant, il serait imprudent de considérer une application comme sûre sans vérifier son environnement. Certaines bibliothèques, fonctionnalités personnalisées, routes de traitement des données ou intégrations externes peuvent introduire des chemins de décodage pertinents.
La bonne démarche consiste à vérifier la version de Node.js utilisée en production, à consulter l'avis de sécurité officiel et à appliquer les correctifs nécessaires.
Est-ce la même vulnérabilité que PHP2Shell ?
Non. Les deux incidents concernent des composants logiciels différents, même s'ils illustrent un risque commun : les conséquences potentiellement graves d'une mauvaise gestion des données non fiables.
En octobre 2026, PHP a également fait l'objet de deux divulgations de sécurité importantes, référencées sous les numéros CVE-2026-109618 et CVE-2026-109619, et évoquées collectivement sous le nom de PHP2Shell.
Ces vulnérabilités affectent le runtime PHP et impliquent d'autres problèmes de gestion de la mémoire. Selon les conditions d'exploitation, elles peuvent notamment permettre une exécution de code à distance ou la divulgation d'informations présentes dans la mémoire du processus.
La vulnérabilité Brotli, quant à elle, concerne le décodeur intégré à Node.js.
Cette comparaison rappelle une réalité importante : la sécurité d'un site web ne dépend pas uniquement de son code applicatif. Elle repose également sur les runtimes, les bibliothèques et les composants d'infrastructure utilisés pour le faire fonctionner.
Une application peut être correctement développée tout en restant exposée à une faille provenant d'un composant sous-jacent.
Quelles versions de Node.js sont concernées ?
L'avis de sécurité publié par Node.js le 21 octobre 2026 identifie les branches suivantes et les versions corrigées correspondantes.
Branche Node.js Versions concernées Version corrigée minimale Node.js 22.x Versions antérieures à 22.23.4 22.23.4 Node.js 24.x Versions antérieures à 24.22.1 24.22.1 Node.js 26.x Versions antérieures à 26.12.1 26.12.1
Ces versions correspondent aux correctifs minimaux indiqués dans l'avis concerné. Il est préférable d'installer la dernière version de sécurité disponible pour la branche prise en charge, plutôt que de considérer ces numéros comme des objectifs définitifs.
Les anciennes branches qui ne sont plus prises en charge nécessitent une attention particulière. Elles peuvent ne plus recevoir les mêmes correctifs de sécurité. Les entreprises concernées devraient donc prévoir une migration vers une version maintenue.
Enfin, ces mises à jour corrigent CVE-2026-111497. Elles ne garantissent pas que toutes les autres vulnérabilités éventuelles de Node.js ou de Next.js soient également résolues.
Comment vérifier si votre application est concernée ?
Il n'est pas nécessaire de commencer par un audit complet de sécurité. Les premières vérifications consistent à identifier l'environnement d'exécution réellement utilisé en production.
1. Vérifier la version de Node.js
Dans le terminal de votre projet, exécutez :
node --version
Comparez le résultat aux versions corrigées présentées dans le tableau précédent.
Gardez à l'esprit que la version installée sur l'ordinateur d'un développeur peut être différente de celle utilisée sur le serveur de production.
2. Vérifier l'environnement de production
Identifiez la version réellement utilisée par votre application déployée.
Selon votre architecture, il peut s'agir :
D'un processus Node.js exécuté directement sur un serveur privé virtuel (VPS).
D'une installation Node.js intégrée à un conteneur Docker.
D'un environnement d'hébergement applicatif géré.
D'une plateforme de déploiement qui sélectionne elle-même le runtime.
Pour Docker, vérifiez la version de Node.js dans l'image utilisée en production, et pas uniquement celle installée sur le serveur hôte.
Pour un hébergement géré, vérifiez si la plateforme a mis à jour son environnement et si votre application impose une version spécifique.
3. Examiner les dépendances et les opérations de décompression
Vérifiez si votre code ou vos dépendances utilisent explicitement des fonctionnalités de décompression Brotli, notamment celles exposées par les API node:zlib de Node.js.
Examinez également les routes qui traitent des fichiers envoyés par les utilisateurs, des contenus externes, des données compressées ou des informations récupérées auprès de services tiers.
L'objectif est de déterminer si des données contrôlées par un attaquant peuvent atteindre le décodeur vulnérable. Cette analyse complète la mise à jour du runtime, mais ne la remplace pas.
4. Mettre à jour et redéployer
Installez la version corrigée de Node.js adaptée à votre environnement, puis reconstruisez ou redéployez l'application lorsque cela est nécessaire.
Redémarrez les processus ou les conteneurs concernés afin qu'ils utilisent effectivement la nouvelle version. Installer une mise à jour sur un serveur ne remplace pas automatiquement un processus déjà en cours d'exécution ni une ancienne image de conteneur.
Enfin, vérifiez la version utilisée en production et assurez-vous que l'application fonctionne normalement.
Quelles précautions prendre pour les projets Next.js ?
Pour les projets Next.js, la maintenance de sécurité doit couvrir séparément le framework et son environnement d'exécution.
Mettre à jour Node.js. Si votre application utilise une version concernée, la mise à jour vers une version corrigée constitue la principale mesure de protection contre cette vulnérabilité.
Consulter les avis de sécurité Next.js. Vérifiez si votre version du framework comporte d'autres vulnérabilités ou nécessite une mise à jour indépendante. Appliquez les correctifs recommandés par les avis correspondants.
Examiner la configuration de déploiement. Une application peut fonctionner avec une version récente de Node.js en développement tout en utilisant une version plus ancienne dans un conteneur ou sur sa plateforme d'hébergement.
Contrôler les données non fiables. Portez une attention particulière aux fonctionnalités qui décompressent des données, traitent des fichiers envoyés par les utilisateurs ou transmettent des contenus externes aux API du runtime.
Surveiller l'activité de l'application. Examinez les journaux du serveur et les alertes de sécurité afin de détecter d'éventuels plantages inhabituels, requêtes suspectes ou autres signes d'activité malveillante.
Si des indices d'exploitation sont détectés, installer le correctif ne suffit pas nécessairement. Il faut également déterminer si des identifiants, des jetons d'authentification ou d'autres informations sensibles ont pu être exposés.
Et si votre application utilise Bun ?
Bun est un environnement d'exécution JavaScript distinct de Node.js. Il dispose de ses propres implémentations et intégrations, tout en assurant la compatibilité avec de nombreuses API de Node.js.
Il ne faut donc pas considérer automatiquement les deux environnements comme identiques.
Si votre application fonctionne avec Bun, consultez les avis de sécurité propres à Bun et vérifiez si la fonctionnalité concernée existe dans la version installée.
Un numéro de version corrigé pour Node.js ne constitue pas un correctif pour Bun. Inversement, utiliser Bun ne garantit pas l'absence de risque sans vérification de l'avis correspondant et de l'implémentation concernée.
Dans tous les cas, il est essentiel de maintenir à jour le runtime, les dépendances et les images de déploiement.
Désactiver Brotli suffit-il à éliminer le risque ?
Pas nécessairement.
La vulnérabilité concerne le décodage de données Brotli malformées. Désactiver la compression des réponses au niveau du serveur web ou du CDN ne garantit pas que l'application cessera d'utiliser un décodeur vulnérable en interne.
Si un chemin de traitement vulnérable est identifié, en restreindre temporairement l'accès peut contribuer à réduire l'exposition pendant la préparation d'un correctif. Ces mesures doivent toutefois correspondre à l'architecture réelle de l'application.
La solution prioritaire reste la mise à jour vers une version corrigée du runtime. Les changements de configuration ne doivent pas être considérés comme un remplacement de cette mise à jour.
Que doivent faire les entreprises dès maintenant ?
La réponse dépend de l'environnement technique, mais les priorités restent les mêmes.
Identifier : recenser les applications de production utilisant Node.js 22.x, 24.x ou 26.x et déterminer les versions effectivement installées.
Corriger : mettre à jour les environnements concernés vers les versions de sécurité appropriées.
Vérifier : confirmer que les processus de production et les images de conteneurs utilisent bien les versions corrigées.
Examiner : identifier les chemins applicatifs qui décompressent des données Brotli contrôlées par des sources non fiables.
Surveiller : analyser toute activité inhabituelle et évaluer une éventuelle exposition en présence de signes d'exploitation.
Maintenir : mettre en place un processus régulier de suivi des avis de sécurité et de mise à jour des runtimes et des dépendances.
Pour les systèmes accessibles depuis Internet, il est judicieux de commencer par les services exposés et ceux qui traitent des données non fiables.
Si une application ne peut pas être corrigée immédiatement, évaluez son exposition réelle et envisagez des restrictions temporaires sur les fonctionnalités concernées. Lorsque le risque ne peut pas être suffisamment maîtrisé, une interruption temporaire du service peut être nécessaire jusqu'à la mise en place du correctif.
La leçon essentielle : la sécurité dépasse le code de l'application
Les applications web modernes reposent sur plusieurs couches logicielles. Un déploiement classique peut inclure un framework frontend, un runtime côté serveur, des bibliothèques tierces, une image de conteneur, un proxy inverse, un CDN et un système d'exploitation.
Une vulnérabilité dans un seul de ces composants peut affecter la sécurité de l'ensemble de l'application, même si le code applicatif n'a subi aucune modification.
C'est pourquoi la sécurité ne se limite pas à l'ajout d'une authentification, à la validation des formulaires ou à l'écriture d'une logique métier sécurisée. Ces pratiques restent indispensables, mais elles doivent s'accompagner d'une infrastructure maintenue et d'un processus fiable de mise à jour.
Pour les dirigeants d'entreprise, cela signifie que la sécurité doit faire partie de la maintenance continue du site web, et non être considérée comme une tâche ponctuelle réalisée lors de sa mise en ligne.
Pour les équipes techniques, le principe est tout aussi concret : connaître la version du runtime en production, savoir comment elle est mise à jour et vérifier que les correctifs atteignent effectivement les systèmes déployés.
Conclusion
La vulnérabilité CVE-2026-111497 du décodeur Brotli rappelle que des composants d'infrastructure largement utilisés peuvent introduire des risques de sécurité importants. Comme Node.js constitue la base de nombreuses applications côté serveur, notamment les déploiements classiques de Next.js, les équipes doivent vérifier leur exposition et appliquer rapidement les mises à jour nécessaires.
Il ne s'agit pas d'abandonner Brotli, Node.js ou Next.js. Il s'agit de les maintenir correctement.
Une réponse efficace repose sur trois éléments : appliquer les correctifs sans délai, comprendre comment les données non fiables circulent dans l'application et vérifier l'environnement de production.
Ces pratiques permettent aux entreprises de réduire les risques sans imposer de changements architecturaux inutiles.
Chez Hamo, nous sommes convaincus qu'un produit numérique fiable ne repose pas uniquement sur des fonctionnalités pertinentes et une interface soignée. Il dépend également de la rigueur technique nécessaire pour maintenir des systèmes sécurisés, à jour et capables d'évoluer.
Sources officielles
Les informations de sécurité présentées dans cet article reflètent les avis disponibles au 24 octobre 2026. Consultez les avis des éditeurs pour prendre connaissance des éventuelles mises à jour ultérieures.
