urllib3 EUVD-2026-89000

Requires ALL of the following, which sharply narrow the exposed population: (1) the application must use an HTTPS proxy (not a plain HTTP proxy), specifically HTTPS forwarding (use_forwarding_for_https=True) or a proxy connection that mixes target and proxy TLS policy; (2) the application must configure target-server TLS settings that are supposed to stay separate from the proxy handshake - one of proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, or CERT_NONE - where cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place and persist across reused connections; and (3) the attacker must hold a man-in-the-middle position to intercept and impersonate the HTTPS proxy with their own certificate. Limiting factors: end-to-end target TLS via CONNECT tunneling is NOT affected (the separate target TLS connection is preserved); a default urllib3 deployment without an HTTPS proxy, or one that does not override target TLS policy, is not exploitable. urllib3 versions before 1.26.0 or 2.8.0 and later are unaffected.

This is a genuine but conditional certificate-validation flaw (CWE-295) in urllib3, one of the most widely deployed Python libraries. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N) scores 7.6 and correctly captures high confidentiality AND integrity impact with no availability impact, plus an attack requirement (AT:P) and passive user interaction (UI:P) that reflect the real preconditions. No EPSS score, KEV listing, or public exploit code is present in the input - the referenced GitHub PR (#5093) and two commits are the FIX, not exploit code, so this is 'no public exploit identified at time of analysis,' not active exploitation. The practical risk is gated by two non-trivial prerequisites that raise real-world attack complexity above the vendor's AC:L: the application must (1) use an HTTPS proxy and (2) configure target-server TLS settings (e.g. cert_reqs=CERT_NONE, custom ssl_context, use_forwarding_for_https=True) that bleed into and weaken the proxy handshake, AND the attacker must occupy a man-in-the-middle position on the proxy path. It is therefore a real priority for the specific population running HTTPS-forwarding proxies with mixed target/proxy TLS policy, but not a broadly wormable/mass-exploitable issue for the typical urllib3 user who does not use an HTTPS proxy. Note the vendor uses AC:L in 4.0 while the config-and-MITM dependency argues for higher complexity - this is captured via AT:P/UI:P in 4.0 and via AC:H in the independent 3.1 assessment below.

A Python application routes HTTPS traffic through an HTTPS proxy while setting target-server TLS options (such as cert_reqs=CERT_NONE or a custom ssl_context), which are erroneously applied to - and can mutate in place - the proxy's certificate policy, disabling proxy certificate verification for reused connections. An attacker positioned on the network path to the proxy impersonates the HTTPS proxy with their own certificate, which the weakened policy now accepts. No public exploit code exists; the attacker must already hold a MITM position and the app must use the vulnerable proxy configuration.