CVE-2026-48934
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
Node.js is an asynchronous, event-driven JavaScript runtime designed for building scalable network applications. Its tls module, which the https module and HTTPS agent build on, supports TLS session resumption. A client can save the session from one connection, through the session event or tlsSocket.getSession(), and pass it back through the session option on a later connection, to skip the full handshake.
A certificate validation bypass (CVE-2026-48934) has been identified in Node.js's TLS client. A resumed session carries the trust established in the handshake that created it, so it should only ever be reused for the same server identity. However, Node.js accepted a saved session on any connection, even one to a different servername than the session was authenticated for. That let the client resume a session with a host whose own identity had never been verified, which the Node.js project describes as a TLS host identity verification bypass that can lead to unauthorized connections.
This behaviour maps to CWE-295 (Improper Certificate Validation), where a product does not validate, or incorrectly validates, a certificate. In Node.js, resuming a session issued for one name skips the certificate check that should have tied the new connection to its own servername. As a result, a client can treat a connection as authenticated for a host it never verified.
Exploitation requires a Node.js TLS client that reuses sessions across connections to different hostnames. Examples include an application that caches sessions and passes them to tls.connect() or https.request() for other hosts, or an HTTPS agent that shares session state. The attacker must control, or sit in front of, a server able to accept a session issued for another identity. Applications that never reuse TLS sessions, or only reuse them for the same host, are not exposed. The Node.js project describes the issue as affecting its supported 22.x, 24.x and 26.x lines. Node.js did not bind sessions to a servername before this fix, so earlier release lines are affected too.
Details
Module Info
- Product: Node.js
- Affected packages: node (built-in tls module; lib/internal/tls/wrap.js, lib/_tls_wrap.js on older lines)
- Affected versions: <=21.7.3 >=22.0.0 <22.23.0 >=23.0.0 <=23.11.1 >=24.0.0 <24.17.0 >=25.0.0 <=25.9.0 >=26.0.0 <26.3.1
- GitHub repository: https://github.com/nodejs/node
- Published packages: https://nodejs.org/en/download
- Package manager: Not applicable; Node.js is distributed as runtime builds from nodejs.org rather than as a published npm package
- Fixed in: Node.js 22.23.0, 24.17.0, and 26.3.1 (upstream fixes, released June 18, 2026); Node.js NES v12.22.19, v14.21.12, v16.20.13, v18.20.18, v20.20.3, v20.20.10, and v22.22.10 (all shipped June 25, 2026), covering the 12.x through 20.x lines that never received an upstream fix before reaching End-of-Life; v20.20.10 and v22.22.10 are custom builds. This fix was later found to be incomplete for the HTTPS Agent; see CVE-2026-58040 below
Vulnerability Info
This Medium-severity vulnerability is found in the session handling of Node.js's TLS client (TLSSocket.prototype.setSession() and the session event and getSession() paths). The HackerOne CNA assigns a CVSS v3.0 score of 4.3, and the Node.js project also rates it Medium.
When a client connects with a saved session, Node.js should only resume it if it was issued for the servername now being contacted. Otherwise it should fall back to a full handshake with certificate and hostname verification. In the vulnerable implementation, setSession() handed any supplied session straight to OpenSSL, and sessions were exported as raw OpenSSL data with no record of which host they belonged to. The fix wraps each exported client session with the servername it was authenticated for. On reuse, it discards a session whose recorded servername differs from the current connection's. It also discards raw, unwrapped sessions on connections that verify certificates. It shipped as commit fd890ba01d on 22.x, a77af4867b on 24.x and d1be630415 on 26.x, through nodejs-private pull request #854.
An attacker would need a client that offers a session obtained from one host while connecting to another host the attacker controls, and a server-side setup able to resume that session.
Note: The Node.js July 2026 security release disclosed CVE-2026-58040, an incomplete fix for this issue: HTTPS Agent session reuse could still skip hostname verification across identity policies. Fully remediating session reuse also needs that later fix.
Mitigation
Node.js 22.x, 24.x and 26.x are supported and received this fix in 22.23.0, 24.17.0 and 26.3.1. The follow-up fix for CVE-2026-58040 shipped in 22.23.2, 24.18.1 and 26.5.1. Every other release line is past its support window and never received an upstream fix. Node.js 12.x reached End-of-Life on April 30, 2022; Node.js 14.x on April 30, 2023; Node.js 16.x on September 11, 2023; Node.js 18.x on April 30, 2025; Node.js 20.x on April 30, 2026; Node.js 23.x on June 1, 2025; and Node.js 25.x on June 1, 2026. For more information see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade to Node.js 22.23.2, 24.18.1 or 26.5.1 or later on those lines, which include both this fix and the CVE-2026-58040 follow-up.
- Migrate affected applications away from the End-of-Life Node.js release lines, and avoid reusing TLS sessions across different hostnames.
- Leverage a commercial support partner like HeroDevs for post-EOL security support, through Node.js NES.
Credits
- 3d7omb (reporter)
- Matteo Collina (remediation developer)