{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-106072", "assignerOrgId": "36234546-b8fa-4601-9d6f-f4e334aa8ea1", "state": "PUBLISHED", "assignerShortName": "hackerone", "dateReserved": "2026-10-06T15:00:00.655Z", "datePublished": "2026-10-23T16:15:05.783Z", "dateUpdated": "2026-10-23T16:15:05.783Z"}, "containers": {"cna": {"descriptions": [{"lang": "en", "value": "A flaw in Node.js TLS hostname verification allows a certificate with only a DNS SAN to authenticate an IP endpoint when the client connects using a non-canonical IPv4 spelling, such as `0177.0.0.1`, `0x7f.0.0.1`, `2130706433` or `127.1`.\n\n`tls.checkServerIdentity()` did not classify these hosts as IP addresses, but normalized them to their canonical form and matched the result against the certificate DNS names. A certificate containing `DNS:127.0.0.1` and no `IP Address:127.0.0.1` SAN was therefore accepted, while the same certificate is correctly rejected for `127.0.0.1`. Exploitation requires a certificate with a numeric DNS SAN issued by a CA trusted by the client, and a platform resolver that accepts these spellings, such as glibc.\n\nThis vulnerability affects Node.js **26.x**, **24.x**, and **22.x**."}], "affected": [{"defaultStatus": "unaffected", "vendor": "nodejs", "product": "node", "versions": [{"version": "22.23.3", "status": "affected", "lessThanOrEqual": "22.23.3", "versionType": "semver"}, {"version": "24.22.0", "status": "affected", "lessThanOrEqual": "24.22.0", "versionType": "semver"}, {"version": "26.12.0", "status": "affected", "lessThanOrEqual": "26.12.0", "versionType": "semver"}]}], "references": [{"url": "https://nodejs.org/en/blog/vulnerability/october-2026-security-releases"}], "metrics": [{"cvssV3_0": {"version": "3.0", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L", "baseScore": 6.7, "baseSeverity": "MEDIUM"}}], "problemTypes": [{"descriptions": [{"type": "CWE", "lang": "en", "cweId": "CWE-295", "description": "CWE-295 Improper Certificate Validation"}]}], "providerMetadata": {"orgId": "36234546-b8fa-4601-9d6f-f4e334aa8ea1", "shortName": "hackerone", "dateUpdated": "2026-10-23T16:15:05.783Z"}}}}

{}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "product": "node", "vendor": "nodejs", "versions": [{"lessThanOrEqual": "22.23.3", "status": "affected", "version": "22.23.3", "versionType": "semver"}, {"lessThanOrEqual": "24.22.0", "status": "affected", "version": "24.22.0", "versionType": "semver"}, {"lessThanOrEqual": "26.12.0", "status": "affected", "version": "26.12.0", "versionType": "semver"}]}], "source": "support@hackerone.com"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "A flaw in Node.js TLS hostname verification allows a certificate with only a DNS SAN to authenticate an IP endpoint when the client connects using a non-canonical IPv4 spelling, such as `0177.0.0.1`, `0x7f.0.0.1`, `2130706433` or `127.1`.\n\n`tls.checkServerIdentity()` did not classify these hosts as IP addresses, but normalized them to their canonical form and matched the result against the certificate DNS names. A certificate containing `DNS:127.0.0.1` and no `IP Address:127.0.0.1` SAN was therefore accepted, while the same certificate is correctly rejected for `127.0.0.1`. Exploitation requires a certificate with a numeric DNS SAN issued by a CA trusted by the client, and a platform resolver that accepts these spellings, such as glibc.\n\nThis vulnerability affects Node.js **26.x**, **24.x**, and **22.x**."}], "id": "CVE-2026-106072", "lastModified": "2026-10-23T19:42:24.553", "metrics": {"cvssMetricV30": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "LOW", "baseScore": 6.7, "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "integrityImpact": "HIGH", "privilegesRequired": "HIGH", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L", "version": "3.0"}, "exploitabilityScore": 1.2, "impactScore": 5.5, "source": "support@hackerone.com", "type": "Secondary"}]}, "published": "2026-10-23T17:17:20.203", "references": [{"source": "support@hackerone.com", "url": "https://nodejs.org/en/blog/vulnerability/october-2026-security-releases"}], "sourceIdentifier": "support@hackerone.com", "vulnStatus": "Awaiting Analysis", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-295"}], "source": "support@hackerone.com", "type": "Secondary"}]}

