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

> Trois CVE Node.js montrent comment résolution d’hôte et validation de certificat peuvent interpréter différemment une adresse IP non canonique.

Publié le: 2026-11-04  
Canonical: https://rootzero.eu/research/node-tls-ip-normalisation-certificats-2026/

**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](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) 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](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases) 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](https://nodejs.org/en/blog/vulnerability/october-2026-security-releases).