CVE-2026-55553

urllib is an HTTP client for Node.js that supports authentication, redirects, timeouts, and other request features. Prior to 4.9.1 and 2.44.1, urllib follows redirects through followRedirect but reuses caller-supplied options across origins. In src/HttpClient.ts, #requestInternal recursively calls this.#requestInternal(nextUrl.href, options, requestContext), causing options.headers and auth or digestAuth values to be reused when the redirect target has a different scheme, host, or port. Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, and x-access-token can therefore be sent to an attacker-controlled redirected origin, exposing credentials intended for the original origin and potentially allowing reuse against the original partner API or related services. No user interaction is required. This issue is fixed in versions 2.44.1 and 4.9.1.

urllib is an HTTP client for Node.js that supports authentication, redirects, timeouts, and other request features. Prior to 4.9.1 and 2.44.1, urllib follows redirects through followRedirect but reuses caller-supplied options across origins. In src/HttpClient.ts, #requestInternal recursively calls this.#requestInternal(nextUrl.href, options, requestContext), causing options.headers and auth or digestAuth values to be reused when the redirect target has a different scheme, host, or port. Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, and x-access-token can therefore be sent to an attacker-controlled redirected origin, exposing credentials intended for the original origin and potentially allowing reuse against the original partner API or related services. No user interaction is required. This issue is fixed in versions 2.44.1 and 4.9.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):

     // https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
      if (RedirectStatusCodes.includes(res.statusCode) && maxRedirects > 0 && requestContext.redirects < maxRedirects) {
        if (res.headers.location) {
          requestContext.redirects++;
          const nextUrl = new URL(res.headers.location, requestUrl.href);
          // Ensure the response is consumed
          await response.body.arrayBuffer();
          debug(
            'Request#%d got response, status: %s, headers: %j, timing: %j, redirect to %s',
            requestId,
            res.status,
            res.headers,
            res.timing,
            nextUrl.href,
          );
          return await this.#requestInternal(nextUrl.href, options, requestContext);
        }
      }

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.

[client container]                       [partner container]              [attacker container]
hostname: client                         hostname: partner                hostname: attacker
                                         port: 3001                       port: 3002
   urllib v4.9.0
        │
        │ GET http://partner:3001/start
        │ + 6 credential-bearing headers
        ↓
                                         302 Location:
                                         http://attacker:3002/captured
                                                   │
                                                   │ urllib follows redirect
                                                   │ → DIFFERENT ORIGIN
                                                   │   (different hostname and port)
                                                   │ → all 6 headers preserved
                                                   ↓
                                                                          headers logged
                                                                          inside attacker
                                                                          container

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

• source…

urllib is an HTTP client for Node.js that supports authentication, redirects, timeouts, and other request features. Prior to 4.9.1 and 2.44.1, urllib follows redirects through followRedirect but reuses caller-supplied options across origins. In src/HttpClient.ts, #requestInternal recursively calls this.#requestInternal(nextUrl.href, options, requestContext), causing options.headers and auth or digestAuth values to be reused when the redirect target has a different scheme, host, or port. Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, and x-access-token can therefore be sent to an attacker-controlled redirected origin, exposing credentials intended for the original origin and potentially allowing reuse against the original partner API or related services. No user interaction is required. This issue is fixed in versions 2.44.1 and 4.9.1.

urllib is an HTTP client for Node.js that supports authentication, redirects, timeouts, and other request features. Prior to 4.9.1 and 2.44.1, urllib follows redirects through followRedirect but reuses caller-supplied options across origins. In src/HttpClient.ts, #requestInternal recursively calls this.#requestInternal(nextUrl.href, options, requestContext), causing options.headers and auth or digestAuth values to be reused when the redirect target has a different scheme, host, or port. Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, and x-access-token can therefore be sent to an attacker-controlled redirected origin, exposing credentials intended for the original origin and potentially allowing reuse against the original partner API or related services. No user interaction is required. This issue is fixed in versions 2.44.1 and 4.9.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):

     // https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
      if (RedirectStatusCodes.includes(res.statusCode) && maxRedirects > 0 && requestContext.redirects < maxRedirects) {
        if (res.headers.location) {
          requestContext.redirects++;
          const nextUrl = new URL(res.headers.location, requestUrl.href);
          // Ensure the response is consumed
          await response.body.arrayBuffer();
          debug(
            'Request#%d got response, status: %s, headers: %j, timing: %j, redirect to %s',
            requestId,
            res.status,
            res.headers,
            res.timing,
            nextUrl.href,
          );
          return await this.#requestInternal(nextUrl.href, options, requestContext);
        }
      }

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.

[client container]                       [partner container]              [attacker container]
hostname: client                         hostname: partner                hostname: attacker
                                         port: 3001                       port: 3002
   urllib v4.9.0
        │
        │ GET http://partner:3001/start
        │ + 6 credential-bearing headers
        ↓
                                         302 Location:
                                         http://attacker:3002/captured
                                                   │
                                                   │ urllib follows redirect
                                                   │ → DIFFERENT ORIGIN
                                                   │   (different hostname and port)
                                                   │ → all 6 headers preserved
                                                   ↓
                                                                          headers logged
                                                                          inside attacker
                                                                          container

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

• source…

urllib is an HTTP client for Node.js that supports authentication, redirects, timeouts, and other request features. Prior to 4.9.1 and 2.44.1, urllib follows redirects through followRedirect but reuses caller-supplied options across origins. In src/HttpClient.ts, #requestInternal recursively calls this.#requestInternal(nextUrl.href, options, requestContext), causing options.headers and auth or digestAuth values to be reused when the redirect target has a different scheme, host, or port. Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, and x-access-token can therefore be sent to an attacker-controlled redirected origin, exposing credentials intended for the original origin and potentially allowing reuse against the original partner API or related services. No user interaction is required. This issue is fixed in versions 2.44.1 and 4.9.1.

Root has patched CVE-2026-55553 in the urllib package for Root:npm. Multiple fixed versions available.