urllib3 is an HTTP client library for Python. From 1.23 to before 2.7.0, cross-origin redirects followed from the low-level API via ProxyManager.connectionfromurl().urlopen(..., assertsamehost=False) still forward these sensitive headers. This vulnerability is fixed in 2.7.0.
urllib3 is an HTTP client library for Python. From 2.6.0 to before 2.7.0, urllib3 could decompress the whole response instead of the requested portion (1) during the second HTTPResponse.read(amt=N) call when the response was decompressed using the official Brotli library or (2) when HTTPResponse.drainconn() was called after the response had been read and decompressed partially (compression algorithm did not matter here). These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data) on the client side. This vulnerability is fixed in 2.7.0.
urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting preloadcontent=False when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when preloadcontent=False. If upgrading is not immediately possible, disable redirects by setting redirect=False for requests to untrusted source.
https://github.com/urllib3/urllib3/security/advisories/GHSA-gm62-xv2j-4w53 discloses: Unbounded number of links in the decompression chain ====================================================
illia-v published GHSA-gm62-xv2j-4w53 Dec 5, 2025
Package: urllib3 (pip) Affected versions: >=1.24,<2.6.0 Patched versions: 2.6.0
Description ===========
Impact ------
urllib3 supports chained HTTP encoding algorithms for response content according to RFC 9110 (e.g., Content-Encoding: gzip, zstd).
However, 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.
Affected usages ---------------
Applications and libraries using urllib3 version 2.5.0 and earlier for HTTP requests to untrusted sources unless they disable content decoding explicitly.
Remediation -----------
Upgrade to at least urllib3 v2.6.0 in which the library limits the number of links to 5.
If upgrading is not immediately possible, use preloadcontent=False and ensure that resp.headers["content-encoding"] contains a safe number of encodings before reading the response content.
Severity: High 8.9 / 10 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H CVE ID: CVE-2025-66418 Weaknesses: Weakness CWE-770
Credits ------- @illia-v illia-v Reporter @sethmlarson sethmlarson Remediation reviewer @pquentin pquentin Remediation reviewer https://github.com/urllib3/urllib3/security/advisories/GHSA-2xpw-w6gg-jr37 advises: Streaming API improperly handles highly compressed data =======================================================
illia-v published GHSA-2xpw-w6gg-jr37 Dec 5, 2025
Package: urllib3 (pip) Affected versions: >=1.0,<2.6.0 Patched versions: 2.6.0
Description ===========
Impact ------
urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.
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 library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation.
The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side, even if the application only requested a small chunk of data.
Affected usages ---------------
Applications and libraries using urllib3 version 2.5.0 and earlier to stream large compressed responses or content from untrusted sources.
stream(), read(amt=256), read1(amt=256), readchunked(amt=256), readinto(b) are examples of urllib3.HTTPResponse method calls using the affected logic unless decoding is disabled explicitly.
Remediation -----------
Upgrade to at least urllib3 v2.6.0 in which the library avoids decompressing data that exceeds the requested amount.
If your environment contains a package facilitating the Brotli encoding, upgrade to at least Brotli 1.2.0 or brotlicffi 1.2.0.0 too. These versions are enforced by the urllib3[brotli] extra in the patched versions of urllib3.
Credits -------
The issue was reported by @Cycloctane.
Supplemental information was provided by @stamparm during a security audit performed by 7ASecurity and facilitated by OSTIF.
Severity: High 8.9 / 10 CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H CVE ID: CVE-2025-66471 Weaknesses: Weakness CWE-409
Credits -------
@illia-v illia-v Coordinator @pquentin pquentin Remediation reviewer @sethmlarson sethmlarson Analyst @Cycloctane Cycloctane Finder @stamparm stamparm Finder
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. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. 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 library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.
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.
Impact
urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once.
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 library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation.
The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data; CWE-409) on the client side, even if the application only requested a small chunk of data.
Affected usages
Applications and libraries using urllib3 version 2.5.0 and earlier to stream large compressed responses or content from untrusted sources.
stream(), read(amt=256), read1(amt=256), readchunked(amt=256), readinto(b) are examples of urllib3.HTTPResponse method calls using the affected logic unless decoding is disabled explicitly.
Remediation
Upgrade to at least urllib3 v2.6.0 in which the library avoids decompressing data that exceeds the requested amount.
If your environment contains a package facilitating the Brotli encoding, upgrade to at least Brotli 1.2.0 or brotlicffi 1.2.0.0 too. These versions are enforced by the urllib3[brotli] extra in the patched versions of urllib3.
Credits
The issue was reported by @Cycloctane. Supplemental information was provided by @stamparm during a security audit performed by 7ASecurity and facilitated by OSTIF.
Impact
urllib3 supports chained HTTP encoding algorithms for response content according to RFC 9110 (e.g., Content-Encoding: gzip, zstd).
However, 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.
Affected usages
Applications and libraries using urllib3 version 2.5.0 and earlier for HTTP requests to untrusted sources unless they disable content decoding explicitly.
Remediation
Upgrade to at least urllib3 v2.6.0 in which the library limits the number of links to 5.
If upgrading is not immediately possible, use preloadcontent=False and ensure that resp.headers["content-encoding"] contains a safe number of encodings before reading the response content.
It was discovered that urllib3 incorrectly handled certain character sequences. A remote attacker could possibly use this issue to perform CRLF injection.
USN-3990-1 fixed a vulnerability in urllib3. This update provides the corresponding update for Ubuntu 14.04 ESM. Original advisory details: It was discovered that urllib3 incorrectly stripped certain characters from requests. A remote attacker could use this issue to perform CRLF injection. (CVE-2019-11236)
It was discovered that urllib3 incorrectly removed Authorization HTTP headers when handled cross-origin redirects. This could result in credentials being sent to unintended hosts. This issue only affected Ubuntu 16.04 LTS, Ubuntu 18.04 LTS and Ubuntu 18.10. (CVE-2018-20060) It was discovered that urllib3 incorrectly stripped certain characters from requests. A remote attacker could use this issue to perform CRLF injection. (CVE-2019-11236) It was discovered that urllib3 incorrectly handled situations where a desired set of CA certificates were specified. This could result in certificates being accepted by the default CA certificates contrary to expectations. This issue only affected Ubuntu 18.04 LTS, Ubuntu 18.10, and Ubuntu 19.04. (CVE-2019-11324)