ALPINE-CVE-2026-123877: Medium severity alpine/nodejs vulnerability

Published Nov 11, 2026
·
Updated

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

4 affected componentsFixes available
alpine/nodejs<22.23.5-r0
22.23.5-r0
alpine/nodejs<22.23.5-r0
22.23.5-r0
alpine/nodejs<24.22.3-r0
24.22.3-r0
alpine/nodejs<24.22.3-r0
24.22.3-r0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade alpine/nodejs to a version that resolves this vulnerability.

    Fixed in 22.23.5-r0
  2. Upgrade

    Upgrade alpine/nodejs to a version that resolves this vulnerability.

    Fixed in 24.22.3-r0

Event History

Nov 11, 2026
CVE Published
via OSV·07:17 PM
Data Sourced
via OSV·07:17 PM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

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: [].

2

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.

3

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.

4

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.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203