Skip to content

GHSA-8988-9cw3-xx77 on Cyberus Linux 26.05

Aliases: GHSA-8988-9cw3-xx77

Packages: python3Packages.urllib3

Status: Plausible

Advisory Information

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:

  1. Ignore proxy_ssl_context and use the target server's SSL context for the TLS connection to an HTTPS forwarding proxy.
  2. Override the HTTPS proxy's certificate-verification policy with the target server's certificate-verification policy.
  3. 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 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.

Remediation

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.

Updates

2026-09-21 21:23 CEST

Metadata changes:

  • Status for package python3Packages.urllib3: “Plausible”

2026-09-21 21:22 CEST

Metadata changes:

  • Status for package python3Packages.urllib3: “New”