VulnerableCode Package Details - pkg:rpm/redhat/python-urllib3@2.6.3-0.1?arch=el8pc

Search for packages

Vulnerability	Summary	Fixed by
VCID-kjka-a931-uygj Aliases: CVE-2026-21441 GHSA-38jv-5279-wg99	Decompression-bomb safeguards bypassed when following HTTP redirects (streaming API) ### Impact urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.6.2/advanced-usage.html#streaming-and-i-o) 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. However, 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 (high CPU usage and large memory allocations for decompressed data; CWE-409). ### Affected usages Applications and libraries using urllib3 version 2.6.2 and earlier to stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. ### Remediation Upgrade to at least urllib3 v2.6.3 in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable [redirects](https://urllib3.readthedocs.io/en/2.6.2/user-guide.html#retrying-requests) by setting `redirect=False` for requests to untrusted source.	There are no reported fixed by versions.
VCID-v365-pn8r-e7dh Aliases: CVE-2025-66418 GHSA-gm62-xv2j-4w53	urllib3 allows an unbounded number of links in the decompression chain 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.	There are no reported fixed by versions.
VCID-zevs-1ge5-y7g7 Aliases: CVE-2025-66471 GHSA-2xpw-w6gg-jr37	urllib3 streaming API improperly handles highly compressed data urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.5.0/advanced-usage.html#streaming-and-i-o) 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.	There are no reported fixed by versions.

Vulnerability

Summary

Fixed by

VCID-kjka-a931-uygj
Aliases:
CVE-2026-21441
GHSA-38jv-5279-wg99

Decompression-bomb safeguards bypassed when following HTTP redirects (streaming API) ### Impact urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.6.2/advanced-usage.html#streaming-and-i-o) 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. However, 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 (high CPU usage and large memory allocations for decompressed data; CWE-409). ### Affected usages Applications and libraries using urllib3 version 2.6.2 and earlier to stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. ### Remediation Upgrade to at least urllib3 v2.6.3 in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable [redirects](https://urllib3.readthedocs.io/en/2.6.2/user-guide.html#retrying-requests) by setting `redirect=False` for requests to untrusted source.

There are no reported fixed by versions.

VCID-v365-pn8r-e7dh
Aliases:
CVE-2025-66418
GHSA-gm62-xv2j-4w53

urllib3 allows an unbounded number of links in the decompression chain 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.

There are no reported fixed by versions.

VCID-zevs-1ge5-y7g7
Aliases:
CVE-2025-66471
GHSA-2xpw-w6gg-jr37

urllib3 streaming API improperly handles highly compressed data urllib3's [streaming API](https://urllib3.readthedocs.io/en/2.5.0/advanced-usage.html#streaming-and-i-o) 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.

There are no reported fixed by versions.

Vulnerability	Summary	Aliases
This package is not known to fix vulnerabilities.

Vulnerability

Summary

Aliases

This package is not known to fix vulnerabilities.

Date	Actor	Action	Vulnerability	Source	VulnerableCode Version
2026-04-16T13:38:41.869361+00:00	RedHat Importer	Affected by	VCID-kjka-a931-uygj	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-21441.json	38.4.0
2026-04-01T13:34:10.787731+00:00	RedHat Importer	Affected by	VCID-v365-pn8r-e7dh	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-66418.json	38.0.0
2026-04-01T13:34:04.548626+00:00	RedHat Importer	Affected by	VCID-zevs-1ge5-y7g7	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2025-66471.json	38.0.0
2026-04-01T13:32:59.599341+00:00	RedHat Importer	Affected by	VCID-kjka-a931-uygj	https://access.redhat.com/hydra/rest/securitydata/cve/CVE-2026-21441.json	38.0.0