{"api_version":"1","generated_at":"2026-11-12T09:28:39+00:00","cve":"CVE-2026-123867","urls":{"html":"https://cve.report/CVE-2026-123867","api":"https://cve.report/api/cve/CVE-2026-123867.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-123867","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-123867"},"summary":{"title":"Node.js is vulnerable to a per-host mTLS authorization bypass via a CA-only SNI context failing open to the default CA","description":"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.","state":"PUBLISHED","assigner":"openjs","published_at":"2026-11-11 19:17:33","updated_at":"2026-11-11 19:17:33"},"problem_types":["CWE-295","CWE-295 Improper Certificate Validation"],"metrics":[{"version":"3.0","source":"ce714d77-add3-4f53-aff5-83d477b104bb","type":"Secondary","score":"4.2","severity":"MEDIUM","vector":"CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N","data":{"version":"3.0","vectorString":"CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N","baseScore":4.2,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"HIGH","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"LOW","availabilityImpact":"NONE"}},{"version":"3.0","source":"CNA","type":"CVSS","score":"4.2","severity":"MEDIUM","vector":"CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N","data":{"baseScore":4.2,"baseSeverity":"MEDIUM","vectorString":"CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N","version":"3.0"}}],"references":[{"url":"https://cna.openjsf.org/security-advisories.html","name":"https://cna.openjsf.org/security-advisories.html","refsource":"ce714d77-add3-4f53-aff5-83d477b104bb","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://nodejs.org/en/blog/vulnerability/november-2026-security-releases","name":"https://nodejs.org/en/blog/vulnerability/november-2026-security-releases","refsource":"ce714d77-add3-4f53-aff5-83d477b104bb","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-123867","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-123867","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"nodejs","product":"node","version":"affected 0.0.0 22.23.5 semver","platforms":[]},{"source":"CNA","vendor":"nodejs","product":"node","version":"affected 23.0.0 24.22.3 semver","platforms":[]},{"source":"CNA","vendor":"nodejs","product":"node","version":"affected 25.0.0 26.13.1 semver","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"aur0r4_glyph","lang":"en"},{"source":"CNA","value":"mcollina","lang":"en"},{"source":"CNA","value":"UlisesGascon","lang":"en"},{"source":"CNA","value":"pimterry","lang":"en"},{"source":"CNA","value":"aduh95","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"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"}]}],"credits":[{"lang":"en","type":"reporter","value":"aur0r4_glyph"},{"lang":"en","type":"remediation developer","value":"mcollina"},{"lang":"en","type":"remediation reviewer","value":"UlisesGascon"},{"lang":"en","type":"remediation reviewer","value":"pimterry"},{"lang":"en","type":"coordinator","value":"aduh95"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/markdown","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."}],"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."}],"metrics":[{"cvssV3_0":{"baseScore":4.2,"baseSeverity":"MEDIUM","vectorString":"CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N","version":"3.0"},"format":"CVSS"}],"problemTypes":[{"descriptions":[{"cweId":"CWE-295","description":"Improper Certificate Validation","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-11-11T18:23:12.991Z","orgId":"ce714d77-add3-4f53-aff5-83d477b104bb","shortName":"openjs"},"references":[{"tags":["vendor-advisory"],"url":"https://nodejs.org/en/blog/vulnerability/november-2026-security-releases"},{"url":"https://cna.openjsf.org/security-advisories.html"}],"title":"Node.js is vulnerable to a per-host mTLS authorization bypass via a CA-only SNI context failing open to the default CA","x_generator":{"engine":"nodejs-private/security-release publish-cves"}}},"cveMetadata":{"assignerOrgId":"ce714d77-add3-4f53-aff5-83d477b104bb","assignerShortName":"openjs","cveId":"CVE-2026-123867","datePublished":"2026-11-11T18:23:12.991Z","dateReserved":"2026-11-06T16:16:19.081Z","dateUpdated":"2026-11-11T18:23:12.991Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-11-11 19:17:33","lastModifiedDate":"2026-11-11 19:17:33","problem_types":["CWE-295","CWE-295 Improper Certificate Validation"],"metrics":{"cvssMetricV30":[{"source":"ce714d77-add3-4f53-aff5-83d477b104bb","type":"Secondary","cvssData":{"version":"3.0","vectorString":"CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N","baseScore":4.2,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"HIGH","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"LOW","integrityImpact":"LOW","availabilityImpact":"NONE"},"exploitabilityScore":1.6,"impactScore":2.5}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"123867","Ordinal":"1","Title":"Node.js is vulnerable to a per-host mTLS authorization bypass vi","CVE":"CVE-2026-123867","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"123867","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"Node.js is vulnerable to a per-host mTLS authorization bypass vi"}]}}}