OESA-2026-4624: python-urllib3 security update
Sanity-friendly HTTP client for Python Security Fix(es):
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.(CVE-2026-97687)
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
openeuler/python-urllib3to a version that resolves this vulnerability.Fixed in 1.26.18-11.oe2403sp4 - Upgrade
Upgrade
python-urllib3to a version that resolves this vulnerability.Fixed in 2.8.0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using urllib3 with an HTTPS proxy are exposed when they configure TLS settings for the target server that should be distinct from the proxy TLS handshake. Relevant paths include proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, use_forwarding_for_https=True, and CERT_NONE.
What must an attacker be able to do to exploit the flaw?
An attacker must be able to intercept and impersonate the HTTPS proxy after the effective proxy certificate policy accepts the attacker’s certificate. Successful exploitation can allow observation or modification of forwarded traffic, or receipt of a target TLS client certificate.
Does this affect HTTPS CONNECT tunneling?
CONNECT tunneling preserves the separation between proxy and target TLS handling. The described impact concerns HTTPS forwarding where target-server TLS settings can be incorrectly applied to the HTTPS proxy connection.
Why can this affect later connections as well?
Using cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place. That mutation persists, so subsequent connections that reuse the same context may connect to the HTTPS proxy without certificate verification.