CVE-2026-97687: urllib3: HTTPS proxy TLS configuration may be ignored or overridden
urllib3 is an HTTP client library for Python. From 1.26.0 until 2.8.0, the proxysslcontext, proxyasserthostname, proxyassertfingerprint, sslcontext, certreqs, verifymode, useforwardingforhttps=True, and CERTNONE 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 certreqs=CERTNONE can overwrite proxysslcontext.verifymode 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
urllib3to a version that resolves this vulnerability.Fixed in 2.8.0
Event History
Frequently Asked Questions
Which deployments are realistically exposed to interception?
Applications using an HTTPS proxy and configuring TLS settings intended for the target server are exposed when those settings weaken or alter verification of the proxy connection. The practical attack requires an attacker to intercept and impersonate the HTTPS proxy after the effective proxy policy accepts the attacker’s certificate.
Does this affect ordinary CONNECT-based HTTPS proxying in the same way?
CONNECT tunneling preserves the separate end-to-end TLS connection to the target server. The described traffic observation, modification, and possible exposure of a target TLS client certificate applies to HTTPS forwarding, including use of use_forwarding_for_https=True with target-specific identity or credentials.
Can the unsafe proxy verification state persist beyond one request?
Yes. Setting cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place, and the changed context can be reused by later connections that then connect to the HTTPS proxy without certificate verification.
What version contains the fix?
The issue is fixed in urllib3 2.8.0. The affected range is from 1.26.0 until 2.8.0.