CVE-2026-55553: urllib Redirects Can Leak Credentials

A high-severity flaw in the Node.js urllib package can forward authentication headers to a different origin when an application automatically follows an HTTP redirect. CVE-2026-55553 affects urllib through 4.9.0 and the legacy 2.x line through 2.44.0. Maintainers fixed it in 4.9.1 and 2.44.1.

The vulnerable package is the npm client named urllib, not Python’s standard-library urllib or the Python urllib3 package. A vulnerable version alone does not prove that credentials leaked: the application must send caller-supplied credentials, follow a redirect, and cross to a different scheme, host, or port.

Who is affected by CVE-2026-55553?

Developers and operators should check Node.js services, workers, build tools, and automation that use urllib directly or through another dependency. The risk is highest when those requests include bearer tokens, cookies, proxy credentials, API keys, or other custom authentication headers and allow redirects automatically.

Run npm ls urllib in each deployed project and inspect the exact version recorded in the lockfile. A dependency can be transitive, so the package may be present even when it is absent from the top-level package.json.

How the redirect can expose credentials

The advisory says urllib reused the original request options while following redirects. Before the fix, a redirect to another origin could therefore retain headers such as Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, and x-access-token.

A realistic sequence starts with an authenticated request to a trusted partner API. If that endpoint, an intermediary, a misconfigured CDN, or an upstream open redirect returns a location controlled by someone else, the vulnerable client may send the original headers to that destination. No end-user click is required, but an attacker still needs a redirect path across the application’s trust boundary.

This is a confidentiality issue, not evidence of remote code execution or a compromised npm release. GitHub rates it high severity with a CVSS 3.1 score of 7.5. The public advisory does not report active exploitation.

What developers should do now

1. Inventory the exact package path. Check production services, workers, CI jobs, and internal tools with npm ls urllib. Record the direct or transitive parent and the resolved lockfile version.
2. Upgrade the affected line. Move 4.x deployments to at least 4.9.1 and legacy 2.x deployments to at least 2.44.1. Rebuild from a reviewed lockfile and run redirect, proxy, and authentication tests before deployment.
3. Map cross-origin redirects. Identify calls that combine automatic redirects with credentials. Treat a change in scheme, hostname, or port as an origin change, even when both destinations belong to the same vendor.
4. Review evidence before rotating everything. Preserve application, proxy, DNS, egress, and partner logs for the exposure window. Look for redirected requests to unexpected origins, but avoid adding raw secrets to new logs during the investigation.
5. Revoke credentials that may have crossed the boundary. If logs confirm or strongly indicate a credential-bearing request reached an untrusted origin, invalidate the affected token, cookie, API key, or proxy credential. Review subsequent use and related account changes. Updating the package does not revoke a secret that already leaked.
6. Constrain redirects as defense in depth. Until every deployment is patched, disable automatic redirects where possible or allow only explicitly approved destination origins. Rebuild sensitive headers for each destination instead of carrying one header set across trust boundaries.

If an API key may have escaped, the API-key theft response guide explains how to preserve usage evidence, revoke the exposed value, and check who could create a replacement. For dependency-wide secret exposure, the Keyv npm incident checklist shows why direct dependencies and the current registry page are not enough to scope a project.

What not to assume

• A vulnerable urllib version is exposure evidence, not proof that a redirect or credential leak occurred.
• HTTPS protects the request in transit; it does not make an attacker-controlled redirect destination an authorized recipient.
• Rotating every organization secret without scoping the redirect path can destroy useful evidence and create avoidable outages.
• A clean endpoint malware scan cannot determine whether a server-side HTTP client sent a header to the wrong origin.

References

1. node-modules project. “urllib: Cross-origin redirects preserve credential-bearing request headers, leading to potential credential leakage.” GitHub Security Advisory GHSA-hq3h-g68c-hp78, published August 25, 2026. Primary advisory.
2. CVE Program. “CVE-2026-55553.” CVE Record, published August 25, 2026; accessed August 25, 2026. Affected versions and CVSS record.