DEBIAN-CVE-2026-123867: Medium severity debian/nodejs vulnerability
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/cryptotls.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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Affected deployments use Node.js 26.x, 24.x, or 22.x and configure mutual TLS with hostname-specific SNI contexts where a protected hostname has its own client-certificate CA but no server certificate in that context. The server must also have a default hostname/client CA configuration.
What does an attacker need to exploit the bypass?
The attacker needs a client certificate trusted by the default client CA, but not by the protected hostname's intended CA. They can then connect using the protected hostname and complete mutual TLS under the default CA's authorization.
Does enabling requestCert and rejectUnauthorized prevent exploitation?
No. The issue can allow the unauthorized client to complete mutual TLS and read the protected hostname's response even when both requestCert and rejectUnauthorized are enabled.
How can an administrator identify a vulnerable configuration?
Review SNI contexts created with server.addContext(host, { ca: protectedCA }). A hostname is affected when its SNI context specifies a client CA but does not include a server certificate, causing the client CA check to fall back to the default context.