UBUNTU-CVE-2026-123877: Medium severity ubuntu/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
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Node.js 26.x, 24.x, and 22.x deployments are affected when an https.Agent can reuse cached TLS sessions across requests that use different CA policies. The relevant policy transition is from a request that omits ca to a later request that explicitly sets ca: [].
What conditions must occur for an attacker to benefit?
A TLS session must first be authenticated using the broader default trust store and stored in the Agent's session cache. A later connection to the same cache key must use ca: [] and resume that TLS 1.3 session; the server must be trusted by the default store but rejected by the empty replacement CA policy.
How can I determine whether an application has encountered the vulnerable path?
Review use of shared https.Agent instances for requests that mix omitted ca with explicitly configured ca: []. The vulnerable behavior is indicated when the later ca: [] request reuses a cached TLS 1.3 session and reports authorized === true even though a fresh connection under that policy would reject the server certificate.