{"bugzilla": {"description": "nodejs: nodejs: Authentication bypass via non-canonical IPv4 hostname verification", "id": "2560022", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2560022"}, "csaw": false, "cvss3": {"cvss3_base_score": "6.7", "cvss3_scoring_vector": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L", "status": "draft"}, "cwe": "CWE-295", "details": ["A flaw was found in Node.js TLS hostname verification. When a client connects using a non-canonical IPv4 hostname spelling (for example 0177.0.0.1, 0x7f.0.0.1, 2130706433, or 127.1), tls.checkServerIdentity() may fail to classify the host as an IP address, normalize it to a canonical form, and match that form against certificate DNS SANs instead of requiring an IP Address SAN. A certificate that contains a DNS SAN equal to the canonical IP string (for example DNS:127.0.0.1) without a corresponding IP Address SAN can therefore be accepted for an IP endpoint. Exploitation requires a certificate with such a numeric DNS SAN that is trusted by the client, and a platform resolver that accepts the non-canonical spelling (glibc does)."], "mitigation": {"lang": "en:us", "value": "Use only canonical IPv4 literals or DNS names in Node.js TLS client connect targets; reject octal, hex, dword, and shortened IPv4 spellings in application input (CME-1314 Input Canonicalization Before Security Decision: https://cmetaxonomy.org/entries/CME-1314.html).\nWhere feasible, pin expected server certificates or public keys for sensitive outbound TLS (CME-404 Certificate Pinning: https://cmetaxonomy.org/entries/CME-404.html).\nRestrict which destinations Node.js workloads may reach with egress controls (CME-208: https://cmetaxonomy.org/entries/CME-208.html; CME-203: https://cmetaxonomy.org/entries/CME-203.html)."}, "name": "CVE-2026-106072", "package_state": [{"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Fix deferred", "package_name": "nodejs22", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Fix deferred", "package_name": "nodejs24", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:10", "fix_state": "Fix deferred", "package_name": "nodejs26", "product_name": "Red Hat Enterprise Linux 10"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "nodejs:22/nodejs", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:8", "fix_state": "Fix deferred", "package_name": "nodejs:24/nodejs", "product_name": "Red Hat Enterprise Linux 8"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "nodejs:22/nodejs", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "nodejs:24/nodejs", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/o:redhat:enterprise_linux:9", "fix_state": "Fix deferred", "package_name": "nodejs:26/nodejs", "product_name": "Red Hat Enterprise Linux 9"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Not affected", "package_name": "hi/nodejs", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Not affected", "package_name": "nodejs20", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Not affected", "package_name": "nodejs22", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Not affected", "package_name": "nodejs24", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Not affected", "package_name": "nodejs25", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Not affected", "package_name": "nodejs26", "product_name": "Red Hat Hardened Images"}], "public_date": "2026-10-23T16:15:05Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2026-106072\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-106072\nhttps://nodejs.org/en/blog/vulnerability/october-2026-security-releases"], "statement": "This is a Moderate severity flaw, matching the upstream Node.js Medium rating. Red Hat aligns with the CNA CVSS (6.7): exploitation requires both a non-canonical IPv4 host form and a certificate with a DNS SAN for the canonical IP string that is already trusted by the client (Privileges Required: High relative to a generic network attacker without such a cert). On Red Hat platforms using glibc, the resolver accepts these spellings, so that part of the prerequisite is met. Successful abuse can confuse TLS endpoint identity with high confidentiality and integrity impact for the affected connection, but the trusted-cert barrier keeps the overall rating Moderate rather than Important. This is a different root cause from the high-severity CVE-2026-106069. Default memory and MAC safeguards do not correct hostname matching.", "threat_severity": "Moderate"}