Node.js TLS : plusieurs écritures d’une IP, deux décisions de sécurité

Correctifs publiés le 21 octobre 2026. Trois vulnérabilités de Node.js, CVE-2026-105483, CVE-2026-106069 et CVE-2026-106072, partagent un défaut de conception : le code qui décide où se connecter et celui qui décide quel certificat accepter n’interprètent pas toujours une écriture d’adresse IP de la même façon. Le bulletin Node.js fournit des exemples concrets. La leçon ne se limite pas à TLS : toute autorisation portant sur un nom doit utiliser la même identité canonique que l’opération réelle.

Une connexion possède deux noms potentiels

Un client TLS reçoit une chaîne de caractères représentant l’hôte. La couche réseau la résout en adresse de destination ; la vérification du certificat compare ensuite l’hôte annoncé aux subjectAltName du certificat. Pour une adresse IP, la validation devrait utiliser une entrée SAN de type IP Address. Une entrée SAN de type DNS portant des chiffres qui ressemblent à une IP n’est pas équivalente. Si le résolveur et le validateur classent différemment la même chaîne, le certificat peut être vérifié pour une identité différente de la machine effectivement contactée.

Pour CVE-2026-105483, des chiffres Unicode de pleine chasse comme １２７.0.0.1 sont normalisés vers une IPv4 pour la connexion, mais tls.checkServerIdentity() ne les reconnaissait pas comme une IP. Il pouvait alors accepter un certificat dont le SAN était une chaîne DNS numérique, voire un motif DNS, sans SAN IP correspondant. Le défaut est une confusion de type d’identité, pas une cassure cryptographique de TLS.

Pour CVE-2026-106069, l’exemple 0127.0.0.1 montre une autre divergence : certaines règles de normalisation WHATWG lisent l’octet préfixé par zéro en octal, tandis qu’un résolveur système sur certaines plateformes le traite comme décimal. Le client peut alors vérifier un certificat pour 87.0.0.1 tout en se connectant effectivement à 127.0.0.1. Ce résultat dépend de la plateforme : Node.js cite notamment les différences de résolveur comme condition.

Pour CVE-2026-106072, des notations telles que 0x7f.0.0.1, 2130706433 ou 127.1 pouvaient être acceptées comme adresses IP par la connexion mais vérifiées à tort comme noms DNS. Le projet Node.js souligne une précondition importante : l’attaque demande un certificat de confiance comportant un SAN DNS numérique approprié et un résolveur acceptant cette notation. Un simple certificat auto-signé arbitraire ne suffit pas dans une application qui valide normalement sa chaîne de confiance.

Comment tester correctement cette classe de bug

Un test autorisé crée une matrice de représentations : forme canonique, chiffres Unicode, zéros initiaux, hexadécimal, entier unique et forme abrégée. Pour chacune, il enregistre l’adresse effectivement jointe et l’identité utilisée par le contrôle du certificat. Il faut des certificats de laboratoire dont les SAN DNS et SAN IP sont volontairement différents ; sinon un test qui « réussit » peut masquer le décalage. Le résultat attendu est que la validation s’applique au même endpoint que la connexion, avec le bon type de SAN.

Les correctifs sont dans Node.js 22.23.4, 24.22.1 et 26.12.1 selon la branche. Les bibliothèques qui prévalident des URLs ou des hôtes doivent aussi vérifier leurs propres règles : une mise à jour du runtime ne corrige pas un allowlist applicatif qui accepte une chaîne et en utilise une autre représentation ensuite. Il faut mesurer la surface réelle : applications qui ouvrent des connexions TLS à des hôtes fournis ou influencés par un utilisateur, et celles qui utilisent des règles de destination basées sur le texte de l’hôte.

Ces CVE donnent un exemple net de désaccord entre composants. La garantie de TLS n’a de sens que si la question « quel serveur ai-je contacté ? » reçoit la même réponse à la résolution et à la vérification du certificat.

Source principale : publication de sécurité Node.js du 21 octobre 2026.