{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-123867", "assignerOrgId": "ce714d77-add3-4f53-aff5-83d477b104bb", "state": "PUBLISHED", "assignerShortName": "openjs", "dateReserved": "2026-11-06T16:16:19.081Z", "datePublished": "2026-11-11T18:23:12.991Z", "dateUpdated": "2026-11-12T14:34:33.702Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "ce714d77-add3-4f53-aff5-83d477b104bb", "shortName": "openjs", "dateUpdated": "2026-11-12T14:34:33.702Z"}, "title": "Node.js is vulnerable to a per-host mTLS authorization bypass via a CA-only SNI context failing open to the default CA", "problemTypes": [{"descriptions": [{"lang": "en", "cweId": "CWE-295", "description": "CWE-295 Improper Certificate Validation", "type": "CWE"}]}], "affected": [{"vendor": "nodejs", "product": "node", "versions": [{"status": "affected", "version": "0.0.0", "lessThan": "22.23.5", "versionType": "semver"}, {"status": "affected", "version": "23.0.0", "lessThan": "24.22.3", "versionType": "semver"}, {"status": "affected", "version": "25.0.0", "lessThan": "26.13.1", "versionType": "semver"}], "defaultStatus": "unaffected"}], "descriptions": [{"lang": "en", "value": "A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different client-certificate CA with `server.addContext(host, { ca: protectedCA })` but no server certificate in that SNI context, the per-host client CA is never installed and the handshake falls back to the default client CA. In `src/crypto/crypto_tls.cc`, `CertCbDone` installs the SNI context's CA only when `setSniContext` succeeds, but `setSniContext` returns `false` for a context with no server certificate, so a CA-only SNI context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not the protected CA, can therefore complete mTLS to the protected hostname and read its response even with `requestCert` and `rejectUnauthorized` enabled, while a client certified by the protected CA is rejected. This vulnerability affects Node.js 26.x, 24.x, and 22.x.", "supportingMedia": [{"type": "text/markdown", "base64": false, "value": "A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different client-certificate CA with `server.addContext(host, { ca: protectedCA })` but no server certificate in that SNI context, the per-host client CA is never installed and the handshake falls back to the default client CA. In `src/crypto/crypto_tls.cc`, `CertCbDone` installs the SNI context's CA only when `setSniContext` succeeds, but `setSniContext` returns `false` for a context with no server certificate, so a CA-only SNI context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not the protected CA, can therefore complete mTLS to the protected hostname and read its response even with `requestCert` and `rejectUnauthorized` enabled, while a client certified by the protected CA is rejected. This vulnerability affects Node.js 26.x, 24.x, and 22.x."}]}], "references": [{"url": "https://nodejs.org/en/blog/vulnerability/november-2026-security-releases", "tags": ["vendor-advisory"]}, {"url": "https://cna.openjsf.org/security-advisories.html"}], "metrics": [{"format": "CVSS", "scenarios": [{"lang": "en", "value": "GENERAL"}], "cvssV3_1": {"version": "3.1", "attackVector": "NETWORK", "attackComplexity": "HIGH", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "LOW", "integrityImpact": "LOW", "availabilityImpact": "NONE", "baseSeverity": "MEDIUM", "baseScore": 4.2, "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N"}}], "credits": [{"lang": "en", "value": "Uttkarsh Singh", "type": "reporter"}, {"lang": "en", "value": "mcollina", "type": "remediation developer"}, {"lang": "en", "value": "UlisesGascon", "type": "remediation reviewer"}, {"lang": "en", "value": "pimterry", "type": "remediation reviewer"}, {"lang": "en", "value": "aduh95", "type": "coordinator"}], "source": {"discovery": "UNKNOWN"}, "x_generator": {"engine": "nodejs-private/security-release publish-cves"}}}}

