CVE-2024-37891
MediumCVSS 4.4Summary
A vulnerability in urllib3 causes the Proxy-Authorization header not to be stripped on cross-origin redirects when not using urllib3's built-in proxy support. This could leak credentials to a malicious server under specific conditions. The severity is low and requires misconfiguration.
Risk Assessment
The risk is low as it requires a rare combination: manually setting Proxy-Authorization without ProxyManager, not disabling redirects, and redirecting to a malicious origin. In typical scenarios, organizations may face proxy credential theft.
Recommendation
Update urllib3 to version 1.26.19 or 2.2.2. If unable to upgrade, use ProxyManager for Proxy-Authorization, disable redirects (redirects=False), or avoid using the header.
Other vulnerabilities in urllib3
See all- CVE-2026-97689High
urllib3 versions from 1.10.3 until 2.8.0 contain an unbounded memory allocation vulnerability. The HTTPResponse.read_chunked and HTTPResponse.stream methods buffer the chunk-size field without a length bound until a newline or EOF is encountered. A malicious HTTP server can send a very long unterminated chunk-size line, leading to exhaustion of the client process memory.
- CVE-2026-97688Medium
In urllib3 (versions 2.6.2 through 2.8.0), the HTTPResponse.stream and HTTPResponse.read_chunked methods can enter an infinite loop because the Deflate decoder retains trailing bytes as unconsumed input after reaching end-of-stream and repeatedly decodes them without progress. The issue occurs when an untrusted server sends a chunked Deflate response whose decoded body exceeds a positive finite chunk size and whose encoded body has trailing bytes.
- CVE-2026-97687High
urllib3 versions from 1.26.0 until 2.8.0 fail to keep target-server TLS settings separate from the HTTPS proxy connection. The proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, use_forwarding_for_https=True, and CERT_NONE configuration paths are affected. Setting cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place, and the mutation persists so later connections may connect to the HTTPS proxy without certificate verification.
- CVE-2026-44432High
The urllib3 HTTP client library for Python versions 2.6.0 to before 2.7.0 contains a vulnerability where the entire response is decompressed instead of the requested portion during the second HTTPResponse.read(amt=N) call when using the official Brotli library, or after HTTPResponse.drain_conn() is called after partial read. This can lead to excessive resource consumption (high CPU usage and memory allocation) on the client side.
- CVE-2026-21441High
The urllib3 Python library versions 1.22 through 2.6.2 incorrectly decompresses entire HTTP redirect response bodies even when using the streaming API. This enables a decompression bomb attack leading to excessive client resource consumption.
- CVE-2025-66471High
urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation, resulting in excessive resource consumption (high CPU usage and massive memory allocation).
- CVE-2025-66418High
urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.
- CVE-2021-28363Medium
The urllib3 library 1.26.x before 1.26.4 for Python omits SSL certificate validation in some cases involving HTTPS to HTTPS proxies. The initial connection to the HTTPS proxy (if an SSLContext isn't given via proxy_config) doesn't verify the hostname of the certificate. This means certificates for different servers that still validate properly with the default urllib3 SSLContext will be silently accepted.
Original NVD description (English source)
urllib3 is a user-friendly HTTP client library for Python. When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3's `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

