AI analysis
In urllib3 from 1.26.0 before 2.8.0, TLS settings meant only for the target server are applied to the HTTPS proxy connection, so proxy and target certificate policies are not kept separate. The bug is triggered when an application uses an HTTPS proxy together with target TLS options that must stay off the proxy handshake, including cert_reqs=CERT_NONE, verify_mode, a custom ssl_context, or use_forwarding_for_https=True; setting CERT_NONE can overwrite proxy_ssl_context.verify_mode in place, and that change persists for later connections that reuse the same context. An attacker who can intercept the path to the proxy can impersonate it once the weakened proxy policy accepts the attacker's certificate, then observe or modify forwarded traffic or receive a target TLS client certificate, while CONNECT tunneling still preserves the separate end-to-end target TLS session. Python applications on a vulnerable urllib3 release that use an HTTPS proxy with those configuration paths are affected. No public proof of concept is known, and the issue is not in CISA's Known Exploited Vulnerabilities catalog.
What to do: Upgrade urllib3 to 2.8.0 or later. Until then, do not apply target-only TLS settings (especially cert_reqs=CERT_NONE, verify_mode, or a shared ssl_context) to connections that also use an HTTPS proxy, and do not reuse a proxy SSL context after those settings have been applied. Review apps that set use_forwarding_for_https or custom proxy_ssl_context, proxy_assert_hostname, or proxy_assert_fingerprint values.
Affected
| urllib3 | 1.26.0 before 2.8.0 (fixed in 2.8.0) |
Estimated exposure
masswell over 1 million Python environments include the affected library; only those using an HTTPS proxy with the vulnerable TLS settings are exploitable — urllib3 is a standard dependency of Python HTTP stacks such as requests and is among the most-downloaded packages on PyPI, so installs of the affected 1.26 and 2.x lines far exceed one million, but there is no public count of deployments…
Description
urllib3 is an HTTP client library for Python. From 1.26.0 until 2.8.0, the proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, use_forwarding_for_https=True, and CERT_NONE configuration paths fail to remain separated because target-server TLS settings are incorrectly applied to the HTTPS proxy connection. The trigger is that an application uses an HTTPS proxy and configures target-server TLS settings that must remain separate from the proxy TLS handshake, including HTTPS forwarding with target-specific identity or credentials. Applying cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place, and the mutation persists so later connections reusing the same context may connect to the HTTPS proxy without certificate verification. The attack mechanism is that an attacker intercepts and impersonates the HTTPS proxy after the effective proxy policy accepts the attacker's certificate. The impact is that the attacker can observe or modify forwarded traffic or receive a target TLS client certificate, while CONNECT tunneling still preserves the separate end-to-end target TLS connection. This issue is fixed in version 2.8.0.