Which versions of py7zr are affected by CVE-2026-55195?

py7zr, a Python library used in file processing applications across enterprise infrastructure, contains a denial-of-service vulnerability that enables attackers to exploit archive extraction…. A patch is available.

How to fix or mitigate CVE-2026-55195?

Within 24 hours: Identify all applications and systems using py7zr versions 1.1.2 or earlier, prioritizing those that process untrusted or externally-supplied files. Within 7 days: Deploy the latest patched py7zr release (verify exact patched version from py7zr GitHub releases or vendor security advisory) to all affected systems and conduct comprehensive functional testing. Within 30 days: Complete deployment across all development, staging, and production environments and verify patched version compliance via software inventory.

py7zr CVE-2026-55195

Q: What is the CVSS score of CVE-2026-55195?

CVE-2026-55195 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

EUVD-2026-42396 HIGH

Improper Handling of Highly Compressed Data (Data Amplification) (CWE-409)

2026-06-19 https://github.com/miurahr/py7zr

GHSA-gjrg-mpp7-g774

Python Ubuntu Information Disclosure Red Hat

8.7

CVSS 4.0 · Vendor: https://github.com/miurahr/py7zr

Severity by source

Vendor (https://github.com/miurahr/py7zr) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

7.5 HIGH

Attacker-supplied archive extracted by a server-side library needs no auth or privileges (PR:N) at low complexity (AC:L); impact is availability-only (A:H, C/I:N).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

SUSE

MEDIUM

qualitative

Red Hat

6.5 MEDIUM

qualitative

Primary rating from Vendor (https://github.com/miurahr/py7zr).

CVSS VectorVendor: https://github.com/miurahr/py7zr

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Updated

Jul 08, 2026 - 21:34 vuln.today

v3 (cvss_changed)

Analysis Updated

Jul 08, 2026 - 21:32 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 08, 2026 - 21:22 vuln.today

cvss_changed

CVSS changed

Jul 08, 2026 - 21:22 NVD

8.7 (HIGH)

Source Code Evidence Fetched

Jun 19, 2026 - 23:43 vuln.today

Analysis Generated

Jun 19, 2026 - 23:43 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

406 pypi packages depend on py7zr (251 direct, 159 indirect)

Ecosystem-wide dependent count for version 1.1.3.

DescriptionCVE.org

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:

python

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:

python

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.

AnalysisAI

Denial-of-service via decompression bomb in py7zr, the pure-Python 7-Zip library, affects all versions up to and including 1.1.2. The library's Worker.decompress() writes extracted data to disk or memory without tracking cumulative decompressed size, so a tiny crafted .7z (demonstrated at a 6,556:1 ratio - 15.6 KB expanding to 100 MB) can exhaust disk or RAM on any application that extracts untrusted archives. Publicly available exploit code exists (a working PoC is published in the GHSA advisory), but the issue is not listed in CISA KEV; CVSS 4.0 rates it 8.7 (High) with pure availability impact.

Technical ContextAI

py7zr (pkg:pip/py7zr) is a widely-used pure-Python implementation of the 7-Zip (LZMA/LZMA2) archive format, commonly embedded in file-processing pipelines, upload handlers, malware sandboxes, and backup tooling. The root cause is CWE-409 (Improper Handling of Highly Compressed Data, i.e. data amplification / 'zip bomb'): Worker.decompress() in py7zr/worker.py streams decompressed chunks straight to the output file with no running byte counter and no configurable ceiling, unlike Python's standard zipfile which exposes size guards. Because the 7z/LZMA format achieves very high ratios on repetitive input (e.g. runs of zero bytes), an attacker can encode gigabytes of output in a kilobyte-scale archive, and the decompression loop will materialize all of it before extraction returns.

RemediationAI

Vendor-released patch: 1.1.3 - upgrade py7zr to >= 1.1.3 (e.g. pip install --upgrade 'py7zr>=1.1.3'), which adds a max_extract_size constructor parameter that tracks cumulative decompressed bytes and aborts extraction once the limit is exceeded; the 1.1.3 release (https://github.com/miurahr/py7zr/releases/tag/v1.1.3) also bundles fixes for CVE-2026-23879 and CVE-2026-55206, so upgrading is doubly worthwhile. After upgrading, explicitly set max_extract_size to a value appropriate for your workload rather than relying on the default, accepting the trade-off that legitimately large archives will be rejected. If you cannot upgrade immediately, apply compensating controls before extraction: enforce a decompression quota at the OS or container level (run extraction in a cgroup/ulimit-bounded worker or on a disk-quota'd tmpfs so a bomb hits a hard limit instead of exhausting the host), reject archives whose declared uncompressed size or entry count is implausibly large relative to the compressed size, and isolate extraction in a disposable sandbox - noting these controls add operational complexity and may need tuning to avoid false rejections. The corresponding upstream fix commit is https://github.com/miurahr/py7zr/commit/28faf107b64374fa5a02bfb93aa2024e281ca97b.