CVE-2026-123872
Description
A flaw was found in Node.js. An authenticated remote attacker can bypass client certificate authentication policies on servers configuring different security requirements per hostname. By renegotiating an established Transport Layer Security (TLS) connection and changing the target server name, the attacker can carry forward their existing authenticated session to gain unauthorized access to restricted endpoints.
Statement
This vulnerability is rated as an Important severity flaw because an authenticated attacker can circumvent host-level access controls and reach privileged virtual host endpoints over an existing connection. Exploitation requires non-default architectures where a Node.js process directly handles TLS termination across multi-tenant domains with heterogeneous mutual TLS policies using TLS 1.2. Deployments where TLS is terminated by front-end reverse proxies, ingress routers, or environments utilizing TLS 1.3 exclusively are not exposed to this renegotiation issue.
Mitigation
Enforce TLS 1.3 to eliminate TLS renegotiation, or isolate virtual host policies using an upstream reverse proxy.
To enforce TLS 1.3 across Node.js services without application code modifications, configure the minimum TLS version using the NODE_OPTIONS environment variable:
export NODE_OPTIONS="--tls-min-v1.3"
For systemd-managed Node.js applications, configure the environment variable within the unit configuration:
[Service]
Environment="NODE_OPTIONS=--tls-min-v1.3"
Apply the configuration by reloading systemd and restarting the target service:
systemctl daemon-reload
systemctl restart <service_name>
Caveats:
Enforcing TLS 1.3 prevents clients that support only TLS 1.2 or earlier from establishing connections. Applying systemd configuration changes and restarting the service will cause a momentary service interruption. Alternatively, if TLS 1.2 support must be retained, terminate TLS connections at a reverse proxy configured to bind differing mutual TLS authentication domains to separate listening addresses or ports.
Common Vulnerability Scoring System (CVSS) Score Details
Info alert:Important note
CVSS scores for open source components depend on vendor-specific factors (e.g. version or build chain). Therefore, Red Hat's score and impact rating can be different from NVD and other vendors. Red Hat remains the authoritative CVE Naming Authority (CNA) source for its products and services (see Red Hat classifications).
The following CVSS metrics and score provided are preliminary and subject to review.
CVSS v3 Score Breakdown
| Red Hat | NVD | cve.org | |
|---|---|---|---|
| Base Score | 8.1 | N/A | 8.1 |
| Attack Vector | Network | N/A | Network |
| Attack Complexity | Low | N/A | Low |
| Privileges Required | Low | N/A | Low |
| User Interaction | None | N/A | None |
| Scope | Unchanged | N/A | Unchanged |
| Confidentiality | High | N/A | High |
| Integrity Impact | High | N/A | High |
| Availability Impact | None | N/A | None |
Vector
Red Hat: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
cve.org: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Understanding the Weakness (CWE)
Integrity,Authentication
Technical Impact: Bypass Protection Mechanism; Gain Privileges or Assume Identity
When a certificate is invalid or malicious, it might allow an attacker to spoof a trusted entity by interfering in the communication path between the host and client. The product might connect to a malicious host while believing it is a trusted host, or the product might be deceived into accepting spoofed data that appears to originate from a trusted host.
Frequently Asked Questions
Not sure what something means? Check out our Security Glossary.
Want to get errata notifications? Sign up here.
