URLLIB3 · CVE-2026-97687 · Package
FIX → 2.8.0
urllib3 versions 1.26.0 through 2.7.0 can mix up TLS settings meant for the target server and the HTTPS proxy, so the proxy connection may skip certificate verification. An attacker who can intercept traffic to the proxy can impersonate it and read or change forwarded requests and responses, including credentials and tokens.
first public Sep 15, 2026 · 3 sources
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Applications that route HTTPS requests through an HTTPS forwarding proxy with urllib3 and set separate TLS options for the proxy and the target server are exposed. Code that uses a plain HTTP proxy, or CONNECT tunneling without forwarding, is not affected by the proxy handshake issue, though the advisory notes a client certificate may still be exposed in some cases. Teams that never configure an HTTPS proxy can skip it.
Not affected if connect-tunnel-only, default-config, no-https-proxy, plain-http-proxy
Who cares proxy, pypi, python, self-hosted, urllib3
pip show urllib3 or python -c "import urllib3; print(urllib3.__version__)"; affected versions are 1.26.0 through 2.7.0.proxy_ssl_context, , and to see whether HTTPS proxies are used with forwarding.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:
proxy_ssl_context and use the target server's SSL context for 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.
Check it with your coding agent
It reads this page and tells you if your code is affected.
Are you affected?
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
use_forwarding_for_httpsssl_contextcert_reqs="CERT_NONE" in code that also uses an HTTPS proxy.Upgrade to 2.8.0
urllib3 to 2.8.0 or later.proxy_ssl_context to configure TLS for an HTTPS forwarding proxy; passing ssl_context with use_forwarding_for_https=True emits a FutureWarning in 2.8.0 and raises an error in 3.0.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.
Code using urllib3 versions 1.26.0 through 2.7.0 may be affected in any of the following cases.
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.
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.
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.
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:
Code connecting through a plain HTTP proxy does not establish a TLS connection to the proxy and is not affected by this issue.
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.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.