Bug 2571835 (CVE-2026-123867)
| Summary: | CVE-2026-123867 nodejs: Node.js: Mutual TLS authorization bypass via incomplete SNI context configuration | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | OSIDB Bzimport <bzimport> |
| Component: | vulnerability | Assignee: | Product Security DevOps Team <prodsec-dev> |
| Status: | NEW --- | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | Keywords: | Security |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | --- | |
| Doc Text: |
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.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.