CVE-2026-61652 in Zapros
Summary
by MITRE • 09/22/2026
Zapros, a Python HTTP client, prior to version 0.14.0 is vulnerable to denial of service via memory exhaustion. The issue affects all callers who streamed compressed responses relying on the chunk size — explicit (`iter_bytes(chunk_size=...)`) or the default — to bound memory. The decoder ignored that bound, so a chunk could be far larger than requested and a single compressed response could overflow memory. Version 0.14.0 contains a patch. Some workarounds are available. Read the still-compressed body with `Response.iter_raw()` / `Response.async_iter_raw()`, which bypass the built-in decoders, and decompress it yourself with an explicit output-size bound (e.g. `zlib`'s `max_length`), aborting once a configured limit is exceeded. Where feasible, send `Accept-Encoding: identity` to disable response compression so bodies are not decompressed client-side. Avoid decoding response bodies from untrusted servers.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Zapros versions prior to 0.14.0 represents a critical denial of service flaw rooted in improper memory management during the handling of compressed HTTP responses. This issue specifically impacts applications that utilize streaming mechanisms, whether through explicit chunking via parameters like iter_bytes with a defined chunk size or by relying on default buffering behaviors. The core technical failure lies within the response decoder logic, which fails to respect the configured bounds for data processing. When a server returns a compressed payload, the decompression process can generate output buffers that significantly exceed the requested chunk limits. This discrepancy allows an attacker to craft responses with high compression ratios or specific structural properties that cause the memory allocator to consume excessive resources, ultimately leading to system instability or crash due to memory exhaustion.
From a technical perspective, this flaw aligns closely with CWE-400, which describes conditions where uncontrolled resource consumption occurs within a software product. The vulnerability is exacerbated by the asynchronous nature of many modern HTTP clients, where such memory leaks can accumulate rapidly across multiple concurrent connections. In an operational context, this weakness enables remote attackers to trigger service disruptions without requiring authentication or complex exploitation techniques beyond sending specific compressed payloads. This falls under the MITRE ATT&CK framework category of Resource Hijacking, specifically within the sub-technique for Denial of Service via resource exhaustion. The impact is severe for services that process untrusted content, as a single malicious response can degrade performance for all users sharing the same server resources or cause complete service outages if memory limits are reached.
Mitigation strategies focus on either upgrading to patched versions or implementing defensive coding practices in legacy systems. The primary remediation is to upgrade Zapros to version 0.14.0 or later, where the decoder logic has been corrected to strictly enforce chunk size boundaries during decompression. For environments unable to immediately patch, developers can adopt workarounds that bypass the vulnerable built-in decoders entirely. By using Response.iter_raw() or its asynchronous counterpart async_iter_raw(), applications receive the raw compressed bytes without automatic decomposition. This approach shifts the responsibility of decompression to the application layer, allowing for precise control over memory usage through libraries like zlib with explicit max_length parameters. Additionally, sending Accept-Encoding: identity headers can prevent servers from returning compressed responses altogether, thereby eliminating the risk at the protocol level. It is also advisable to avoid decoding response bodies from untrusted sources unless strict size limits and validation are enforced throughout the processing pipeline.