Urllib3
Monthly
Unbounded memory allocation in urllib3 (1.10.3 through 2.7.x) lets a malicious or machine-in-the-middle HTTP server exhaust the memory of a Python client process by streaming an unterminated chunk-size line in a 'Transfer-Encoding: chunked' response. Only clients that consume the response through the streaming path (HTTPResponse.stream() or HTTPResponse.read_chunked()) are affected; the non-streaming .read() path was already bounded to http.client._MAXLINE. Exploitation is unauthenticated (CVSS:4.0 vector PR:N, assessed CVSS:3.1 PR:N) but requires the client to reach an attacker-controlled or intercepted endpoint, so SSRF-prone, proxy, crawler, and webhook-fetching services are the realistic exposure; impact is denial of service only (C:N/I:N/A:H, no RCE), and no public exploit identified at time of analysis.
Certificate validation bypass in urllib3 1.26.0 through 2.7.x allows a man-in-the-middle attacker who can impersonate the configured HTTPS proxy to intercept, observe, or modify traffic forwarded through that proxy, and in some configurations to obtain the target TLS client certificate. The flaw only affects applications that route requests through an HTTPS proxy while also setting target-server TLS options - proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, or CERT_NONE - because those target settings are incorrectly applied to the proxy TLS handshake; in particular, cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place and the mutation persists across reused connections, silently disabling proxy certificate verification. End-to-end target TLS via CONNECT tunneling remains protected, and no public exploit identified at time of analysis; the issue is fixed in urllib3 2.8.0.
Uncontrolled resource consumption in the Python urllib3 HTTP client library (versions 1.22 through 2.6.2) lets a malicious or compromised server crash or exhaust memory on the client by serving a compressed redirect response. When an application streams from an untrusted source with preload_content=False and has not disabled redirects, urllib3 eagerly drains and decompresses the entire redirect body before any read call, ignoring configured read limits, leaving no defense against decompression bombs. EPSS is low (0.03%), there is no public exploit identified at time of analysis, and it is not in CISA KEV, but the bug is broadly reachable given urllib3's ubiquity.
A malicious or compromised HTTP server can pin the CPU and hang a Python client indefinitely by returning a chunked, deflate-encoded response that carries trailing bytes after the compressed stream, causing urllib3 2.6.2 through 2.7.x to loop without progress. The hang is reachable only on the client streaming path - HTTPResponse.stream() or HTTPResponse.read_chunked() with content decoding enabled (decode_content=True) and a positive finite chunk size (amt=N) - where the Deflate decoder retains the trailing bytes as unconsumed input after end-of-stream and re-decodes them forever; because no further socket read occurs, network read timeouts never interrupt the loop. Impact is availability-only (no confidentiality or integrity effect), unauthenticated from the network per the reported vector (PR:N), and no public exploit identified at time of analysis; exploitation additionally requires the attacker to control or compromise the endpoint the client connects to.
A decompression-bomb denial-of-service flaw in the urllib3 Python HTTP client library (versions 1.0 through 2.5.x, fixed in 2.6.0) lets a malicious or compromised server force a client that uses the streaming API against a compressed HTTP response to fully decompress a small, highly compressed body in a single operation. The result is excessive CPU consumption and massive memory allocation on the client, potentially exhausting resources or crashing the process, even when the application only requested a 256-byte chunk. Exploitation requires the victim application to call stream(), read(amt=...), read1(), read_chunked(), or readinto() with content decoding enabled against an attacker-influenced response; the CVSS vector shows PR:N, so no authentication is required on the target, and no public exploit code or in-the-wild activity has been identified. EPSS is just 0.03% (7th percentile), so despite a vendor CVSS 4.0 score of 8.9, real-world risk is currently low and opportunistic scanning is unlikely.
Resource-exhaustion denial of service in urllib3 1.24 through 2.5.x allows a malicious or attacker-controlled HTTP server to drive a Python client into unbounded CPU usage and memory allocation by returning a Content-Encoding header with an arbitrarily long chain of compression algorithms. The library's MultiDecoder previously split the header on commas and instantiated a decoder per token with no cap, so each attacker-supplied link multiplies the decompression work and the size of the decoded body. Exploitation requires the application to connect to a hostile or compromised endpoint with content decoding enabled (the default), and the assessed CVSS 3.1 vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects that prerequisite and the availability-only impact. There is no public exploit code identified at time of analysis and EPSS is low at 0.03% (8th percentile), but urllib3 is embedded in an enormous number of downstream Python packages and tools, so patch coverage across distributions matters more than the headline exploitation signal. The issue is fixed in urllib3 2.6.0, which caps chained encodings at 5.
urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and prior to 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behavior. This issue has been patched in version 2.5.0.
urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3 is a user-friendly HTTP client library for Python. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
urllib3 is a user-friendly HTTP client library for Python. Rated medium severity (CVSS 4.2). This Exposure of Sensitive Information vulnerability could allow attackers to access sensitive data that should not be disclosed.
urllib3 is a user-friendly HTTP client library for Python. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. This Exposure of Sensitive Information vulnerability could allow attackers to access sensitive data that should not be disclosed.
An issue was discovered in urllib3 before 1.26.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
The urllib3 library 1.26.x before 1.26.4 for Python omits SSL certificate validation in some cases involving HTTPS to HTTPS proxies. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
The _encode_invalid_chars function in util/url.py in the urllib3 library 1.25.2 through 1.25.7 for Python allows a denial of service (CPU consumption) because of an inefficient algorithm. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
The urllib3 library before 1.24.2 for Python mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In the urllib3 library through 1.24.1 for Python, CRLF injection is possible if the attacker controls the request parameter. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Versions 1.17 and 1.18 of the Python urllib3 library suffer from a vulnerability that can cause them, in certain configurations, to not correctly validate TLS certificates. Rated low severity (CVSS 3.7), this vulnerability is remotely exploitable, no authentication required.
Unbounded memory allocation in urllib3 (1.10.3 through 2.7.x) lets a malicious or machine-in-the-middle HTTP server exhaust the memory of a Python client process by streaming an unterminated chunk-size line in a 'Transfer-Encoding: chunked' response. Only clients that consume the response through the streaming path (HTTPResponse.stream() or HTTPResponse.read_chunked()) are affected; the non-streaming .read() path was already bounded to http.client._MAXLINE. Exploitation is unauthenticated (CVSS:4.0 vector PR:N, assessed CVSS:3.1 PR:N) but requires the client to reach an attacker-controlled or intercepted endpoint, so SSRF-prone, proxy, crawler, and webhook-fetching services are the realistic exposure; impact is denial of service only (C:N/I:N/A:H, no RCE), and no public exploit identified at time of analysis.
Certificate validation bypass in urllib3 1.26.0 through 2.7.x allows a man-in-the-middle attacker who can impersonate the configured HTTPS proxy to intercept, observe, or modify traffic forwarded through that proxy, and in some configurations to obtain the target TLS client certificate. The flaw only affects applications that route requests through an HTTPS proxy while also setting target-server TLS options - proxy_ssl_context, proxy_assert_hostname, proxy_assert_fingerprint, ssl_context, cert_reqs, verify_mode, or CERT_NONE - because those target settings are incorrectly applied to the proxy TLS handshake; in particular, cert_reqs=CERT_NONE can overwrite proxy_ssl_context.verify_mode in place and the mutation persists across reused connections, silently disabling proxy certificate verification. End-to-end target TLS via CONNECT tunneling remains protected, and no public exploit identified at time of analysis; the issue is fixed in urllib3 2.8.0.
Uncontrolled resource consumption in the Python urllib3 HTTP client library (versions 1.22 through 2.6.2) lets a malicious or compromised server crash or exhaust memory on the client by serving a compressed redirect response. When an application streams from an untrusted source with preload_content=False and has not disabled redirects, urllib3 eagerly drains and decompresses the entire redirect body before any read call, ignoring configured read limits, leaving no defense against decompression bombs. EPSS is low (0.03%), there is no public exploit identified at time of analysis, and it is not in CISA KEV, but the bug is broadly reachable given urllib3's ubiquity.
A malicious or compromised HTTP server can pin the CPU and hang a Python client indefinitely by returning a chunked, deflate-encoded response that carries trailing bytes after the compressed stream, causing urllib3 2.6.2 through 2.7.x to loop without progress. The hang is reachable only on the client streaming path - HTTPResponse.stream() or HTTPResponse.read_chunked() with content decoding enabled (decode_content=True) and a positive finite chunk size (amt=N) - where the Deflate decoder retains the trailing bytes as unconsumed input after end-of-stream and re-decodes them forever; because no further socket read occurs, network read timeouts never interrupt the loop. Impact is availability-only (no confidentiality or integrity effect), unauthenticated from the network per the reported vector (PR:N), and no public exploit identified at time of analysis; exploitation additionally requires the attacker to control or compromise the endpoint the client connects to.
A decompression-bomb denial-of-service flaw in the urllib3 Python HTTP client library (versions 1.0 through 2.5.x, fixed in 2.6.0) lets a malicious or compromised server force a client that uses the streaming API against a compressed HTTP response to fully decompress a small, highly compressed body in a single operation. The result is excessive CPU consumption and massive memory allocation on the client, potentially exhausting resources or crashing the process, even when the application only requested a 256-byte chunk. Exploitation requires the victim application to call stream(), read(amt=...), read1(), read_chunked(), or readinto() with content decoding enabled against an attacker-influenced response; the CVSS vector shows PR:N, so no authentication is required on the target, and no public exploit code or in-the-wild activity has been identified. EPSS is just 0.03% (7th percentile), so despite a vendor CVSS 4.0 score of 8.9, real-world risk is currently low and opportunistic scanning is unlikely.
Resource-exhaustion denial of service in urllib3 1.24 through 2.5.x allows a malicious or attacker-controlled HTTP server to drive a Python client into unbounded CPU usage and memory allocation by returning a Content-Encoding header with an arbitrarily long chain of compression algorithms. The library's MultiDecoder previously split the header on commas and instantiated a decoder per token with no cap, so each attacker-supplied link multiplies the decompression work and the size of the decoded body. Exploitation requires the application to connect to a hostile or compromised endpoint with content decoding enabled (the default), and the assessed CVSS 3.1 vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) reflects that prerequisite and the availability-only impact. There is no public exploit code identified at time of analysis and EPSS is low at 0.03% (8th percentile), but urllib3 is embedded in an enormous number of downstream Python packages and tools, so patch coverage across distributions matters more than the headline exploitation signal. The issue is fixed in urllib3 2.6.0, which caps chained encodings at 5.
urllib3 is a user-friendly HTTP client library for Python. Starting in version 2.2.0 and prior to 2.5.0, urllib3 does not control redirects in browsers and Node.js. urllib3 supports being used in a Pyodide runtime utilizing the JavaScript Fetch API or falling back on XMLHttpRequest. This means Python libraries can be used to make HTTP requests from a browser or Node.js. Additionally, urllib3 provides a mechanism to control redirects, but the retries and redirect parameters are ignored with Pyodide; the runtime itself determines redirect behavior. This issue has been patched in version 2.5.0.
urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.
urllib3 is a user-friendly HTTP client library for Python. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
urllib3 is a user-friendly HTTP client library for Python. Rated medium severity (CVSS 4.2). This Exposure of Sensitive Information vulnerability could allow attackers to access sensitive data that should not be disclosed.
urllib3 is a user-friendly HTTP client library for Python. Rated high severity (CVSS 8.1), this vulnerability is remotely exploitable, low attack complexity. This Exposure of Sensitive Information vulnerability could allow attackers to access sensitive data that should not be disclosed.
An issue was discovered in urllib3 before 1.26.5. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
The urllib3 library 1.26.x before 1.26.4 for Python omits SSL certificate validation in some cases involving HTTPS to HTTPS proxies. Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR and LF control characters in the first argument of putrequest(). Rated medium severity (CVSS 6.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
The _encode_invalid_chars function in util/url.py in the urllib3 library 1.25.2 through 1.25.7 for Python allows a denial of service (CPU consumption) because of an inefficient algorithm. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Uncontrolled Resource Consumption vulnerability could allow attackers to cause denial of service by exhausting system resources.
The urllib3 library before 1.24.2 for Python mishandles certain cases where the desired set of CA certificates is different from the OS store of CA certificates, which results in SSL connections. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
In the urllib3 library through 1.24.1 for Python, CRLF injection is possible if the attacker controls the request parameter. Rated medium severity (CVSS 6.1), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available and no vendor patch available.
urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Versions 1.17 and 1.18 of the Python urllib3 library suffer from a vulnerability that can cause them, in certain configurations, to not correctly validate TLS certificates. Rated low severity (CVSS 3.7), this vulnerability is remotely exploitable, no authentication required.