REDHAT-BUG-2490018: High severity undici vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 7.28.0 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 8.5.0 - Compensating control
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 (so requestTls is honored correctly), rather than using undici's ProxyAgent/Socks5ProxyAgent with socks5:// or socks://.
Event History
Frequently Asked Questions
Which deployments are exposed?
Applications are affected when they use undici's ProxyAgent, or Socks5ProxyAgent directly, with a socks5:// or socks:// proxy URI and depend on requestTls settings to restrict TLS trust. This specifically includes configurations using requestTls.ca, cert, key, rejectUnauthorized, or servername.
What does an attacker need to exploit this?
An attacker needs to intercept or tamper with the HTTPS connection through the SOCKS5 tunnel and present a publicly trusted certificate for the target hostname. Because the configured requestTls trust settings are ignored, the connection uses Node's default trust store and may accept that certificate.
What should we do if we cannot patch immediately?
Upgrade undici to v7.28.0 or v8.5.0. If upgrading is not immediately possible, route the traffic through an HTTP-proxy ProxyAgent instead of the SOCKS5 path, because requestTls is honored for HTTP proxies.
How can we identify affected configurations?
Review proxy configuration for socks5:// or socks:// URIs and identify whether requests rely on requestTls to provide a private or corporate CA, client certificates, custom hostname handling, or rejectUnauthorized behavior. The issue was introduced in undici 7.23.0 with the addition of SOCKS5 support.