CVE-2026-9697: Undici ProxyAgent SOCKS5 Certificate Pinning Bypass

Technical summary

CVE-2026-9697 describes a silent configuration drop in undici's ProxyAgent implementation when using SOCKS5 URIs (socks5:// or socks://). The requestTls parameter bundle—which includes ca, cert, key, rejectUnauthorized, and servername options—is not properly passed through to the underlying TLS connection. Instead, the HTTPS connection through the SOCKS5 tunnel uses Node.js's default trust store, which trusts the Mozilla CA bundle. This means any certificate signed by a public CA for the target hostname will be accepted, regardless of pinning policies configured in requestTls. The bug was introduced when SOCKS5 support was added in version 7.23.0. HTTP proxies do not exhibit this issue; they correctly honor requestTls configuration.

Business impact

For organizations using undici with certificate pinning (a common control to prevent MITM attacks against internal or partner APIs), switching to a SOCKS5 proxy inadvertently removes that protection without any warning or error. This creates a window where HTTPS traffic to pinned endpoints can be intercepted and modified by an attacker with network visibility. The silent nature of the failure makes it especially dangerous: configuration looks correct, but is not enforced. Applications relying on internal CAs, mTLS, or strict certificate validation for compliance or security posture are most at risk. Impact ranges from data exfiltration to tampering with API responses or sensitive payloads.

Affected systems

Affected systems are those running Node.js applications that use undici's ProxyAgent or Socks5ProxyAgent with a SOCKS5 proxy URI and that also rely on requestTls configuration for TLS certificate validation or pinning. Undici versions 7.23.0 through 7.27.x and 8.0.0 through 8.4.x are vulnerable. Version 8.5.0 and 7.28.0 and later contain the fix. Any application that upgraded undici primarily for SOCKS5 support (introduced in 7.23.0) without realizing requestTls would not be honored is a candidate for exposure.

Exploitability

Exploitation requires network-level access (man-in-the-middle position) between the application and the target HTTPS endpoint. An attacker must be able to intercept traffic or control the network path—this could be an untrusted network, a compromised proxy hop, a BGP hijack, or DNS spoofing. The attack surface is elevated in environments where SOCKS5 proxies are used to route traffic through untrusted networks or where the proxy itself is not fully controlled. No interaction or special conditions are required beyond deploying a vulnerable version with SOCKS5 proxy configuration; the flaw is silently triggered by configuration alone.

Remediation

Upgrade undici to version 7.28.0 or later (for the v7 branch) or version 8.5.0 or later (for the v8 branch). Review your dependency management and ensure all transitive dependencies that pull in undici are also updated. If an immediate upgrade is not possible and SOCKS5 proxy with TLS scope restriction is required, route traffic through an HTTP-proxy ProxyAgent instead, where requestTls is correctly honored. Audit your deployment to confirm which applications use both SOCKS5 proxies and requestTls; these are the highest-priority targets for patching.

Patch guidance

Apply the patch by upgrading undici to v7.28.0 or v8.5.0 or later. These versions restore the proper handling of requestTls configuration in SOCKS5 paths. Verify the upgrade by reviewing package-lock.json or yarn.lock to confirm the installed version. No configuration changes are required after patching; existing requestTls settings will then be honored correctly. Test in a staging environment if possible to confirm that TLS handshakes and certificate validation behave as expected after the upgrade.

Detection guidance

Review application code and configuration to identify any use of ProxyAgent or Socks5ProxyAgent with a SOCKS5 URI. Check for simultaneous use of requestTls parameters (ca, cert, key, rejectUnauthorized, servername). Examine package-lock.json or yarn.lock to identify undici versions between 7.23.0–7.27.x or 8.0.0–8.4.x. Monitor TLS handshake logs or use packet inspection to see if HTTPS connections through SOCKS5 proxies are accepting certificates outside the intended trust anchor. Also audit reverse DNS records and certificate transparency logs for unexpected certificates issued for your internal or pinned hostnames during the vulnerable window.

Why prioritize this

This vulnerability merits urgent attention because it silently breaks a critical security control (certificate pinning) without alerting operators. The CVSS score of 7.4 reflects high impact on confidentiality and integrity. While it requires network-level access, the combination of silent failure, the prevalence of SOCKS5 in enterprise proxy architectures, and the potential for compliance violations (PCI-DSS, HIPAA, etc. often require certificate pinning) makes this a priority. Organizations using SOCKS5 should patch within days, not weeks.

Risk score, explained

The CVSS 3.1 score of 7.4 (HIGH) reflects: (1) high impact on confidentiality (C:H) and integrity (I:H) via certificate pinning bypass; (2) attack vector of network (AV:N); (3) attack complexity of high (AC:H) due to the need for network-level positioning; (4) no privilege required (PR:N) and no user interaction (UI:N); (5) scope unchanged (S:U). The score accurately captures the severity of a silent configuration flaw that enables MITM attacks. It does not increase further because exploitation does require positioning, and availability is not impacted.

Frequently asked questions