CVE-2026-58040

Overview

Node.js is a JavaScript runtime built on the V8 JavaScript engine. It uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, and it is widely used to build scalable server-side and networking applications.

An improper certificate validation vulnerability (CVE-2026-58040) has been identified in the Node.js HTTPS Agent, where connection and TLS session reuse can skip hostname verification across identity policies. A request that supplies its own checkServerIdentity function can be served over a pooled connection or a resumed TLS session that was established under a different identity policy, so the check the request asked for never runs. This is an incomplete fix of CVE-2026-48934.

Per MITRE, CWE-297, Improper Validation of Certificate with Host Mismatch, describes a product that "communicates with a host that provides a certificate, but the product does not properly ensure that the certificate is actually associated with that host." An application that relies on a custom identity check, for example certificate pinning, may therefore accept a peer it intended to reject.

This issue affects all users on the active 26.x, 24.x, and 22.x release lines below the patched versions. The End-of-Life 12.x, 14.x, 16.x, 18.x, and 20.x lines are affected as well and received a post-EOL security fix under Node.js NES. The issue is tracked in GitHub Security Advisory GHSA-r5cq-rcm7-54x2.

‍

Details

Module Info

Vulnerability Info

This Medium-severity vulnerability is found in the https.Agent implementation of the Node.js runtime, in every release below the patched version of each line.

A client can override how Node.js decides that a server certificate belongs to the host being contacted by passing its own checkServerIdentity function. That is the supported way to implement certificate pinning or any identity policy stricter than the default. Separately, the HTTPS Agent pools sockets and caches TLS sessions so later requests to the same endpoint can skip a full handshake, and both the pool and the session cache are addressed by a name the agent derives from the request options.

In affected versions that name did not account for a per-request checkServerIdentity. Requests with different identity policies therefore shared one pool entry and one cached session. A request carrying a strict custom check could be handed a keep-alive socket whose handshake had already been validated under the default policy, or could resume a cached TLS session, and in neither case does the custom identity check run against the peer. The stricter policy the calling code asked for is silently skipped.

The upstream fix (commit 52a8ace880, "https: bind identity checks to session reuse") tags any request that carries a per-request custom check with a unique marker at request time:

if (options.checkServerIdentity !== undefined &&
   options.checkServerIdentity !== tls.checkServerIdentity &&
   !hasAgentCheckServerIdentity(options)) {
 options[kPerRequestCheckServerIdentity] =
   ++perRequestCheckServerIdentityIndex;
}


That marker is appended to the agent name, so such a request gets its own pool entry; it disables both the session cache lookup and the caching of the resulting session; and keepSocketAlive returns false for the socket so it is not returned to the keep-alive pool afterwards. The same commit records the new behavior in the Node.js documentation: "Requests that specify a custom checkServerIdentity option are not eligible for connection reuse or TLS session reuse by an https.Agent, unless the checkServerIdentity option was specified when constructing the Agent."

The CVSS vector records a network attack vector with high attack complexity and low privileges required, a changed scope, and confidentiality impact only. The practical consequence is that a connection an application believed was validated under its own identity policy may not have been.

Note: requests remain eligible for connection and session reuse when the checkServerIdentity option was supplied to the Agent constructor rather than per request, because in that case every request through that Agent shares the same identity policy.

‍

Mitigation

The Node.js 12.x, 14.x, 16.x, 18.x, and 20.x release lines are End-of-Life and will not receive an upstream fix for this issue. For more information see previous releases.

HeroDevs' Node.js NES release notes list this CVE as fixed for all five of those EOL lines: v12.22.20 (August 11, 2026), v14.21.13, v16.20.14, v18.20.19, and v20.20.4 (all August 3, 2026). HeroDevs also lists a fix for this CVE in NES v22.22.11 (July 31, 2026). Node.js 22.x is not End-of-Life, but HeroDevs publishes a separate custom Node.js 22 line with its own release notes and its own version numbering, distinct from the upstream nodejs.org 22.x releases; v22.22.11 belongs to that custom line rather than being a post-EOL fix.

Users of the affected components should apply one of the following mitigations:

‍

Credits