Node.js : quatre failles de sécurité élevées, dont une RCE via Brotli
Le projet Node.js a publié le 21 octobre 2026 une mise à jour de sécurité pour ses branches 22.x, 24.x et 26.x. Elle corrige quatre vulnérabilités classées élevées, dont une écriture hors limites dans le décodeur Brotli pouvant permettre une exécution de code à distance.

À retenir : l’avis officiel classe le niveau maximal de cette publication en gravité élevée, et non critique. L’impact concret de la faille Brotli dépend de la possibilité pour une entrée contrôlée par un tiers d’atteindre le décodeur vulnérable.
Une erreur de mémoire dans le décodeur Brotli
Brotli est un format de compression utilisé pour réduire la taille des données échangées. Lorsqu’un programme décompresse un flux, il transforme les données compactées en contenu exploitable par l’application. Dans les versions vulnérables de Node.js, un défaut du décodeur peut provoquer une écriture hors des limites prévues en mémoire (out-of-bounds write).
Selon l’avis du projet Node.js, cette corruption mémoire peut permettre l’exécution de code à distance (CVE-2026-111497). Cela ne signifie pas que toute application Node.js est automatiquement exploitable : il faut notamment que le processus traite un contenu Brotli pouvant être influencé par un attaquant. Le niveau d’exposition dépend de l’application, des chemins de données et des protections déjà en place.

Pourquoi la compression mérite une attention particulière
La taille réduite d’un flux ne décrit pas forcément la quantité de travail ni la mémoire nécessaire à son décodage. Le composant qui décompresse les données fait donc partie de la surface d’attaque dès que l’application accepte des contenus non fiables.
Les quatre vulnérabilités élevées corrigées
- CVE-2026-111497 — Brotli : écriture hors limites dans le décodeur, avec possibilité d’exécution de code à distance.
- CVE-2026-105482 — DNS :
dns.resolvetronque les noms qui contiennent un caractère NUL. - CVE-2026-105483 — TLS : contournement de la vérification du nom du certificat lorsque l’adresse IP est écrite avec des chiffres pleine chasse. Cette faille concerne les branches 24.x et 26.x.
- CVE-2026-106069 — TLS : contournement de la vérification du nom du certificat lorsque l’hôte est résolu de façon permissive vers une adresse IP.
Les quatre avis concernent les branches Node.js 22.x, 24.x et 26.x, à l’exception de CVE-2026-105483 qui ne concerne que 24.x et 26.x. La publication du 21 octobre inclut aussi d’autres correctifs de gravité moyenne et faible.
Quelles versions installer ?
| Branche | Version corrigeant cet avis |
|---|---|
| Node.js 22.x | 22.23.4 |
| Node.js 24.x | 24.22.1 |
| Node.js 26.x | 26.12.1 |
Ces numéros sont ceux indiqués par l’avis de sécurité du 21 octobre 2026. Si une version corrective plus récente existe au moment de votre déploiement, privilégiez la dernière version maintenue de votre branche. Les branches en fin de vie ne reçoivent pas nécessairement de correctif : migrez vers une branche maintenue.
Vérifier son application et ses images Docker
- Vérifiez le runtime réellement utilisé. Dans un terminal, lancez
node --version. Pour une image Docker, inspectez son Node.js avecdocker run --rm votre-image:tag node --version. - Mettez à jour la base et reconstruisez. Ajustez la version Node.js dans le Dockerfile ou l’image de base, reconstruisez l’image sans réutiliser une couche périmée, puis redéployez-la. Mettre à jour Node.js sur l’hôte ne change pas le runtime déjà embarqué dans une image.
- Contrôlez les artefacts déployés. Vérifiez les images des services web, workers, tâches planifiées et outils internes, ainsi que les images réellement utilisées en production.
- Ajoutez un contrôle à chaque build. Analysez les images produites et bloquez la livraison si un composant contient encore une vulnérabilité dépassant votre seuil de gravité.
- Réduisez l’exposition en attendant le déploiement. Si un service décompresse des contenus non fiables, limitez temporairement cette entrée ou isolez le traitement, puis vérifiez les journaux après mise à jour.

Comment prioriser la correction ?
Commencez par recenser la version présente dans chaque conteneur et chaque processus Node.js. Traitez en priorité les services exposés qui acceptent ou décompressent des données provenant de l’extérieur. La présence d’une version affectée indique qu’une mise à jour est nécessaire ; elle ne prouve pas, à elle seule, qu’une exploitation a eu lieu.
Après le déploiement, vérifiez la version dans l’instance active et conservez le résultat du scan de l’image. Si vous soupçonnez une exploitation, suivez votre procédure de réponse à incident et examinez les événements et journaux pertinents.
Commentaires ()