FlawAtlas
Search the atlas
CVE-2026-9697 High

undici vulnerable to TLS certificate validation bypass via dropped requestTls in SOCKS5 ProxyAgent

## Impact undici's `ProxyAgent` silently drops the `requestTls` option when configured with a SOCKS5 proxy URI (`socks5://` or `socks://`). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured `ca`, `cert`, `key`, `rejectUnauthorized`, and `servername` settings. Applications that pin to an internal or corporate CA via `requestTls.ca` will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange. Affected applications are those that use undici's `ProxyAgent` (or `Socks5ProxyAgent` directly) with SOCKS5 AND rely on `requestTls` for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added. ## Patches Upgrade to undici v7.28.0 or v8.5.0. ## Workarounds No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy `ProxyAgent` instead, where `requestTls` is honored correctly.

Exploit probability 0.5%
Published June 18, 2026
Required by Not available
Last source change June 19, 2026

02 / AFFECTED SOFTWARE

Affected packages

Unknown Unknown

24 explicit affected versions

npm undici

03 / CONNECTIONS

Connected vulnerabilities

04 / EVIDENCE

Source records

Open Source Vulnerabilities CVE-2026-9697

Impact: undici's ProxyAgent silently drops the requestTls option when configured with a SOCKS5 proxy URI (socks5:// or socks://). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured ca, cert, key, rejectUnauthorized, and servername settings. Applications that pin to an internal or corporate CA via requestTls.ca will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange. Affected applications are those that use undici's ProxyAgent (or Socks5ProxyAgent directly) with SOCKS5 AND rely on requestTls for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added. Patches: Upgrade to undici v7.28.0 or v8.5.0. Workarounds: No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy ProxyAgent instead, where requestTls is honored correctly.

View original source
Open Source Vulnerabilities GHSA-vmh5-mc38-953g

## Impact undici's `ProxyAgent` silently drops the `requestTls` option when configured with a SOCKS5 proxy URI (`socks5://` or `socks://`). The target HTTPS connection through the SOCKS5 tunnel falls back to Node's default trust store, ignoring user-configured `ca`, `cert`, `key`, `rejectUnauthorized`, and `servername` settings. Applications that pin to an internal or corporate CA via `requestTls.ca` will, when their proxy URI is SOCKS5, get the default Mozilla CA bundle as the trust anchor instead. Any cert signed by any publicly-trusted CA for the target hostname is accepted, breaking the intended pin and enabling MITM read and tamper of the HTTPS exchange. Affected applications are those that use undici's `ProxyAgent` (or `Socks5ProxyAgent` directly) with SOCKS5 AND rely on `requestTls` for TLS scope restriction. The bug was introduced in undici 7.23.0 when SOCKS5 support was added. ## Patches Upgrade to undici v7.28.0 or v8.5.0. ## Workarounds No workaround is available within the SOCKS5 path. If a SOCKS5 proxy with TLS scope restriction is required and an upgrade is not yet possible, route the traffic through an HTTP-proxy `ProxyAgent` instead, where `requestTls` is honored correctly.

View original source

05 / REFERENCES

Further evidence