UBUNTU-CVE-2026-123867: Medium severity ubuntu/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 bypass?
Node.js 26.x, 24.x, and 22.x deployments are affected when they use per-host mTLS authorization with server.addContext(host, { ca: protectedCA }) and the SNI context does not include a server certificate. The protected hostname must rely on a different client-certificate CA than the default hostname.
What does an attacker need to exploit it?
The attacker needs a client certificate trusted by the server's default client CA, but not by the protected hostname's intended CA. They can then connect using the protected hostname and complete mTLS because the server falls back to the default CA.
Does enabling requestCert and rejectUnauthorized prevent exploitation?
No. The bypass can occur even when requestCert and rejectUnauthorized are enabled, because the protected hostname's CA-only SNI context fails to replace the default client CA during the TLS handshake.
How can I determine whether a hostname is misconfigured?
Review SNI contexts created with server.addContext and identify hostnames configured with a ca option but no server certificate. A practical indicator is that a client certificate trusted only by the default CA is accepted for that protected hostname, while a certificate trusted only by its configured protected CA is rejected.
What configuration change can reduce exposure before patching?
Avoid CA-only SNI contexts for protected hostnames. Configure the SNI context with a server certificate in addition to its intended client-certificate CA so the per-host CA can be installed.