Les équipes qui utilisent node-forge pour déchiffrer des données en AES-GCM doivent vérifier leur intégration sans attendre. Une vulnérabilité référencée CVE-2026-119186, publiée par Digital Bazaar le 27 octobre et répertoriée par la base d’avis de GitLab le 30 octobre 2026, concerne toutes les versions de node-forge jusqu’à 1.4.0. Le correctif est disponible dans node-forge 1.4.1.
Le problème se situe dans l’option tagLength utilisée au démarrage du mode AES-GCM. Dans les versions vulnérables, cette valeur n’était pas correctement validée. Si elle vaut 0, ou prend une valeur convertie en 0 comme null, false, une chaîne vide ou « 0 », l’étiquette d’authentification peut devenir vide. Dans cette situation, la fonction de finalisation du déchiffrement peut renvoyer une validation positive même pour un texte chiffré et des données additionnelles arbitraires, si l’étiquette fournie est vide ou absente.
Concrètement, les applications concernées sont celles qui déchiffrent de l’AES-GCM avec node-forge et transmettent une longueur d’étiquette nulle ou assimilée à zéro, notamment lorsqu’elles calculent cette longueur à partir d’une étiquette reçue. Un attaquant capable d’envoyer un texte chiffré avec une étiquette vide pourrait alors faire accepter à l’application des données choisies comme si elles étaient authentiques. L’impact porte donc sur l’intégrité des messages, pas sur une exposition directe de leur confidentialité.
Les développeurs doivent d’abord identifier la version résolue de node-forge dans leurs fichiers de dépendances, leurs fichiers de verrouillage et leurs outils d’analyse de dépendances. Les projets utilisant une version antérieure à 1.4.1 doivent être mis à jour, y compris lorsqu’il s’agit d’une dépendance transitive. Après la mise à jour, il faut tester les parcours de déchiffrement AES-GCM. Le correctif n’accepte plus que les longueurs prévues par NIST, de 128 à 32 bits selon les valeurs autorisées. Une longueur absente utilise 128 bits par défaut. En attendant un déploiement complet, il est recommandé de ne pas dériver tagLength de données reçues, de fixer une valeur valide ou d’omettre cette option, puis de vérifier la longueur de l’étiquette reçue.
