Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
PackInfo.read() uses an O(n^2) cumulative sum pattern where numstreams is read directly from the archive header. A crafted .7z archive with a large numstreams value causes excessive CPU consumption during SevenZipFile.init() — no extraction is needed. A 50 KB archive takes ~7 seconds of CPU time. Details The vulnerable code is in PackInfo.read() (archiveinfo.py): self.packpositions = [sum(self.packsizes[:i]) for i in range(self.numstreams + 1)] numstreams is parsed from the archive header via readuint64() and is attacker-controlled. Each sum(self.packsizes[:i]) re-sums from the beginning, producing O(n^2) total work. This runs during header parsing in SevenZipFile.init(), before any extraction. Suggested fix — replace with O(n) cumulative sum: from itertools import accumulate self.packpositions = [0] + list(accumulate(self.packsizes)) PoC Tested on py7zr 1.1.0, Python 3.12.3, Linux x8664. Results: n= 1000 size= 1042 bytes time=0.004s n= 5000 size= 5042 bytes time=0.071s n=…
Recommended action: Upgrade to 1.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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 maxsize parameter. Fix: track cumulative decompressed bytes and raise before writing if a limit is exceeded: Tested on py7zr 0.22.0, Python 3.12, Ubuntu 22.04.
Recommended action: Upgrade to 1.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There exists an arbitrary file write vulnerability in py7zr (1.1.0, latest), which allows symbolic links to be recreated outside the destination directory via crafted malicious symbolic link chains. When using extractall to extract an archive, the library restores these symbolic links, linking them to arbitrary directories on the host file system. Subsequent extraction of regular files through these symbolic links can result in arbitrary file writes. This vulnerability may lead to remote code execution, privilege escalation, data corruption, or denial of service. Details The root cause of this vulnerability is that py7zr fails to properly restrict the targets of symbolic links within an archive. During extraction, the program only checks the link arcname within the destination directory, but ignores the combined symlink path resolution. Attackers can exploit this vulnerability by constructing malicious archives, thereby bypassing the directory boundary restrictions…
Recommended action: Upgrade to 1.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A directory traversal vulnerability in the SevenZipFile.extractall() function of the python library py7zr v0.20.0 and earlier allows attackers to write arbitrary files via extracting a crafted 7z file.
Recommended action: Upgrade to 0.20.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.