node-modules urllib CVE-2026-55553

The followRedirect option must be active (it is the default behavior in urllib); applications that explicitly set followRedirect: false are not affected. The original request must supply credential-bearing headers - Authorization, Cookie, Proxy-Authorization, x-api-key, x-auth-token, x-access-token - or configure options.auth (Basic) or options.digestAuth; requests with no credentials in headers or options are not affected. The attacker must control or influence the redirect target URL, meaning they must either operate the redirecting server, exploit an open redirect vulnerability on a trusted upstream host, or otherwise inject a Location header pointing to their infrastructure. Exploitation is limited to the urllib v3/v4 branch (>=3.0.0, <=4.9.0) and v2 branch (<=2.44.0); GHSA confirmed that urllib was the only tested Node.js HTTP client that did not strip headers on cross-origin redirect as of v4.9.0. No user interaction by a human operator is required once the attacker controls the redirect target.

The NVD CVSS 3.1 score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N) accurately reflects the network-exposed, unauthenticated nature of the flaw from the attacker's perspective, but AC:L may slightly overstate ease of exploitation: the attacker must be positioned to control or influence the redirect target URL, which requires either owning an upstream service, abusing an open redirect vulnerability on a trusted partner endpoint, or operating in an SSRF-adjacent scenario. No EPSS score was provided in the input data, so exploitation probability cannot be independently quantified. There is no CISA KEV entry, meaning active in-the-wild exploitation is unconfirmed. A working three-container proof-of-concept topology is documented in the GHSA advisory (GHSA-hq3h-g68c-hp78), confirming exploitability in controlled conditions. Real-world impact is highest in server-to-server API integration patterns where urllib is used with long-lived Bearer tokens or session cookies and where the upstream API can be caused to issue redirects to attacker-controlled hosts. Applications using urllib solely on same-origin infrastructure with no possibility of attacker-influenced redirect targets face significantly reduced practical risk despite the high CVSS score.

An application backend uses urllib with a long-lived Bearer token to call a partner REST API. An attacker who can influence the partner API's redirect responses - for example by exploiting an open redirect on that partner's domain or by compromising the partner's DNS - causes the partner endpoint to issue a 302 redirect to an attacker-controlled server. urllib follows the redirect and forwards the original Authorization: Bearer LIVE-AUTH header to the attacker's server, which logs the credential. The attacker then replays the token directly against the original partner API to access data or perform privileged actions. A three-container reproduction topology demonstrating this scenario is documented in the GHSA advisory.