CVE-2026-55195: 
Python Analyse et atténuation des vulnérabilités

CVE-2026-55195 is a decompression bomb (zip bomb) denial-of-service vulnerability in the Python library py7zr, affecting all versions up to and including 1.1.2. The flaw resides in Worker.decompress() in py7zr/worker.py, which extracts .7z archive entries without tracking or limiting the total decompressed output size. A crafted archive as small as 15.6 KB can expand to 100 MB or more (a 6,556:1 ratio), exhausting disk space or memory on the target system. The vulnerability was published on June 19, 2026, and is classified as Moderate severity with a CVSS v4 base score of 6.9 (GitHub Advisory, py7zr Release).

The root cause is classified as CWE-409 (Improper Handling of Highly Compressed Data / Data Amplification). The Worker.decompress() function in py7zr/worker.py writes decompressed chunks directly to disk without maintaining a running total of bytes written or enforcing any configurable size limit — unlike Python's built-in zipfile module, which provides a max_size parameter. An attacker supplies a maliciously crafted .7z file; when any code path calls extractall() or equivalent extraction methods, the library decompresses the full content without bounds checking, consuming available disk or memory resources. The attack vector is local (the malicious archive must be processed by the target application), requires no privileges, and no user interaction beyond the application's normal archive-handling behavior (GitHub Advisory, py7zr Security Advisory).

Successful exploitation causes a denial-of-service condition by exhausting disk space or system memory on the host running the vulnerable py7zr version. Applications that automatically process user-supplied or externally sourced .7z archives (e.g., file upload services, CI/CD pipelines, backup tools) are at elevated risk, as a single small malicious archive can render the service unavailable. There is no confidentiality or integrity impact; the vulnerability is limited to availability of the vulnerable system (GitHub Advisory).

1. Craft the bomb archive: Use py7zr itself or any 7-Zip-compatible tool to compress a large file of repetitive data (e.g., 100 MB of null bytes) into a small .7z archive (~15.6 KB), achieving compression ratios exceeding 6,000:1.
2. Deliver the archive: Supply the crafted .7z file to a target application that uses py7zr <= 1.1.2 for extraction — for example, by uploading it to a file-processing service, submitting it via an API endpoint, or placing it in a directory monitored by an automated pipeline.
3. Trigger extraction: Cause the application to call SevenZipFile.extractall() or any equivalent extraction method on the malicious archive. No authentication or special privileges are required beyond the ability to supply the file.
4. Exhaust resources: The Worker.decompress() function writes decompressed data to disk without size checks, rapidly consuming available disk space or memory until the system becomes unresponsive or the process is killed (GitHub Advisory, py7zr Security Advisory).

• File System: Sudden, rapid growth of files in temporary or extraction directories; presence of very large output files (hundreds of MB to GB) originating from a small .7z input archive; disk space exhaustion on volumes used by the py7zr application.
• Process: Python processes consuming abnormally high disk I/O or memory, particularly those associated with py7zr-based applications; processes stalling or being killed due to out-of-memory (OOM) conditions.
• Logs: Application logs showing extraction operations initiated on unexpectedly small .7z files followed by errors related to disk full (OSError: [Errno 28] No space left on device) or memory allocation failures; OOM killer entries in system logs (/var/log/syslog or dmesg) referencing the Python process.

Upgrade py7zr to version 1.1.3 or later, which introduces a cumulative decompressed-size check in Worker.decompress() and adds a configurable max_extract_size constructor parameter (defaulting to 2 GB) that raises a DecompressionBombError if the limit is exceeded (py7zr Release). As a short-term workaround for applications that cannot immediately upgrade, restrict the sources of .7z files accepted for extraction to trusted origins only, and implement OS-level disk quotas or process resource limits (e.g., ulimit -f) to cap the maximum file size writable by the extraction process. OpenSUSE users should apply the distribution-provided package updates as they become available (OpenSUSE Advisory).

The vulnerability was reported by researcher BudongJW and addressed promptly by maintainer miurahr in the same-day v1.1.3 release alongside two other CVEs (CVE-2026-23879 and CVE-2026-55206). OpenSUSE issued security announcements for their package updates shortly after the upstream fix was published (OpenSUSE Advisory). No significant broader media coverage or notable social media discussion has been observed beyond standard advisory distribution.