CVE-2025-50181

What it actually does

This flaw affects urllib3 redirect handling, where redirects and retries are governed through the same Retry mechanism. In affected versions, application code that attempts to disable redirects at the individual request level, such as by using redirect=False, may not reliably prevent redirect processing under certain retry/redirect configurations. The practical technical impact is that an HTTP client may follow an attacker-controlled Location header even when the calling application expected redirect following to be disabled. This can cause outbound requests to unintended destinations and may weaken application-level controls that rely on blocking redirects, such as URL allowlists, anti-SSRF protections, or logic intended to inspect redirect responses without dereferencing them.

Why it matters to the business

Organizations using vulnerable urllib3 versions in Python applications may have services that make unintended outbound HTTP requests if they process attacker-influenced URLs or responses. The most likely business impact is exposure to server-side request forgery-style behavior, unexpected access to internal or restricted network locations, leakage of request metadata to attacker-controlled endpoints, or bypass of business logic that depends on redirects being blocked. The CVSS score is moderate, EPSS is low, and it is not listed in CISA KEV or associated with ransomware campaigns, so remediation should be prioritized through normal dependency management rather than treated as an active emergency unless the library is used in security-sensitive URL fetching paths.

How an attack unfolds

An attacker first identifies an application workflow that uses urllib3 to fetch a URL or communicate with an HTTP endpoint where the attacker can influence either the initial URL or the HTTP response. The application believes redirects are disabled for that request, commonly to avoid following untrusted Location headers. The attacker then returns an HTTP 3xx redirect response with a Location header pointing to an attacker-controlled, internal, cloud metadata, or otherwise sensitive destination. Due to the vulnerable redirect/retry interaction, urllib3 may follow the redirect despite the request-level redirect=False expectation. The application then makes an outbound request to the redirected target, which can disclose network reachability, send request metadata, trigger unintended actions, or interact with resources the attacker could not directly access.

How to fix it

Upgrade urllib3 to a version that includes the upstream fix. For source-based deployments tracking the urllib3 Git repository, ensure the code includes commit aaab4eccc10c965897540b21e15f11859d0b62e7 or a later release containing that commit. Rebuild and redeploy all applications, containers, virtual environments, serverless packages, and vendored dependencies that include urllib3. Where immediate upgrade is not possible, reduce exposure by avoiding attacker-controlled URLs, enforcing strict destination allowlists before every outbound request, validating the final resolved destination independently, blocking access to internal address ranges and cloud metadata endpoints at the network layer, and disabling or tightly configuring Retry redirect behavior globally rather than relying only on request-level redirect=False.

How to confirm the fix worked

Confirm the installed urllib3 version or source revision includes the fixed commit aaab4eccc10c965897540b21e15f11859d0b62e7 or a later patched release. Use software composition analysis, package lockfiles, container image scans, and runtime package inspection to identify all copies of urllib3, including vendored or transitive copies. Functionally validate the fix by creating a controlled test endpoint that returns a 3xx response with a Location header and verifying that application code using redirect=False does not issue a follow-up request to the redirected URL. Also verify outbound egress controls block internal IP ranges, link-local metadata services, and unapproved external domains regardless of application behavior.

Typical attack path

1. Find an application feature that performs outbound HTTP requests using urllib3, such as URL previewing, webhook delivery, file import, API polling, or backend service integration.
2. Provide or influence a URL, endpoint, or upstream HTTP service that the application will contact.
3. Return an HTTP 301, 302, 303, 307, or 308 response containing a crafted Location header.
4. Point the Location header to an attacker-controlled host or a restricted internal destination.
5. Rely on the vulnerable urllib3 redirect/retry behavior to follow the redirect even though the application attempted to disable redirects for the request.
6. Observe the resulting connection, captured request metadata, or effects of the unintended request to confirm impact.

How to detect it

There are no reliable CVE-specific indicators that prove exploitation because the behavior appears as ordinary HTTP redirect traffic. To assess possible prior exploitation, review application logs, HTTP client debug logs, reverse proxy logs, egress proxy logs, DNS logs, firewall logs, and cloud network flow logs for cases where an application received a 3xx response and then immediately made a follow-up outbound request to the Location target despite redirect blocking being expected. Pay special attention to redirects from attacker-controlled or user-supplied URLs to private IP ranges, loopback addresses, link-local addresses such as cloud metadata services, unusual ports, newly observed domains, or domains not normally contacted by the service. If urllib3 debug logging was enabled, search for redirect-related log messages around suspicious requests. Correlate timestamps between inbound user actions, upstream 3xx responses, DNS resolutions, and outbound connections to determine whether an attacker caused unintended follow-up requests.

What your security team should do

• Inventory all Python applications, containers, build artifacts, and vendored libraries that include urllib3.
• Prioritize remediation for services that fetch user-supplied URLs, process webhooks, crawl external content, proxy HTTP requests, or communicate with semi-trusted third-party endpoints.
• Upgrade urllib3 to a patched version or source revision containing commit aaab4eccc10c965897540b21e15f11859d0b62e7, then rebuild and redeploy affected artifacts.
• Add regression tests proving redirect=False requests do not follow 3xx Location headers in security-sensitive code paths.
• Enforce centralized outbound request controls: scheme restrictions, DNS/IP validation, denylisting of private and link-local ranges, and approved-domain allowlists.
• Review retry and redirect configuration across shared HTTP client wrappers to ensure redirect behavior is explicit and not inherited unintentionally.
• Monitor application and egress logs for unexpected 3xx-to-follow-up-request sequences, especially toward internal address space or unfamiliar external domains.
• Treat this as normal-priority dependency remediation unless local exposure involves untrusted URL fetching or internal network reachability, in which case raise priority.