CVE-2026-97687 is a high severity (CVSS 8.1) flaw in the Python urllib3 library from 1.26.0 until 2.8.0. TLS settings meant for the target server can be applied to the HTTPS proxy connection, which can disable proxy certificate verification. The fix is urllib3 2.8.0.
What's affected
The urllib3 advisory lists versions from 1.26.0 up to but not including 2.8.0 as affected, and 2.8.0 as patched. The weaknesses are CWE-295, improper certificate validation, and CWE-440, expected behavior violation.
The advisory explains that urllib3 lets you configure TLS separately for an HTTPS proxy and for the target server, but in the affected versions the two were not kept apart. Depending on the proxy mode, target settings could replace the proxy's settings. Setting cert_reqs to CERT_NONE for a target could overwrite the verify mode of the context configured for the proxy. The change happened in place and persisted, so later connections that reused the context might skip proxy certificate verification.
The advisory says that in CONNECT tunneling mode, impersonating the proxy does not by itself defeat the separate end to end TLS connection to the target. HTTPS forwarding mode is the more exposed one.
How to check if you're exposed
Find urllib3 in every Python environment, including those pulled in by requests and other libraries.
pip show urllib3
python -c "import urllib3; print(urllib3.__version__)"
pip freeze | grep -i urllib3
Then check whether your code reaches the affected configuration. Search for proxy settings and TLS overrides.
grep -rn "proxy_ssl_context\|cert_reqs\|use_forwarding_for_https" --include=*.py .
Code that uses no HTTPS proxy is not exposed to the proxy impersonation path, though you should still upgrade.
What to do now
- Upgrade urllib3 to 2.8.0 or later with pip install, and update lock files so builds do not go back.
- Check libraries that pin or vendor urllib3 and update them as well.
- If your code disables verification for a target server, review it and avoid sharing one SSL context object between proxy and target settings.
- Rebuild container images and virtual environments that carry the old version.
- Where you use HTTPS forwarding through a proxy, review the proxy's trust configuration and the credentials sent through it.
- Paste your lockfile or manifest into the free in-browser dependency scan to see whether the affected package is in your tree, then use reachability analysis to separate code paths you call from ones you never touch.
Why it matters
The bug is a case of one setting leaking into another. A developer who turns off verification for a single target, perhaps for a test server, would not expect that to change how the proxy is treated. CWE-295 is the result: a certificate check that is skipped when the code believes it is on. Mutating a shared object makes the mistake last for later connections.
The attacker must be positioned to intercept the connection to the proxy. If they are, the advisory says they can see or change forwarded traffic and may receive a target client certificate. The record does not mark exploitation and the CVE is not in CISA's catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does every urllib3 user need to worry?
The conditions involve an HTTPS proxy and target specific TLS settings. Upgrade anyway, since the library is so widely shared.
What is the fixed version?
urllib3 2.8.0.
Sources
Last reviewed: 18 October 2026.
