ALPINE-CVE-2026-123877: Medium severity alpine/nodejs vulnerability
A certificate validation bypass in Node.js https.Agent lets a cached TLS session authenticated under one CA policy be reused by a later request with a stricter policy. https.Agent.prototype.getName() assigns the same Agent and session-cache key to a request that omits ca and one that explicitly supplies ca: [], because an omitted value appends nothing to the key while an empty array stringifies to an empty string. The two policies differ: omitting ca uses the default trust store, while supplying ca replaces it. Since they share a key, a TLS session authenticated under the broader default policy is handed to a new connection made under the later ca: [] policy, and TLS 1.3 session resumption carries the earlier authentication forward, so the second request reports authorized === true and transmits confidential data to a server its own CA policy would reject on a fresh connection. 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 applications are exposed to this issue?
Applications using Node.js 22.x, 24.x, or 26.x are exposed when the same https.Agent can reuse TLS sessions across requests with different CA settings, specifically an earlier request that omits ca followed by a request using ca: [].
What conditions are required for exploitation?
An attacker needs a server certificate accepted by the default trust store but not by the later request's empty replacement CA store. A TLS session established under the broader policy must be cached and resumed for the later request through the shared https.Agent.
Is a deployment using only the default TLS configuration affected?
The described policy bypass depends on mixing a request that omits ca with a later request that explicitly sets ca: [] on the same Agent. The data does not describe a bypass for requests that only use the default trust configuration.
How can I identify potentially affected code?
Review use of https.Agent for reuse across requests and look for code paths that use both an omitted ca option and ca: []. Prioritize cases where the later request sends confidential data after TLS authorization succeeds.