CVE-2026-22871: 
Python vulnerability analysis and mitigation

CVE-2026-22871 is a path traversal vulnerability in GuardDog's safe_extract() function that allows malicious PyPI packages to write arbitrary files outside the intended extraction directory, leading to arbitrary file overwrite and remote code execution (RCE) on systems running GuardDog. GuardDog is a CLI tool developed by Datadog to identify malicious PyPI and npm packages. All versions prior to 2.7.1 are affected (guarddog < 2.7.1 on PyPI). The vulnerability was discovered on January 5, 2026, reported the same day, and publicly disclosed on January 13, 2026. It carries a CVSS v3.1 base score of 9.8 (Critical) and a CVSS v4.0 base score of 8.7 (High) (Github Advisory, Feedly).

The root cause is an incorrect usage of Python's zipfile.ZipFile.extract() API, classified as CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). In guarddog/utils/archives.py, the vulnerable code passes os.path.join(target_directory, file) as the path parameter to zip.extract(). Because extract() automatically appends the member name to the provided path, the filename is appended twice — and when the member name contains path traversal sequences (e.g., ../../), this double-appending breaks zipfile's built-in sanitization, allowing files to be written outside the intended extraction directory. An attacker crafts a malicious Python wheel (.whl) package containing files with path traversal names, uploads it to PyPI or distributes it directly, and triggers exploitation simply by having a GuardDog user scan the package (Github Advisory, Patch Commit).

Successful exploitation allows an attacker to overwrite arbitrary files on the system running GuardDog with the privileges of the GuardDog process. Depending on the execution context, this can lead to immediate code execution (e.g., writing to ~/.bashrc or ~/.profile), persistent backdoors (e.g., writing to ~/.ssh/authorized_keys or /etc/cron.d/), or persistent service execution via systemd user services. If GuardDog is run as root, the impact extends to system-wide file compromise and full host takeover (Github Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been observed as of the time of disclosure (Feedly). The EPSS score is approximately 0.236% (47th percentile), indicating a relatively low but non-negligible probability of exploitation within 30 days (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. The attack requires passive user interaction — a GuardDog user must scan a malicious package — but no authentication or special privileges are required on the attacker's side.

1. Craft a malicious package: Create a Python wheel (.whl) archive containing files with path traversal sequences in their names (e.g., ../../.bashrc or ../../.ssh/authorized_keys), embedding a malicious payload (e.g., a reverse shell command or SSH public key).
2. Distribute the package: Upload the malicious package to PyPI under a plausible or typosquatted package name, or distribute it directly to a target.
3. Trigger GuardDog scan: Wait for or social-engineer a GuardDog user into scanning the malicious package using a command such as guarddog pypi scan malicious-pkg.
4. Path traversal during extraction: When GuardDog processes the ZIP archive in safe_extract(), the vulnerable zip.extract(file, path=os.path.join(target_directory, file)) call causes the filename to be appended twice, bypassing zipfile's sanitization and writing the malicious file to an arbitrary location outside the extraction directory.
5. Achieve code execution: Depending on the written file's location, code execution occurs automatically (e.g., on next shell login via ~/.bashrc) or via a scheduled task, SSH key injection, or systemd service, with the privileges of the GuardDog process (Github Advisory, Patch Commit).

• File System: Unexpected modifications to ~/.bashrc, ~/.profile, ~/.ssh/authorized_keys, /etc/cron.d/, or systemd user service files with timestamps correlating to GuardDog scan activity; new or modified files in locations outside GuardDog's expected temporary extraction directory.
• Logs: GuardDog execution logs showing scans of unknown or suspicious package names; OS-level audit logs (e.g., auditd) recording file writes to sensitive paths by the GuardDog process.
• Process: Unexpected child processes spawned by the GuardDog Python process (e.g., reverse shell connections, curl, wget, bash) following a package scan.
• Network: Outbound connections from the system running GuardDog to unknown external IP addresses or domains shortly after a package scan, potentially indicating a reverse shell or data exfiltration payload was triggered (Github Advisory).

Upgrade GuardDog to version 2.7.1 or later, which fixes the vulnerability by correcting the zip.extract() call to use zip.extract(file, path=target_directory) instead of the vulnerable os.path.join(target_directory, file) path construction (Patch Commit). If immediate patching is not possible, restrict GuardDog's execution environment using appropriate file system permissions and process isolation (e.g., running in a container or sandbox with a read-only filesystem outside the extraction directory) to limit the impact of arbitrary file writes. Avoid scanning untrusted or unknown packages with unpatched versions of GuardDog (Github Advisory).

The vulnerability was reported by security researcher Charbel (dwBruijn) and disclosed via GitHub's security advisory process on January 13, 2026. The advisory notes an ironic detail: a misleading code comment claiming zip.extract() sanitizes path traversal attempts actually obscured the real vulnerability introduced by the incorrect os.path.join() usage. Red Hat also tracked the CVE, and it received coverage in security aggregation outlets such as RedPacket Security's weekly CISA vulnerability summary (Github Advisory, RedPacket Security).