CVE-2026-61652

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.

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.

Impact

Denial of service via memory exhaustion. 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.

import gzip, zapros

# Server returns ~1 GiB of zeros gzip-compressed to ~1 MiB,
# with header: Content-Encoding: gzip
bomb = gzip.compress(b"\0" * 1_000_000_000)  # ~1 MiB on the wire

with zapros.stream("GET", "https://malicious.example/bomb") as response:
    # Caller asks for 8 KiB chunks, expecting bounded memory:
    for chunk in response.iter_bytes(chunk_size=8192):
        ...  # first `chunk` is ~1 GiB, not 8 KiB -> memory exhaustion

Patches

Upgrade to 0.14.0 or later. The decoders now bound the output of each decompression step to the requested chunk_size: gzip/deflate via zlib's max_length + unconsumed_tail, brotli via output_buffer_limit, and zstd via a bounded stream_writer. Peak memory during streaming decode is now proportional to chunk_size for all supported encodings.

Workarounds

For unpatched versions:

• 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.

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.

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.

Impact

Denial of service via memory exhaustion. 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.

import gzip, zapros

# Server returns ~1 GiB of zeros gzip-compressed to ~1 MiB,
# with header: Content-Encoding: gzip
bomb = gzip.compress(b"\0" * 1_000_000_000)  # ~1 MiB on the wire

with zapros.stream("GET", "https://malicious.example/bomb") as response:
    # Caller asks for 8 KiB chunks, expecting bounded memory:
    for chunk in response.iter_bytes(chunk_size=8192):
        ...  # first `chunk` is ~1 GiB, not 8 KiB -> memory exhaustion

Patches

Upgrade to 0.14.0 or later. The decoders now bound the output of each decompression step to the requested chunk_size: gzip/deflate via zlib's max_length + unconsumed_tail, brotli via output_buffer_limit, and zstd via a bounded stream_writer. Peak memory during streaming decode is now proportional to chunk_size for all supported encodings.

Workarounds

For unpatched versions:

• 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.

Impact

Denial of service via memory exhaustion. 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.

import gzip, zapros

# Server returns ~1 GiB of zeros gzip-compressed to ~1 MiB,
# with header: Content-Encoding: gzip
bomb = gzip.compress(b"\0" * 1_000_000_000)  # ~1 MiB on the wire

with zapros.stream("GET", "https://malicious.example/bomb") as response:
    # Caller asks for 8 KiB chunks, expecting bounded memory:
    for chunk in response.iter_bytes(chunk_size=8192):
        ...  # first `chunk` is ~1 GiB, not 8 KiB -> memory exhaustion

Patches

Upgrade to 0.14.0 or later. The decoders now bound the output of each decompression step to the requested chunk_size: gzip/deflate via zlib's max_length + unconsumed_tail, brotli via output_buffer_limit, and zstd via a bounded stream_writer. Peak memory during streaming decode is now proportional to chunk_size for all supported encodings.

Workarounds

For unpatched versions:

• 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.