ALPINE-CVE-2026-123867: Medium severity alpine/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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
alpine/nodejsto a version that resolves this vulnerability.Fixed in 22.23.5-r0 - Upgrade
Upgrade
alpine/nodejsto a version that resolves this vulnerability.Fixed in 24.22.3-r0
Event History
Frequently Asked Questions
Which deployments are exposed?
Affected deployments use Node.js 26.x, 24.x, or 22.x and configure a protected SNI hostname with server.addContext(host, { ca: protectedCA }) without a server certificate in that hostname's context. The server must also use mutual TLS client-certificate verification.
What does an attacker need to exploit this?
The attacker needs a client certificate trusted by the default hostname's client CA, but not by the protected hostname's intended client CA. They can then connect to the protected hostname and complete the mutual-TLS handshake using the default CA authorization.
Does enabling requestCert and rejectUnauthorized prevent the issue?
No. The issue can occur even when both options are enabled, because the protected hostname's CA is not installed when its SNI context contains only a CA and no server certificate.
How can I identify vulnerable configurations or reduce exposure before a fix is available?
Review server.addContext calls for hostname-specific contexts that set a ca value but omit a server certificate. Do not rely on a CA-only SNI context to enforce separate client-certificate authorization for a protected hostname.