CVE-2026-9697: 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.
Security readout for executives and security teams
Plain-English summary
This bug weakens HTTPS trust decisions for specific Node.js applications using undici with SOCKS5 proxies. If the app expected traffic to trust only an internal or corporate CA, undici instead used Node’s default public CA trust store, allowing a valid public certificate for the hostname to satisfy verification.
Executive priority
Treat as high priority for systems that send sensitive traffic through SOCKS5 proxies with corporate CA pinning or custom TLS policy. For other systems, prioritize normal dependency updates after confirming the specific undici, SOCKS5, and requestTls conditions are absent.
Technical view
undici ProxyAgent drops requestTls options when the proxy URI is socks5:// or socks://. As a result, ca, cert, key, rejectUnauthorized, and servername settings are ignored for the tunneled HTTPS target. The issue was introduced with SOCKS5 support in 7.23.0 and patched in 7.28.0 and 8.5.0.
Likely exposure
Exposure is limited to applications using undici ProxyAgent or Socks5ProxyAgent with a SOCKS5 proxy and relying on requestTls to restrict TLS trust. General undici users, HTTP proxy configurations, and applications not using requestTls for certificate scope restriction are not shown as affected by the provided sources.
Exploitation context
The source bundle does not show active exploitation, and KEV is false. Practical abuse would require a position to intercept or influence HTTPS traffic plus a publicly trusted certificate for the target hostname. The impact is confidentiality and integrity loss for affected HTTPS exchanges.
Researcher notes
The important boundary is configuration-dependent: SOCKS5 plus requestTls. The advisory says no SOCKS5-path workaround exists inside undici before patching. Avoid overstating reachability; the sources do not claim broad Node.js TLS failure or confirmed exploitation.
Mitigation direction
Upgrade undici to v7.28.0 or v8.5.0.
Avoid the SOCKS5 path until upgraded when requestTls restrictions are required.
Use an HTTP-proxy ProxyAgent where requestTls is honored, if upgrade is delayed.
Check Red Hat advisories for affected packaged products and fixed builds.
Monitor the upstream GitHub advisory for any changed guidance.
Validation and detection
Inventory applications and lockfiles for undici versions from 7.23.0 onward.
Review code for ProxyAgent or Socks5ProxyAgent using socks5:// or socks://.
Confirm whether requestTls.ca, cert, key, rejectUnauthorized, or servername is configured.
After remediation, verify the application enforces the intended TLS trust restrictions.
For vendor packages, map installed builds against the referenced Red Hat advisories.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-295: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
2ADP providers
17Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: noneAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-295 · source CWE mapping
Improper Certificate Validation
Improper Certificate Validation represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.