Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process. The following link provides references to all essential vulnerability management information. If something is wrong or missing, please contact a member of PSIRT. https://spaces.redhat.com/display/PRODSEC/Vulnerability+Management+-+Essential+Documents+for+Engineering+Teams
https://bugzilla.redhat.com/show_bug.cgi?id=2428651#c1 The pip uses bundled urllib3 in a way that completely prevents vulnerabilities CVE-2025-66418 and CVE-2025-66471 from being exploited. Both vulnerabilities are in the urllib3 code that handles decompression of the HTTP content, but pip makes sure that this code is never executed. I've investigated the code and also manually verified that: - pip uses `Accept-Encoding: identity` HTTP headers to prevent HTTP servers from compressing served content in any way, see the reasoning for this in: https://github.com/pypa/pip/blob/91d1ae2f22df116f710931133db46130dc07e945/src/pip/_internal/network/utils.py#L7-L26 - When pip reads chunks of a response, it uses `decode_content=False` to prevent urllib3 and requests libraries from decoding/decompressing the received content. See: https://github.com/pypa/pip/blob/91d1ae2f22df116f710931133db46130dc07e945/src/pip/_internal/network/utils.py#L67-L89 pip needs this to be able to calculate checksums from received data, and decompressing them on urllib3 level would make it impossible. - I've manually verified that when a (malicious) server is forced to respond with compressed content, pip is not ready for that, reads raw compressed data without decompressing in lower layers, and then fails when it tries to unpack the downloaded archive in the expected format. pip is also not vulnerable to CVE-2026-21441. When it comes to handling redirects, pip uses the implementation on the requests level, so the vulnerable code in urllib3 is present there, but it's never executed. Therefore, pip is not vulnerable even if it bundles and uses any of the vulnerable versions of urllib3.