CVE-2026-61652: Zapros: Streaming decoders ignored the requested chunk size, allowing a single compressed response chunk to allocate unbounded memory (decompression bomb)
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 (iterbytes(chunksize=...)) 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.iterraw() / Response.asynciterraw(), which bypass the built-in decoders, and decompress it yourself with an explicit output-size bound (e.g. zlib's maxlength), 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Zaprosto a version that resolves this vulnerability.Fixed in 0.14.0 - Configuration
Where feasible, send the header `Accept-Encoding: identity` to disable response compression so response bodies are not decompressed client-side.
HTTP client (Zapros / callers) Accept-Encoding = identity - Compensating control
If streaming compressed responses, avoid the built-in decoders: read the still-compressed body using `Response.iter_raw()` / `Response.async_iter_raw()` and decompress it yourself with an explicit output-size bound (e.g., via `zlib` `max_length`), aborting once the configured limit is exceeded.
Event History
Frequently Asked Questions
Which applications are exposed to this denial-of-service issue?
Applications using Zapros before 0.14.0 are affected if they stream compressed HTTP responses and rely on either an explicit chunk size in iter_bytes(chunk_size=...) or the default chunk size to limit memory use. A malicious or untrusted server can send a compressed response whose decoded chunk exceeds that limit.
What should be done if upgrading to version 0.14.0 is not immediately possible?
Read the compressed response using Response.iter_raw() or Response.async_iter_raw(), then decompress it yourself with an explicit output-size limit and abort when the configured limit is exceeded. Where practical, send Accept-Encoding: identity to prevent client-side response decompression.
Does limiting the requested streaming chunk size mitigate the issue in affected versions?
No. The built-in decoder ignored the requested chunk-size bound, allowing one compressed response chunk to produce an arbitrarily large decoded allocation.
How can exposure be reduced when consuming responses from untrusted servers?
Avoid decoding response bodies from untrusted servers. If such responses must be consumed, bypass the built-in decoders and enforce a decompression output limit, or disable compression with Accept-Encoding: identity where feasible.