CVE-2026-9697

What it actually does

This vulnerability causes undici ProxyAgent and Socks5ProxyAgent to ignore the requestTls configuration when the proxy URI uses socks5:// or socks://. As a result, HTTPS connections made through a SOCKS5 tunnel do not use the application-specified TLS controls such as custom ca, client cert, key, rejectUnauthorized, or servername, and instead fall back to Node.js default TLS behavior and the default public Mozilla trust store. Applications that intended to restrict trust to an internal, private, or corporate certificate authority lose that restriction, allowing any certificate valid for the destination hostname and signed by a publicly trusted CA to be accepted. The primary technical impact is loss of TLS trust boundary enforcement, enabling man-in-the-middle interception, plaintext visibility after TLS termination by the attacker, and modification of HTTPS responses or requests in transit under the right network conditions.

Why it matters to the business

Organizations using affected undici versions for outbound HTTPS requests through SOCKS5 proxies may believe traffic is protected by private CA pinning or custom TLS validation when it is not. This can expose sensitive API calls, credentials, tokens, customer data, internal service responses, or software supply-chain traffic to interception or tampering by an attacker positioned on the proxy path or able to influence routing/DNS. The CVSS score is high, but exploitation requires a suitable man-in-the-middle position and a publicly trusted certificate for the target hostname, so broad opportunistic exploitation is less likely than targeted interception. The issue is not currently listed in CISA KEV, has no known ransomware association, and has low EPSS at the time of assessment, but it is important for environments relying on SOCKS5 proxying and private CA trust enforcement.

How an attack unfolds

An attacker first needs to be in a position to intercept or control traffic between the application and the intended HTTPS destination, such as by controlling a SOCKS5 proxy, compromising a proxy path, manipulating network routing, or otherwise performing man-in-the-middle interception. The vulnerable application must be using undici ProxyAgent or Socks5ProxyAgent with a socks5:// or socks:// proxy URI and must rely on requestTls to restrict accepted certificates, for example by specifying a private CA. Because the vulnerable SOCKS5 path silently drops requestTls, the outbound HTTPS connection is validated using Node.js default trusted public certificate authorities instead of the intended restricted CA. If the attacker can present a publicly trusted certificate for the requested hostname, the application accepts the connection. The attacker can then decrypt, observe, and modify HTTPS traffic passing through the tunnel, potentially stealing credentials, altering API responses, injecting malicious payloads, or manipulating transactions without triggering the application’s intended TLS pinning controls.

How to fix it

Upgrade undici to a fixed release: v7.28.0 or later on the 7.x line, or v8.5.0 or later on the 8.x line. Because the provided fixed_versions field is empty, verify the exact package version in package.json, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, or SBOM data and ensure no affected transitive dependency pins an older undici release. The bug was introduced in undici 7.23.0, so versions from 7.23.0 before 7.28.0 are specifically affected where SOCKS5 proxy support and requestTls are used together. If immediate upgrade is not possible, avoid the SOCKS5 path for traffic that depends on TLS scope restriction; route through an HTTP proxy using ProxyAgent, where requestTls is honored correctly. There is no reliable workaround within the affected SOCKS5 code path. Review application code for socks5:// or socks:// proxy URIs combined with requestTls options such as ca, cert, key, rejectUnauthorized, or servername.

How to confirm the fix worked

Confirm exposure by identifying installed undici versions and code paths that instantiate ProxyAgent or Socks5ProxyAgent with socks5:// or socks:// proxy URIs while also setting requestTls. Validate remediation by confirming the runtime resolves to undici v7.28.0 or later, or v8.5.0 or later. Use dependency tooling such as npm ls undici, yarn why undici, pnpm why undici, SCA scans, or SBOM comparison to detect direct and transitive copies. A functional validation test should connect through a SOCKS5 proxy to a controlled HTTPS endpoint using a certificate that is trusted by the default public trust store but not by the custom requestTls.ca, or vice versa, and verify that the fixed client honors the configured TLS policy. Also review CI/CD dependency lockfiles to ensure older vulnerable releases are not reintroduced.

Typical attack path

1. Identify an application using undici ProxyAgent or Socks5ProxyAgent with a SOCKS5 proxy URI for outbound HTTPS traffic.
2. Gain a man-in-the-middle position by controlling the SOCKS5 proxy, compromising a proxy/router, manipulating DNS or routing, or intercepting traffic on the network path.
3. Present a certificate for the requested hostname that is trusted by Node.js default public CA roots but would not be trusted by the application’s intended custom requestTls.ca configuration.
4. Allow the vulnerable undici SOCKS5 handling to drop requestTls options, causing the client to validate the server using the default trust store.
5. Establish the intercepted HTTPS session successfully because the public CA-signed certificate is accepted.
6. Read sensitive data and optionally modify requests or responses in transit.

How to detect it

This issue does not create a unique exploit artifact on the vulnerable host; detection should focus on identifying exposure and signs of TLS interception or proxy-path manipulation. Review application dependency inventories and runtime package versions for undici 7.23.0 through versions before 7.28.0, then correlate with code or configuration using SOCKS5 proxy URLs and requestTls settings. Inspect outbound proxy logs, SOCKS5 proxy logs, egress firewall logs, DNS logs, and application HTTP client error/debug logs for unexpected proxy endpoints, new routing paths, unusual destination IPs for known HTTPS services, or certificate issuer/subject changes. If applications record peer certificate details, look for connections where the certificate chain terminates at a public CA when a private/internal CA was expected, unexpected certificate serial numbers, changes in SANs, or unexpected servername/SNI behavior. Network forensics may show connections to unapproved SOCKS5 proxies, TCP connections to common SOCKS ports such as 1080, or traffic routed through new intermediaries. Investigate any suspicious authentication failures, token reuse, altered API responses, checksum mismatches, or unexpected payload changes following outbound requests from affected services.

• undici@7.23.0
• undici@7.24.0
• undici@7.25.0
• undici@7.26.0
• undici@7.27.0
• socks5://
• socks://
• ProxyAgent
• Socks5ProxyAgent
• requestTls
• requestTls.ca
• requestTls.cert
• requestTls.key
• requestTls.rejectUnauthorized
• requestTls.servername
• node_modules/undici
• package-lock.json
• yarn.lock
• pnpm-lock.yaml
• npm-shrinkwrap.json
• TCP/1080

What your security team should do

• Prioritize upgrades for services that send credentials, tokens, customer data, administrative API calls, payment data, software-update traffic, or internal service traffic through SOCKS5 proxies using undici.
• Inventory all Node.js applications and dependencies for undici versions from 7.23.0 before 7.28.0, especially where SOCKS5 proxying is configured.
• Search code and configuration for ProxyAgent, Socks5ProxyAgent, socks5://, socks://, and requestTls usage to determine whether the vulnerable condition is actually reachable.
• Upgrade to undici v7.28.0 or later, or v8.5.0 or later, and rebuild/redeploy affected applications from clean dependency lockfiles.
• If upgrade cannot be completed immediately, move affected flows from SOCKS5 proxying to HTTP proxying where requestTls is honored, or disable proxy use for sensitive destinations until patched.
• Review recent outbound HTTPS traffic from affected applications for unexpected proxy endpoints, DNS changes, certificate issuer changes, or evidence of TLS interception.
• Add regression tests that verify custom CA and servername settings are enforced for proxied HTTPS requests.
• Monitor dependency updates and SCA results for transitive undici copies because applications may not import undici directly.