{"id":"CVE-2026-106069","kind":"vulnerability","aliases":["CVE-2026-106069"],"related":[],"title":"Node.js: TLS check accepts wrong IP certificate for leading-zero addresses","description":"A flaw in Node.js TLS hostname verification can cause a server certificate to be validated against a different IP address than the one the client connected to, when the host is a non-canonical IPv4 literal with a leading zero, such as `0127.0.0.1`.\n\n`tls.checkServerIdentity()` normalizes the host following the WHATWG URL rules, which read a leading-zero octet as octal (`0127.0.0.1` becomes `87.0.0.1`), while the connection is made through the operating system resolver, which on some platforms such as macOS reads it as decimal (`127.0.0.1`). A server at the connected address can then be authenticated with a certificate issued for another IP address.\n\nThis vulnerability affects Node.js **26.x**, **24.x**, and **22.x**.","summary":"Node.js normalizes a non-canonical IPv4 literal with a leading zero (such as 0127.0.0.1) differently in its certificate hostname check than the OS resolver does when connecting. A man-in-the-middle at the connected address can present a certificate issued for a different IP and be accepted as authentic.","severity":"high","cvss":7.4,"epss":0.00238,"exploited":false,"exploited_at":null,"products":[],"ecosystems":[],"tags":["backend","macos","node.js","poc-public","runtime","tls-clients"],"not_affected_if":["canonical-ip-literals","hostnames-only","node-18-or-older"],"how_to_check":"- Run `node --version` and compare against the affected lines 22.x, 24.x and 26.x\n- Check whether the application makes TLS connections to host literals written with leading zeros, which is unknown from the sources\n- Check whether the team runs Node.js on macOS, where the sources say the OS resolver reads the octet as decimal","fix":"- Upgrade Node.js to a patched release on your line; the exact fixed versions are unknown from the sources\n- Avoid passing IPv4 literals with leading zeros to TLS clients until patched","status":"open","published_at":"2026-10-23T17:17:19+00:00","first_seen_at":"2026-10-23T21:57:34+00:00","triaged_at":"2026-10-25T03:25:29+00:00","updated_at":"2026-10-25T12:38:50+00:00","category":"runtime","confidence":0.6,"triage":{"at":"2026-10-25T03:25:29Z","model":"claude-haiku-5-5","output":{"fix":"- Upgrade Node.js to a patched release on your line; the exact fixed versions are unknown from the sources\n- Avoid passing IPv4 literals with leading zeros to TLS clients until patched","reach":"network","title":"Node.js: TLS check accepts wrong IP certificate for leading-zero addresses","impact":"medium","summary":"Node.js normalizes a non-canonical IPv4 literal with a leading zero (such as 0127.0.0.1) differently in its certificate hostname check than the OS resolver does when connecting. A man-in-the-middle at the connected address can present a certificate issued for a different IP and be accepted as authentic.","category":"runtime","nicknames":[],"who_cares":["node.js","backend","macos","tls-clients"],"confidence":0.6,"needs_auth":"no","worst_case":"Attacker at the connected address impersonates the server using a wrong-IP certificate","analyst_note":"Find the patched Node.js versions per release line and confirm the OS resolver behaviour at https://nvd.nist.gov/vuln/detail/CVE-2026-106069","how_to_check":"- Run `node --version` and compare against the affected lines 22.x, 24.x and 26.x\n- Check whether the application makes TLS connections to host literals written with leading zeros, which is unknown from the sources\n- Check whether the team runs Node.js on macOS, where the sources say the OS resolver reads the octet as decimal","needs_analyst":true,"not_affected_if":["node-18-or-older","hostnames-only","canonical-ip-literals"],"who_is_affected":"Applications that open TLS connections from Node.js 22.x, 24.x or 26.x to a host given as a non-canonical IPv4 literal with a leading zero, and that rely on certificate identity checks for that address. The sources do not say how common such literals are in real code, and clients that only use hostnames or canonical IP addresses are not described as affected.","user_interaction":"no","needs_special_setup":"yes","severity_if_unknown":"high"},"cost_usd":0.000702,"input_tokens":3532,"output_tokens":698,"severity_before":"high"},"analyst_status":null,"analyst_note":null,"search":"'-106069':15A,18A '-2026':14A,17A '0127.0.0.1':43B,124C,143C '127.0.0.1':167C '22':195C '24':192C '26':190C '87.0.0.1':145C 'accept':4A,78B 'address':12A,66B,100C,173C,185C 'affect':188C 'anoth':183C 'authent':80B,177C 'backend':19B 'becom':144C 'canon':34B,115C 'caus':89C 'certif':7A,47B,70B,92C,180C 'check':3A,49B 'client':28B,105C 'connect':56B,65B,106C,148C,172C 'cve':13A,16A 'decim':166C 'differ':44B,74B,98C 'flaw':82C 'follow':129C 'host':110C,128C 'hostnam':48B,86C 'ip':6A,75B,99C,184C 'ipv4':35B,116C 'issu':71B,181C 'lead':10A,39B,120C,138C 'leading-zero':9A,137C 'liter':36B,117C 'maco':20B,162C 'made':150C 'man':59B 'man-in-the-middl':58B 'middl':62B 'node.js':1A,21B,29B,84C,189C 'non':33B,114C 'non-canon':32B,113C 'normal':30B,126C 'octal':142C 'octet':140C 'one':103C 'oper':153C 'os':52B 'platform':159C 'poc':23B 'poc-publ':22B 'present':68B 'public':24B 'read':135C,163C 'resolv':53B,155C 'rule':133C 'runtim':25B 'server':91C,169C 'system':154C 'tls':2A,27B,85C 'tls-client':26B 'tls.checkserveridentity':125C 'url':132C 'valid':95C 'verif':87C 'vulner':187C 'whatwg':131C 'wrong':5A 'x':191C,193C,196C 'zero':11A,40B,121C,139C","nicknames":[],"mitigations":[],"who_affected":"Applications that open TLS connections from Node.js 22.x, 24.x or 26.x to a host given as a non-canonical IPv4 literal with a leading zero, and that rely on certificate identity checks for that address. The sources do not say how common such literals are in real code, and clients that only use hostnames or canonical IP addresses are not described as affected.","tier":"B","verified":{},"analyst_revisit_at":null,"first_public_at":"2026-10-23T17:17:19+00:00","kev":null,"cvss_vector":"CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N","cvss_by":"support@hackerone.com","poc_count":1,"sources":[{"source":"nvd","external_id":"CVE-2026-106069","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-106069","severity":null,"published_at":"2026-10-23T17:17:19+00:00","modified_at":"2026-10-23T19:42:24+00:00","first_seen_at":"2026-10-23T21:57:34+00:00","fetched_at":"2026-10-23T22:29:03+00:00","note":null},{"source":"github-poc","external_id":"CompleteTech-LLC/node-cve-2026-106069-check","url":"https://github.com/CompleteTech-LLC/node-cve-2026-106069-check","severity":null,"published_at":"2026-10-23T23:47:14+00:00","modified_at":null,"first_seen_at":"2026-10-23T23:55:02+00:00","fetched_at":"2026-10-23T23:55:02+00:00","note":null},{"source":"epss","external_id":"CVE-2026-106069","url":"https://api.first.org/data/v1/epss?cve=CVE-2026-106069","severity":null,"published_at":null,"modified_at":null,"first_seen_at":"2026-10-25T12:38:50+00:00","fetched_at":"2026-10-25T12:38:50+00:00","note":null}],"documents":[{"id":2245,"url":"https://github.com/CompleteTech-LLC/node-cve-2026-106069-check","title":"CompleteTech-LLC/node-cve-2026-106069-check","kind":"poc","source":"github","text":"Standalone defensive checker project for CVE-2026-106069: Node.js: TLS leading-zero IPv4 resolver mismatch. One exploit per repository; implementation pending.\n\nstars 0","published_at":"2026-10-23T23:47:14+00:00","relation":"poc","confidence":null,"note":"0 stars"}],"notice":"Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai"}