CVE-2026-22870: 
Python vulnerability analysis and mitigation

CVE-2026-22870 is a zip bomb (denial of service) vulnerability in DataDog's GuardDog, a CLI tool used to identify malicious PyPI and npm packages. The flaw exists in the safe_extract() function located in guarddog/utils/archives.py, which fails to validate decompressed file sizes when extracting ZIP archives (wheels, eggs), allowing a crafted malicious package to expand from a few megabytes of compressed data into gigabytes of disk usage. All versions prior to 2.7.1 are affected. The vulnerability was discovered on January 4, 2025, reported the same day, and publicly disclosed on January 13, 2026. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 7.1 (High) (Github Advisory, GuardDog Advisory).

The root cause is classified as CWE-409 (Improper Handling of Highly Compressed Data / Data Amplification). While GuardDog's safe_extract() function correctly uses the tarsafe library to impose safety limits on TAR archive extraction, the ZIP file extraction code path lacked equivalent protections — specifically: no decompressed size limit, no compression ratio validation, no file count limits, and no total extracted size validation. The vulnerable code iterated over ZIP entries and extracted them unconditionally via zip.extract(). An attacker exploits this by publishing a specially crafted ZIP-based package (wheel or egg) to PyPI that, when scanned by GuardDog, triggers unbounded decompression and exhausts available disk space (GuardDog Advisory, Patch Commit).

Successful exploitation causes a denial of service by exhausting disk space on the system running GuardDog. In CI/CD environments such as GitHub Actions (which have a standard ~14 GB disk limit), a single malicious package scan can fill the disk and block all subsequent deployments. Beyond pipeline disruption, the attack can exhaust resources on local development machines, security scanning infrastructure, Docker containers, and automated scanning systems. A particularly concerning secondary effect is supply chain attack amplification: by disabling the security scanner itself, an attacker could prevent GuardDog from detecting other malicious packages, forcing manual intervention and increasing security team workload. There is no confidentiality or integrity impact (GuardDog Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.042% (16th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires no privileges and no authentication, but does require passive user interaction — specifically, a user or automated system must trigger a GuardDog scan of the malicious package. No threat actor attribution has been reported.

1. Craft a zip bomb: Create a ZIP archive (e.g., a Python wheel .whl or egg .egg file) that contains highly compressed data with a compression ratio exceeding 100:1, capable of expanding to gigabytes when decompressed.
2. Package as a PyPI distribution: Structure the zip bomb as a valid-looking Python package (e.g., with a setup.py or pyproject.toml) and package it as a .whl or .egg file.
3. Publish to PyPI: Upload the malicious package to PyPI under a plausible package name (e.g., a typosquat of a popular library) to maximize the chance it is scanned.
4. Trigger GuardDog scan: Wait for a victim to run guarddog pypi scan <malicious-package> or include the package in a requirements.txt scanned via guarddog pypi verify. This can also be triggered in automated CI/CD pipelines.
5. Achieve DoS: GuardDog's safe_extract() function extracts the ZIP archive without size validation, causing the decompressed content to fill available disk space, crashing the pipeline or system (GuardDog Advisory).

• File System: Sudden and rapid growth of disk usage in GuardDog's temporary extraction directory (typically a system temp directory); presence of unexpectedly large extracted files from a small downloaded package archive.
• Logs: GuardDog log entries showing extraction of a ZIP archive followed by disk-full errors or process crashes; OS-level disk quota exceeded alerts.
• Process: GuardDog process consuming abnormal amounts of disk I/O during package scanning; system-level alerts for disk space exhaustion (e.g., No space left on device errors in CI/CD logs).
• Network: Download of an unusually small PyPI package (a few MB) that triggers disproportionate disk activity upon scanning (GuardDog Advisory).

Upgrade GuardDog to version 2.7.1 or later, which introduces _check_compression_bomb() validation inside safe_extract() enforcing limits on file count (MAX_FILE_COUNT: 100,000), total uncompressed size (MAX_UNCOMPRESSED_SIZE: 2 GB), and compression ratio (MAX_COMPRESSION_RATIO: 100:1). These limits are configurable via environment variables (GUARDDOG_MAX_UNCOMPRESSED_SIZE, GUARDDOG_MAX_COMPRESSION_RATIO, GUARDDOG_MAX_FILE_COUNT). As an interim workaround for those unable to upgrade immediately, implement disk space monitoring and quotas on systems running GuardDog, and consider restricting automated scanning of untrusted packages (Patch Commit, Github Advisory).

The vulnerability was reported by security researcher Charbel (dwBruijn) and disclosed responsibly with a 30-day suggested disclosure window. The DataDog maintainer team published the advisory and patch promptly on January 13, 2026. Red Hat also tracked the vulnerability under their CVE database. No significant broader media coverage or notable community controversy has been identified beyond standard vulnerability tracking (GuardDog Advisory).