CVE-2026-109383: undici vulnerable to TLS certificate validation bypass via dropped tls options in Agent
Impact
undici's Agent passes its constructor options through a JSON-based deep clone (JSON.parse(JSON.stringify(...))) before forwarding them to each per-origin Pool. JSON cannot represent functions, so a caller-supplied tls option containing a checkServerIdentity callback is silently dropped before it reaches the TLS layer. As a result, a TLS peer whose certificate a custom checkServerIdentity was written to reject, but which passes Node's default hostname and chain checks, is silently accepted when the request is made through Agent. Because Agent is the default dispatcher behind request, fetch, and setGlobalDispatcher, this is the path most applications use. EnvHttpProxyAgent is also affected on its direct and NOPROXY routes, which delegate to an internal Agent.
Only applications that pass a function-valued tls option (such as a custom checkServerIdentity for certificate or public-key pinning) are affected. Passing the same options through connect is not affected. This is the Agent counterpart of the BalancedPool certificate validation bypass fixed in CVE-2026-84961.
Patches
Upgrade to undici 6.29.1, 7.30.1, or 8.12.2. Agent now preserves the tls option outside the JSON clone, so custom TLS verification callbacks are forwarded to each origin unchanged.
Workarounds
Pass the TLS options through connect instead of tls. For proxied EnvHttpProxyAgent destinations, use requestTls / proxyTls.
Other sources
undici is an HTTP client library for Node.js. In versions 4.0.0 through 6.29.0, 7.0.0 through 7.30.0, and 8.0.0 through 8.12.1, its Agent dispatcher passes its constructor options through a JSON-based deep clone before forwarding them to each per-origin pool, and because JSON cannot represent functions, a caller-supplied tls option containing a checkServerIdentity callback is silently dropped before it reaches the TLS layer. As a result, a TLS peer whose certificate a custom checkServerIdentity was written to reject, but which passes Node's default hostname and chain checks, is silently accepted. Because Agent is the default dispatcher behind request, fetch, and setGlobalDispatcher, this affects the path most applications use, and EnvHttpProxyAgent is affected on its direct and no-proxy routes as well, while only applications that pass a function-valued tls option such as a custom checkServerIdentity for certificate or public-key pinning are at risk. The issue is fixed in undici 6.29.1, 7.30.1, and 8.12.2, which preserve the tls option outside the JSON clone so custom verification callbacks are forwarded unchanged, and users should upgrade to one of those versions or later. As a workaround, pass the TLS options through connect instead of tls, or for proxied destinations use requestTls and proxyTls.
— Ubuntu
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/undicito a version that resolves this vulnerability.Fixed in 8.12.2 - Upgrade
Upgrade
npm/undicito a version that resolves this vulnerability.Fixed in 7.30.1 - Upgrade
Upgrade
npm/undicito a version that resolves this vulnerability.Fixed in 6.29.1 - Upgrade
Upgrade
debian/node-undicito a version that resolves this vulnerability.Fixed in 8.12.2+dfsg+~cs3.2.3-1 - Upgrade
Upgrade
debian/node-undicito a version that resolves this vulnerability.Fixed in 8.12.2+dfsg+~cs3.2.3-2 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 6.29.1 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 7.30.1 - Upgrade
Upgrade
undicito a version that resolves this vulnerability.Fixed in 8.12.2 - Configuration
Pass TLS options through connect instead of tls; for proxied destinations, use requestTls and proxyTls.
undici Agent and EnvHttpProxyAgent TLS option placement = connect; for proxied destinations, requestTls and proxyTls
Event History
Frequently Asked Questions
Which applications are actually exposed?
Only applications that provide a function-valued tls option, such as a custom checkServerIdentity callback for certificate or public-key pinning, are at risk. Applications relying only on Node.js's default hostname and certificate-chain validation are not affected by this behavior.
Does this affect the normal request and fetch paths?
Yes. Agent is the default dispatcher used by request, fetch, and setGlobalDispatcher, so applications using those APIs can be affected when they configure the vulnerable custom TLS callback. EnvHttpProxyAgent is also affected on direct and no-proxy routes.
What must an attacker be able to do to exploit this?
The attacker must present a TLS certificate that passes Node.js's default hostname and chain validation but would have been rejected by the application's custom checkServerIdentity callback. The vulnerable Agent drops that callback before the connection reaches the TLS layer.
How can I determine whether my deployment is affected, and what is the fix?
Check whether your installed undici version is 4.0.0 through 6.29.0, 7.0.0 through 7.30.0, or 8.0.0 through 8.12.1, and whether your application passes checkServerIdentity or another function-valued tls option through Agent. Upgrade to undici 6.29.1, 7.30.1, 8.12.2, or a later version.