CVE-2026-84961

What it actually does

undici BalancedPool deep-clones its constructor options via JSON serialize/parse, which silently drops function-valued connect and tls settings such as checkServerIdentity and custom connectors. Those callbacks never reach the TLS stack, so a peer certificate that Node's default hostname and chain checks accept is trusted even when the application's custom verifier would have rejected it. Client, Pool, and Agent dispatchers are unaffected because they extract connect/tls options before cloning. Impact is limited to apps that pass function-valued TLS options into BalancedPool on undici 7.24.1–7.29.1 and 8.0.0–8.10.2.

Why it matters to the business

Services that intended extra certificate pinning, private-CA policy, or custom identity checks on pooled HTTPS clients may accept a TLS peer they meant to refuse, exposing confidentiality and integrity of outbound API, telemetry, or control-plane traffic (CVSS 7.4, high confidentiality and integrity, no availability impact). Exploitation requires a high-complexity network position and a certificate that still passes Node defaults, and there is no KEV listing, ransomware use, or public exploit maturity 30 days after publication—so urgency is patch-driven rather than active-campaign-driven. Downstream Red Hat Node.js, Grafana, observability-console, and RHDH images inherit the library, so any product that built BalancedPool with custom TLS functions should treat this as a trust-boundary failure until upgraded.

How an attack unfolds

An attacker who can present a TLS certificate that satisfies Node's built-in hostname and chain validation—but that the victim's custom checkServerIdentity or connector would have rejected—targets an application whose outbound HTTPS goes through undici BalancedPool with those function-valued options. Because BalancedPool clones options as JSON, the custom functions are discarded and the handshake completes under default TLS policy. The attacker can then sit on the accepted connection and read or alter application data. Named threat actors and in-the-wild campaigns are not associated with this issue; success depends on the app actually supplying function-valued tls/connect options and on the attacker obtaining a default-valid cert for the intended name (compromised/misissued public CA, rogue internal CA, or similar). Client/Pool/Agent code paths do not exhibit the drop.

How to fix it

Upgrade undici to 7.29.1 (7.x line) or 8.10.2 (8.x line), which are the vendor-stated fixed releases; do not leave BalancedPool on 7.24.1 through the unfixed 7.x/8.x ranges. On Red Hat content, apply RHSA-2026:74609 so that cluster-observability-operator logging-console-plugin reaches pf4-rhel9:1790854525, monitoring-console reaches plugin-rhel9:1790854525, monitoring-console-plugin reaches pf5-rhel9:1790854526, grafana12-4-main reaches 12.4.10-0.2.hum1, nodejs24 (el10) reaches 24.21.0-1.el10_2, nodejs24-main reaches 11.16.0-1.24.18.1.0.2.2.hum1, nodejs26-main reaches 26.8.2-0.1.hum1, and rhdh/rhdh reaches hub-rhel9:1789554285. Until patched, avoid passing function-valued connect or tls options into BalancedPool (use Client, Pool, or Agent if custom TLS callbacks are required), and keep custom identity checks on dispatchers that extract options before cloning. Rebuild and redeploy any container or Node application that vendors undici transitively.

How to confirm the fix worked

Confirm the running undici version is 7.29.1, 8.10.2, or later in each line, and that Red Hat images match the RHSA-2026:74609 NVR/tags above. Inventory constructors: only BalancedPool instances that previously received function-valued connect or tls options were in scope. After upgrade, construct BalancedPool with a checkServerIdentity (or custom connector) that rejects a known default-valid test peer and verify the rejection still occurs—pre-fix behavior would accept that peer. Dependency and SBOM scans for undici 7.24.1–<fixed and 8.0.0–<fixed, plus image CVE scanners for the listed Red Hat packages, are the exposure checks.

Typical attack path

1. Discover a service that creates undici BalancedPool with a function-valued tls or connect option (custom checkServerIdentity, connector, or equivalent).
2. Obtain a network position on the path to a pooled upstream (adjacent network, compromised proxy, DNS/routing influence, or similar).
3. Present a certificate that passes Node.js default hostname and chain checks but would fail the application's discarded custom verifier.
4. Complete the TLS handshake against BalancedPool under default policy.
5. Read or modify application traffic on the accepted connection.

How to detect it

Retrospective exploitation is a successful TLS handshake that default Node policy accepted but a discarded custom verifier would have refused; there is no malware drop, distinct CVE string in logs, or public exploit tooling. Hunt outbound HTTPS from processes using undici BalancedPool for peers whose certificates would fail the application's intended checkServerIdentity (wrong SAN relative to app policy, unexpected issuer, or pins that should have fired). Review Node/undici access and TLS debug logs around BalancedPool construction and connect, application-layer anomalies after those connections (unexpected API payloads, auth to wrong backends), and certificate inventory for the upstream names those pools target. No named APT campaigns are tied to this CVE, so do not expect actor-specific C2; correlate with MITM-capable network events (new intercepting proxies, unusual TLS middleboxes, rogue internal CAs) in the 30 days since publication. Absence of custom tls/connect functions on BalancedPool means the host was not vulnerable regardless of version.

What your security team should do

• Patch undici to 7.29.1 or 8.10.2 and apply RHSA-2026:74609 on all listed Red Hat Node.js, Grafana, observability, and RHDH images as the primary control.
• Inventory Node services for BalancedPool usage with function-valued tls/connect options; treat those as the only in-scope exposure.
• Until patched, route custom TLS verification through Client, Pool, or Agent instead of BalancedPool.
• Prioritize internet-facing or multi-tenant outbound HTTPS clients that pin CAs or implement custom identity policy.
• Track this as a cryptographic-policy failure, not an RCE; there is no KEV, ransomware, or public exploit signal, so schedule within normal high-severity TLS-trust SLAs rather than emergency KEV timelines.
• Add SBOM/dependency gates that fail builds still pulling unfixed undici 7.x/8.x BalancedPool consumers.