py7zr: Decompression bomb (zip bomb) denial of service via unchecked extraction size
Description
py7zr's Worker.decompress() extracts archive entries without tracking total decompressed size. A crafted .7z file can exhaust disk or memory before the extraction completes.
Measured: 15.6 KB archive → 100 MB output (6,556:1 ratio).
Proof of concept:
import py7zr, tempfile, os
# create bomb: compress 100MB of zeros into ~15KB
bomb_path = tempfile.mktemp(suffix='.7z')
with py7zr.SevenZipFile(bomb_path, 'w') as z:
import io
z.writef(io.BytesIO(b'\x00' * 100 * 1024 * 1024), 'bomb.bin')
print(f'archive size: {os.path.getsize(bomb_path):,} bytes')
# extract — no size check
with py7zr.SevenZipFile(bomb_path, 'r') as z:
z.extractall(path=tempfile.mkdtemp())
print('extracted 100 MB from ~15 KB archive')
Root cause: Worker.decompress() in py7zr/worker.py writes decompressed data directly to disk without a running total or configurable size limit. There is no equivalent of Python's zipfile max_size parameter.
Fix: track cumulative decompressed bytes and raise before writing if a limit is exceeded:
MAX_EXTRACT_SIZE = 2 * 1024 ** 3 # 2 GB default, configurable
total = 0
for chunk in decompressed_chunks:
total += len(chunk)
if total > MAX_EXTRACT_SIZE:
raise py7zr.exceptions.DecompressionBombError(
f'Extraction aborted: decompressed size exceeded {MAX_EXTRACT_SIZE} bytes'
)
outfile.write(chunk)
Tested on py7zr 0.22.0, Python 3.12, Ubuntu 22.04.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Affected products
1Patches
Vulnerability mechanics
Root cause
"Worker.decompress() writes decompressed data to disk without tracking cumulative size or enforcing a configurable limit."
Attack vector
An attacker crafts a small `.7z` archive (e.g., 15.6 KB) that decompresses to a very large payload (e.g., 100 MB), achieving a compression ratio of 6,556:1 [ref_id=1][ref_id=2]. When py7zr extracts the archive via `extractall()` or `extract()`, `Worker.decompress()` writes every decompressed chunk to disk without checking the running total, allowing the attacker to exhaust disk space or memory on the target system. No authentication or special network position is required—the victim only needs to open the malicious archive with py7zr.
Affected code
The vulnerability resides in `Worker.decompress()` within `py7zr/worker.py` (patched in `py7zr/py7zr.py`). The method writes decompressed data directly to disk without tracking the cumulative total, and `SevenZipFile` had no `max_extract_size` parameter to enforce a limit. The patch adds a `max_extract_size` attribute to `Worker`, a `_total_extracted` counter, and a `DecompressionBombError` exception in `py7zr/exceptions.py` [patch_id=6634768].
What the fix does
The patch introduces a `max_extract_size` parameter (default `None`, preserving backward compatibility) to `SevenZipFile` and passes it to `Worker` [patch_id=6634768]. Inside `Worker.decompress()`, a `_total_extracted` counter accumulates the length of each decompressed chunk; if the total exceeds `max_extract_size`, a `DecompressionBombError` is raised before the chunk is written to disk. This mirrors the `max_size` guard found in Python's `zipfile` module and prevents the unbounded disk/memory exhaustion described in the advisory [ref_id=1][ref_id=2].
Preconditions
- inputThe victim must open a crafted .7z archive using py7zr's extract methods.
- authNo authentication or special privileges required; the attacker only needs to deliver the archive.
Generated on Jun 19, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
3News mentions
0No linked articles in our index yet.