{}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "product": "node", "vendor": "nodejs", "versions": [{"lessThan": "22.23.5", "status": "affected", "version": "0.0.0", "versionType": "semver"}, {"lessThan": "24.22.3", "status": "affected", "version": "23.0.0", "versionType": "semver"}, {"lessThan": "26.13.1", "status": "affected", "version": "25.0.0", "versionType": "semver"}]}], "source": "ce714d77-add3-4f53-aff5-83d477b104bb"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different client-certificate CA with `server.addContext(host, { ca: protectedCA })` but no server certificate in that SNI context, the per-host client CA is never installed and the handshake falls back to the default client CA. In `src/crypto/crypto_tls.cc`, `CertCbDone` installs the SNI context's CA only when `setSniContext` succeeds, but `setSniContext` returns `false` for a context with no server certificate, so a CA-only SNI context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not the protected CA, can therefore complete mTLS to the protected hostname and read its response even with `requestCert` and `rejectUnauthorized` enabled, while a client certified by the protected CA is rejected. This vulnerability affects Node.js 26.x, 24.x, and 22.x."}], "id": "CVE-2026-123867", "lastModified": "2026-11-12T15:17:46.797", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 4.2, "baseSeverity": "MEDIUM", "confidentialityImpact": "LOW", "integrityImpact": "LOW", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N", "version": "3.1"}, "exploitabilityScore": 1.6, "impactScore": 2.5, "source": "ce714d77-add3-4f53-aff5-83d477b104bb", "type": "Secondary"}]}, "published": "2026-11-11T19:17:33.480", "references": [{"source": "ce714d77-add3-4f53-aff5-83d477b104bb", "url": "https://cna.openjsf.org/security-advisories.html"}, {"source": "ce714d77-add3-4f53-aff5-83d477b104bb", "url": "https://nodejs.org/en/blog/vulnerability/november-2026-security-releases"}], "sourceIdentifier": "ce714d77-add3-4f53-aff5-83d477b104bb", "vulnStatus": "Received", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-295"}], "source": "ce714d77-add3-4f53-aff5-83d477b104bb", "type": "Secondary"}]}

{"bugzilla": {"description": "nodejs: Node.js: Mutual TLS authorization bypass via incomplete SNI context configuration", "id": "2571835", "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2571835"}, "csaw": false, "cvss3": {"cvss3_base_score": "4.2", "cvss3_scoring_vector": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N", "status": "draft"}, "cwe": "CWE-295", "details": ["A flaw was found in Node.js. When a Transport Layer Security (TLS) server configures a host-specific client Certificate Authority (CA) without providing an associated server certificate, the per-host client validation settings fail to apply. Consequently, the connection silently falls back to trusting the default client CA. A remote client authorized only for the default host can exploit this flaw to bypass mutual TLS (mTLS) restrictions and gain unauthorized access to protected hostnames."], "mitigation": {"lang": "en:us", "value": "Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability."}, "name": "CVE-2026-123867", "package_state": [{"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Will not fix", "package_name": "nodejs20", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Affected", "package_name": "nodejs22", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Affected", "package_name": "nodejs24", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Will not fix", "package_name": "nodejs25", "product_name": "Red Hat Hardened Images"}, {"cpe": "cpe:/a:redhat:hummingbird:1", "fix_state": "Affected", "package_name": "nodejs26", "product_name": "Red Hat Hardened Images"}], "public_date": "2026-11-11T18:23:12Z", "references": ["https://www.cve.org/CVERecord?id=CVE-2026-123867\nhttps://nvd.nist.gov/vuln/detail/CVE-2026-123867\nhttps://cna.openjsf.org/security-advisories.html\nhttps://nodejs.org/en/blog/vulnerability/november-2026-security-releases"], "statement": "This vulnerability is rated as having Moderate impact because successful exploitation requires a non-standard configuration and existing authorized client credentials, restricting the flaw to cross-tenant boundary traversal rather than arbitrary unauthenticated access. In standard Red Hat enterprise environments, Node.js applications enforcing mutual TLS typically either configure dedicated server certificates for each virtual host or terminate TLS upstream at an API gateway or reverse proxy. The impact is therefore limited to specific deployments that rely on runtime SNI-based client CA switching without defining host-specific server certificates.", "threat_severity": "Moderate"}

{"created": "2026-11-12T13:45:03.648729+00:00", "updated": "2026-11-12T13:45:03.648733+00:00", "vendors": []}