GHSA-hq3h-g68c-hp78

Описание

Summary

urllib supports redirect-following through followRedirect, which is expected behavior for an HTTP client. The issue is that, when following a redirect to a different origin, urllib preserves the caller-supplied request headers verbatim, including credential-bearing headers such as Authorization, Cookie, Proxy-Authorization, and custom auth headers (x-api-key, x-auth-token, x-access-token).

If the redirect target is attacker-controlled or outside the trust boundary of the original target, credentials intended for the original origin can be delivered to the redirected origin. In a local multi-library reproduction, urllib v4.9.0 was the only tested client that stripped no headers on cross-origin redirect.

Affected behavior

Confirmed against urllib v4.9.0. The relevant code is in #requestInternal (src/HttpClient.ts:639-656):

The recursive call this.#requestInternal(nextUrl.href, options, requestContext) reuses the original options object. If the caller supplied credential-bearing headers in options.headers, those headers are reused for the redirected request, regardless of whether the redirect target shares the original origin.

Redirect-header handling context

The CHANGELOG suggests that redirect-related header handling has been considered before, including changes around preserving or cleaning up Host during redirects. Given that context, sensitive-header stripping may be an unintentional gap rather than an explicit policy decision.

Proof of Concept: 3-container topology

The reproduction uses three separate containers (partner, attacker, client) connected over a Podman bridge network. Each container has its own hostname, port, and process, so the redirect crosses a clear origin boundary. This is not a localhost vs 127.0.0.1 same-host case.

The origin tuple is (scheme, host, port):

• source origin: http://partner:3001
• destination origin: http://attacker:3002

The host and port both differ, so the redirect target is a different URL origin. The headers are logged in a separate process inside a separate container.

Client invocation (client/poc.mjs):

Observed result
urllib 4.9.0, Node.js 22.22.2, linux/arm64:

The user-agent value confirms that the redirected request was sent by urllib v4.9.0.

Independent reproduction: multi-library comparison

A separate local harness tested the same cross-origin redirect topology against multiple Node.js HTTP clients:

• same partner:3001 → attacker:3002 redirect;
• same six credential-bearing headers;
• same RFC 6454 origin boundary.

The results were deterministic across runs:

urllib was the only tested library that stripped no headers on cross-origin redirect. Custom auth headers such as x-api-key, x-auth-token, and x-access-token are an ecosystem-wide gap in this comparison. The urllib-specific issue is the absence of any strip step for standard credential-bearing headers such as Authorization, Cookie, and Proxy-Authorization.

The reproduction harness is small and can be shared if useful.

Impact

This affects Node.js applications that use urllib to make authenticated HTTP requests while allowing redirects to be followed automatically.

This exposes credentials to an origin that was not the intended recipient. Depending on the credential type and server-side validation, the leaked credentials may be reusable against the original partner API or related services.

This requires no user interaction. Realistic triggers include compromised partner subdomains, DNS hijacking, malicious partner endpoints during onboarding, internal services redirecting across trust boundaries, or an open redirect upstream of urllib's call site.