CVE-2026-6734

What it actually does

CVE-2026-6734 is a routing/isolation flaw in undici's Socks5ProxyAgent introduced in undici 7.23.0 and present through 8.1.0. When an application uses Socks5ProxyAgent, including through setGlobalDispatcher, undici can reuse a single connection pool across multiple request origins without validating that the pool is tied to the origin being requested. As a result, requests meant for later origins may be sent over the proxy connection established for the first origin. This can disclose headers, cookies, bearer tokens, API keys, request bodies, and other origin-scoped data to the wrong upstream service; cause the application to trust responses from an unintended origin; and in some cases silently downgrade intended HTTPS traffic to HTTP. The issue affects applications that use Socks5ProxyAgent and make requests to more than one origin within the same agent/dispatcher lifecycle.

Why it matters to the business

Organizations using affected undici versions in Node.js applications with SOCKS5 proxying may unintentionally send sensitive data to the wrong destination, including third-party services or internal endpoints. This can lead to credential exposure, data leakage, incorrect business transactions, corrupted integrations, and reliance on untrusted or incorrect responses. The risk is highest for services that call multiple APIs through a shared SOCKS5 proxy agent, especially where authentication headers or sensitive payloads are reused across outbound requests. Although this issue is not currently in CISA KEV, has low EPSS, and has no known public exploit maturity, the potential confidentiality and integrity impact is high because exploitation may occur through normal application behavior rather than obvious intrusion activity.

How an attack unfolds

An attacker generally needs some influence over request sequencing, destination selection, or an origin contacted by the vulnerable application. First, the application initializes an affected undici Socks5ProxyAgent and sends a request to an initial origin through the SOCKS5 proxy. The vulnerable connection pool becomes associated with that first origin. The attacker then causes or waits for the application to make a later request to a different origin using the same Socks5ProxyAgent instance. Due to the pool-origin validation flaw, undici dispatches the later request over the existing pool connected to the first origin instead of the intended origin. If the attacker controls or can observe the first origin, they can receive credentials, headers, query parameters, and request bodies intended for another destination. They may also return crafted responses that the application accepts as if they came from the intended origin, potentially affecting application logic, stored data, downstream API calls, or security decisions. In HTTPS workflows, the application may believe it is making a protected request to the target origin while traffic is actually routed incorrectly, and in some cases the request may be downgraded to HTTP.

How to fix it

Upgrade undici to a fixed release: v7.26.0 or later on the 7.x line, or v8.2.0 or later on the 8.x line. Review dependency lockfiles and transitive dependencies to ensure the runtime actually resolves to a fixed version, because undici may be included directly or through other Node.js packages and frameworks. If immediate upgrade is not possible, use a separate Socks5ProxyAgent instance per origin and avoid sharing a Socks5ProxyAgent or setGlobalDispatcher across requests to multiple origins. As an additional mitigation, avoid sending origin-specific credentials through shared outbound clients; scope authorization headers and cookies to the exact destination; validate response origin and scheme where possible; and avoid SOCKS5 proxying for multi-origin traffic until patched. Applications not using Socks5ProxyAgent, or using it only for a single origin per agent instance, are not expected to be affected by this specific routing flaw.

How to confirm the fix worked

Confirm the deployed dependency tree does not include undici versions 7.23.0 through 8.1.0 where Socks5ProxyAgent is used. Use package-manager inspection commands such as npm ls undici, pnpm why undici, yarn why undici, or software composition analysis tooling, and verify lockfiles and container images are rebuilt after upgrading. Review code for imports or usage of Socks5ProxyAgent, setGlobalDispatcher with a Socks5ProxyAgent, ProxyAgent wrappers that resolve to SOCKS5, or shared dispatcher instances used for multiple origins. Functional validation should include a controlled test where the same application process sends requests through SOCKS5 to two different origins using the same agent; after remediation, each request must reach its intended origin, preserve the intended HTTPS scheme, and not reuse a pool bound to a different origin. For mitigations, verify each origin receives a distinct Socks5ProxyAgent instance and that no global dispatcher is shared across unrelated origins.

Typical attack path

1. Identify or target a Node.js application that uses undici 7.23.0 through 8.1.0 with Socks5ProxyAgent or setGlobalDispatcher.
2. Find a workflow where the application makes outbound requests to more than one origin through the same Socks5ProxyAgent instance.
3. Cause the application to contact an attacker-controlled or attacker-observable origin first, establishing the reused connection pool.
4. Trigger a subsequent request intended for a different origin, ideally one carrying authentication headers, cookies, API tokens, sensitive parameters, or request body data.
5. Receive the misrouted request at the first origin or observe it through the proxy path.
6. Optionally return a crafted response that the vulnerable application treats as the response from the intended origin.
7. Use exposed credentials or manipulated responses to access data, alter application behavior, or pivot into affected integrations.

How to detect it

This vulnerability may not produce classic exploit artifacts because misrouting can occur during ordinary application traffic. Focus on evidence that requests for one destination were delivered to another. Review application logs, outbound HTTP client telemetry, SOCKS5 proxy logs, egress gateway logs, API gateway logs, and upstream service access logs around multi-origin request workflows. Look for mismatches between the TCP/proxy destination and HTTP Host header, URL host, TLS SNI, or expected integration endpoint. Investigate cases where a single persistent proxy connection or connection pool is used while the application logs show requests to multiple different origins. On upstream services, search for unexpected Host headers, Authorization headers, cookies, API keys, request paths, or payload formats belonging to other services. Also review error logs for certificate, protocol, redirect, mixed-content, or HTTP/HTTPS scheme inconsistencies, because intended HTTPS requests may have been routed incorrectly or downgraded. If an attacker-controlled or untrusted origin was contacted first by an affected service, examine that origin's logs and rotate any credentials that may have appeared in subsequent requests. Because known public exploitation is not established, treat findings as data exposure indicators rather than relying on known malware, process, or file artifacts.

• Socks5ProxyAgent
• setGlobalDispatcher
• undici@7.23.0
• undici@7.24.0
• undici@7.25.0
• undici@8.0.0
• undici@8.1.0
• Host header mismatch
• SNI mismatch
• unexpected Host header
• Authorization: Bearer
• X-API-Key
• Cookie:
• http://

What your security team should do

• Inventory Node.js services that use undici and prioritize those using Socks5ProxyAgent or setGlobalDispatcher with SOCKS5 proxying.
• Upgrade affected services to undici v7.26.0 or v8.2.0 or later, and rebuild/redeploy artifacts so fixed versions are present at runtime.
• Search source code and dependency manifests for Socks5ProxyAgent usage and shared global dispatcher patterns that make requests to multiple origins.
• If upgrades require scheduling, immediately isolate by creating one Socks5ProxyAgent per origin or disabling SOCKS5 proxying for multi-origin outbound requests.
• Review secrets exposure risk for services that may have sent authorization headers, cookies, API keys, or sensitive request bodies to unintended origins.
• Rotate credentials that could have been sent through vulnerable multi-origin SOCKS5 request flows, especially tokens used in Authorization, Cookie, X-API-Key, and similar headers.
• Add regression tests that assert outbound requests through SOCKS5 reach the intended host and scheme when multiple origins are used.
• Monitor outbound access logs, proxy logs, and application telemetry for requests whose Host header, URL, SNI, or expected destination do not match the connected upstream service.