Summary
urllib3: HTTPS proxy TLS configuration may be ignored or overridden
Affected Usages
Code using urllib3 versions 1.26.0 through 2.7.0 may be affected in any of the following cases.
1. The target SSL context is used for an HTTPS forwarding proxy
HTTPS requests are forwarded through an HTTPS proxy with use_forwarding_for_https=True, and proxy_ssl_context is configured for the proxy.
urllib3 may ignore proxy_ssl_context and use the target server's ssl_context for the proxy TLS handshake. The proxy may therefore be verified using the target server's trust and certificate policy instead of the policy explicitly configured for the proxy.
2. The target verification policy overrides the proxy policy
An HTTPS proxy is configured with proxy_ssl_context, while the target server uses a different certificate-verification policy.
urllib3 may apply the target server's cert_reqs value to the proxy SSL context. For example, setting cert_reqs="CERT_NONE" for the target server may also disable certificate verification for the HTTPS proxy, even when proxy_ssl_context was configured to require verification.
This issue can affect the TLS connection to an HTTPS proxy in both forwarding and CONNECT tunneling configurations.
3. A mutated proxy SSL context is reused
The same SSL context is reused as proxy_ssl_context across multiple connections, and certificate verification is disabled for one target server.
urllib3 may modify the proxy SSL context's verify_mode in place. Later connections that reuse the same context may therefore connect to the HTTPS proxy without certificate verification.
4. Target-specific TLS identity or credentials are applied to the proxy
HTTPS requests are forwarded through an HTTPS proxy with use_forwarding_for_https=True, and target-specific SNI, hostname assertions, certificate fingerprint assertions, or TLS client credentials are configured.
urllib3 may apply these target-specific settings to the proxy TLS handshake. This may cause urllib3 to:
- send SNI intended for the target server to the proxy;
- verify the proxy using a hostname or certificate fingerprint intended for the target server; or
- present a TLS client certificate intended for the target server to the proxy.
Code connecting through a plain HTTP proxy does not establish a TLS connection to the proxy and is not affected by this issue.
Impact
urllib3 supports configuring TLS independently for an HTTPS proxy and the target server.
proxy_ssl_context, proxy_assert_hostname, and proxy_assert_fingerprint configure the TLS connection to the proxy. ssl_context and the other target-specific TLS parameters configure the connection to the target server.
In urllib3 versions 1.26.0 through 2.7.0, these configurations were not consistently separated. Depending on the proxy mode, urllib3 could:
- Ignore
proxy_ssl_contextand use the target server's SSL context for the TLS connection to an HTTPS forwarding proxy. - Override the HTTPS proxy's certificate-verification policy with the target server's certificate-verification policy.
- Apply target-specific SNI, hostname assertions, certificate fingerprint assertions, or TLS client credentials to the TLS connection to an HTTPS forwarding proxy.
In particular, configuring cert_reqs="CERT_NONE" for a target server could overwrite the verify_mode of the SSL context configured for the HTTPS proxy. This modification occurred in place and persisted on the context object, potentially disabling proxy certificate verification for later connections that reused the same context.
An attacker able to intercept the connection to an HTTPS proxy may be able to impersonate the proxy when the effective proxy TLS configuration disables certificate verification or otherwise accepts the attacker's certificate. This may occur, for example, when the target server's trust or identity policy is incorrectly applied to the proxy connection.
When HTTPS forwarding is enabled, an impersonated proxy can observe or modify forwarded requests and responses, potentially exposing credentials, authentication tokens, request bodies, response data, and other sensitive information.
A TLS client certificate intended for the target server may also be presented to the proxy or to an attacker impersonating it. This can disclose the client's identity and provide proof of possession of the corresponding private key. The private key itself is not transmitted during the TLS handshake.
In CONNECT tunneling mode, impersonating the HTTPS proxy does not by itself defeat the separate end-to-end TLS connection between the client and the target server.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Upgrade to urllib3 2.8.0 or later.
urllib3 2.8.0 independently applies the explicitly configured proxy_ssl_context and proxy-specific certificate assertions to the HTTPS proxy connection. Target-specific SNI, certificate assertions, and TLS client certificate parameters are no longer applied to the HTTPS proxy handshake.
For backward compatibility, when an HTTPS proxy is used with use_forwarding_for_https=True and proxy_ssl_context is not provided, urllib3 2.8.0 continues to use ssl_context for the TLS connection to the proxy. This configuration emits a FutureWarning. In urllib3 3.0, passing ssl_context with use_forwarding_for_https=True for an HTTPS proxy will raise an error. Applications should use proxy_ssl_context to configure TLS for an HTTPS forwarding proxy.
The fixes were implemented in commits b6447295fff7b38fdffc67e0df9712d60cef3cc3 and 07408cec79d1856d81bb42c74a904a24fdb9e465.
Frequently Asked Questions
- What is CVE-2026-97687? CVE-2026-97687 is a high-severity security vulnerability in urllib3 (pip), affecting versions >= 1.26.0, < 2.8.0. It is fixed in 2.8.0.
- Which versions of urllib3 are affected by CVE-2026-97687? urllib3 (pip) versions >= 1.26.0, < 2.8.0 is affected.
- Is there a fix for CVE-2026-97687? Yes. CVE-2026-97687 is fixed in 2.8.0. Upgrade to this version or later.
- Is CVE-2026-97687 exploitable, and should I be worried? Whether CVE-2026-97687 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-97687 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-97687? Upgrade
urllib3to 2.8.0 or later.