CVE-2026-44431

What it actually does

urllib3 versions 1.23 through versions before 2.7.0 can incorrectly retain sensitive request headers when using the low-level ProxyManager.connection_from_url().urlopen(...) API with assert_same_host=False and following a redirect to a different origin. If an application sends headers such as Authorization, Proxy-Authorization, Cookie, or other bearer credentials and the response redirects to an attacker-controlled or unintended host, those headers may be forwarded cross-origin, exposing credentials to that destination. The issue is limited to specific low-level usage patterns and requires redirect-following behavior plus sensitive headers being present, which aligns with the high attack complexity reflected in the CVSS vector.

Why it matters to the business

Applications that use affected urllib3 versions in this pattern may leak API tokens, session cookies, proxy credentials, or service authorization headers to an unintended external host. The likely consequence is credential compromise, which can lead to unauthorized access to third-party APIs, internal services, customer data, or downstream systems depending on what the leaked credential permits. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware association, but urllib3 is widely used across Python ecosystems, so organizations should prioritize inventory and upgrade where the vulnerable API pattern exists.

How an attack unfolds

An attacker first needs a way to influence a URL that a Python application fetches using urllib3's low-level ProxyManager.connection_from_url().urlopen(...) interface, or they need to control a service that the application legitimately contacts. The application must be running urllib3 from 1.23 before 2.7.0, must call urlopen with assert_same_host=False, must allow redirects, and must attach sensitive headers to the request. The attacker-controlled or compromised endpoint then returns an HTTP redirect to a different origin controlled by the attacker. Because of the flaw, urllib3 may continue forwarding sensitive headers on the redirected cross-origin request. The attacker receives the redirected request and captures the exposed headers from web server, proxy, or application logs, then attempts to reuse the leaked tokens, cookies, or credentials against the services for which they are valid.

How to fix it

Upgrade urllib3 to version 2.7.0 or later wherever it is present directly or transitively. If immediate upgrade is not possible, avoid using ProxyManager.connection_from_url().urlopen(...) with assert_same_host=False when sensitive headers are present, disable automatic redirects for such requests, or manually strip Authorization, Proxy-Authorization, Cookie, and other secret-bearing headers before following redirects to a different host. Review dependency lockfiles, container images, vendored Python packages, and application bundles because urllib3 is often pulled in indirectly by higher-level HTTP clients. Rotate any credentials that may have been exposed through affected redirect flows.

How to confirm the fix worked

Confirm that all deployed Python environments, containers, build artifacts, and lockfiles resolve urllib3 to 2.7.0 or later. Use package inventory commands such as pip show urllib3, pip freeze, pipdeptree, poetry show urllib3, pipenv graph, or SBOM/dependency scanner output to verify the effective version. Review application code for ProxyManager.connection_from_url, urlopen, assert_same_host=False, redirect handling, and custom sensitive headers. To validate behavior, create a controlled test with one endpoint that receives a request containing a test Authorization header and returns a redirect to a second different host; after remediation, the second host should not receive the sensitive header.

Typical attack path

1. Identify or influence an application workflow that makes outbound HTTP requests through Python urllib3 ProxyManager.
2. Ensure the target application uses urllib3 version 1.23 through before 2.7.0 and calls urlopen with assert_same_host=False.
3. Cause the application to send a request containing sensitive headers such as Authorization, Proxy-Authorization, or Cookie.
4. Return or trigger an HTTP 3xx redirect to a different attacker-controlled origin.
5. Receive the redirected request and capture sensitive headers that should not have been forwarded cross-origin.
6. Replay or abuse the leaked credential against the relevant API, proxy, or service until it is revoked or expires.

How to detect it

There is no universal host-based IOC for exploitation because this is a library behavior flaw that results in credential leakage during outbound HTTP redirects. To assess prior exploitation, review application logs, outbound proxy logs, egress gateway logs, WAF logs, and destination service access logs for HTTP 3xx responses followed by requests to a different scheme, host, or port where sensitive headers were still present. Focus on applications using urllib3 1.23 through before 2.7.0, especially code paths containing ProxyManager.connection_from_url().urlopen(..., assert_same_host=False). Look for redirects from trusted or expected domains to unexpected external domains, newly registered domains, IP-literal hosts, or attacker-controlled infrastructure. If full HTTP headers are logged by a proxy or controlled test server, search for Authorization, Proxy-Authorization, Cookie, X-Api-Key, or similar headers appearing in requests immediately after cross-origin redirects. Also review credential audit logs for token use from unusual IP addresses, unexpected user agents, new geographies, or services that correlate with redirect events.

• ProxyManager.connection_from_url
• assert_same_host=False
• urlopen(
• Authorization: Bearer
• Proxy-Authorization:
• Cookie:
• X-Api-Key:
• HTTP/1.1 301
• HTTP/1.1 302
• HTTP/1.1 303
• HTTP/1.1 307
• HTTP/1.1 308
• Location: http://
• Location: https://

What your security team should do

• Inventory urllib3 usage across source repositories, dependency lockfiles, containers, serverless packages, and Python virtual environments.
• Prioritize remediation for applications that perform outbound HTTP requests to user-influenced URLs, follow redirects, use proxies, or attach Authorization, Proxy-Authorization, Cookie, API key, or bearer-token headers.
• Upgrade urllib3 to 2.7.0 or later and rebuild/redeploy affected artifacts rather than only updating source manifests.
• Search code for ProxyManager.connection_from_url, urlopen, and assert_same_host=False to identify the vulnerable usage pattern.
• Disable automatic redirects or enforce same-origin redirect policy for requests that carry credentials.
• Rotate credentials that could have been sent through affected redirect paths, especially long-lived API tokens and proxy credentials.
• Add regression tests ensuring sensitive headers are removed when redirects cross scheme, host, or port boundaries.
• Monitor outbound proxy, egress gateway, and destination web server logs for credential-bearing headers sent to unexpected domains.