---
id: "CVE-2026-123867"
page: "https://infrastack.ai/live/CVE-2026-123867"
kind: "vulnerability"
aliases: ["CVE-2026-123867"]
title: "Node.js: per-host mutual-TLS client CA silently falls back to default"
severity: "medium"
cvss: 4.2
epss: null
exploited: false
status: "open"
category: "runtime"
products: []
ecosystems: []
tags: ["mtls", "node.js", "runtime", "self-hosted", "tls"]
not_affected_if: ["default-config", "single-client-ca"]
published_at: "2026-11-11T19:17:33+00:00"
first_seen_at: "2026-11-11T19:28:45+00:00"
updated_at: "2026-11-11T19:30:40+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-123867", "first_seen_at": "2026-11-11T19:28:45+00:00"}]
exploit_sources: []
---

# Node.js: per-host mutual-TLS client CA silently falls back to default

Link for people: https://infrastack.ai/live/CVE-2026-123867 (this .md is for agents)

Node.js TLS servers that set a per-hostname client certificate CA without a server certificate for that name fall back to the default client CA. A client trusted only by the default CA can complete mutual TLS to the protected hostname and read its responses.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Search the codebase for `addContext(` calls that pass an `ca` option and no `cert` or `key` for the same host.
- Check the Node.js version with `node --version`; affected lines are `26.x`, `24.x` and `22.x`.

## Timeline

- 2026-11-11T19:28:45+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-123867

## From the sources

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.

---

_Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_