DEBIAN-CVE-2026-123877: Medium severity debian/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
What application pattern is exposed to this issue?
Applications are exposed when they reuse an https.Agent across requests that use different CA policies, specifically a request using the default trust store followed by a request that explicitly sets ca: []. The affected behavior involves cached TLS sessions and TLS 1.3 session resumption.
What does an attacker need to exploit this?
An attacker needs a server certificate accepted under the default trust store and must cause or receive a connection that reuses a TLS session previously authenticated under that broader policy. The later request must use the same Agent with ca: [], which would reject that certificate on a fresh connection.
Are applications using the default CA configuration alone affected?
The described bypass requires a policy transition: a default-CA request and a later request using ca: [] that share an Agent and session-cache key. The data does not describe an issue for applications that use only the default trust store without the stricter ca: [] request pattern.
What can be done if an update cannot be applied immediately?
Avoid reusing the same https.Agent between requests that omit ca and requests that explicitly specify ca: []. Separate Agents prevent those requests from sharing the affected session cache.
How can I determine whether my application is affected?
Review Node.js code for a shared https.Agent used by both requests without a ca option and requests with ca: []. Systems using Node.js 22.x, 24.x, or 26.x and this request pattern are within the described affected scope.