CVE-2026-107335 in Malcolm
Summary
by MITRE • 10/08/2026
Malcolm's upload-processing pipeline (scripts/safe-extract.py) enforces entry-count, nesting-depth, and total-uncompressed-byte limits when extracting container archives (zip/tar/rar/7z via libarchive), but those limits are not applied when the uploaded file is a single-stream compressed format (.gz, .bz2, .xz, .lzma, .lz) that isn't a .tar.*-style archive. Any authenticated user permitted to upload PCAP/log files can upload a small, highly compressible file (e.g. a gzip bomb) that decompresses to an effectively unbounded size on disk, exhausting the shared Docker volume used by OpenSearch, Logstash, Arkime, and Zeek, and disrupting the platform for all users.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability resides in Malcolm's upload-processing pipeline, specifically within the safe-extract.py script which is responsible for handling incoming container archives such as zip, tar, rar, and 7z files via libarchive. This component implements robust security controls by enforcing strict limits on entry count, nesting depth, and total uncompressed byte size to prevent resource exhaustion attacks during extraction. However, a critical logic flaw exists in the conditional branching of this script: these protective measures are exclusively applied when processing multi-entry archive formats that resemble tar-style containers. When an uploaded file is identified as a single-stream compressed format, including gzip (.gz), bzip2 (.bz2), xz (.xz), lzma (.lzma), or lzip (.lz), the extraction logic bypasses these limits entirely. This discrepancy creates a significant security gap where attackers can exploit the lack of decompression size validation to perform resource exhaustion attacks against the underlying infrastructure.
An authenticated user with permissions to upload PCAP or log files can leverage this flaw by uploading a small, highly compressible file designed as a compression bomb. By carefully crafting such an input, typically using gzip formats due their widespread compatibility and ease of generation, an attacker can create a payload that is only a few kilobytes in size but decompresses into gigabytes or even terabytes of data on disk. Because the safe-extract.py script does not apply any byte-size limits to these single-stream files, the system will proceed with full decompression without interruption. This results in the rapid consumption of available storage space on the shared Docker volume that hosts critical components including OpenSearch, Logstash, Arkime, and Zeek. The sudden spike in disk usage can lead to immediate service degradation or complete failure for all users sharing this environment, effectively causing a denial of service condition without requiring any privilege escalation beyond basic upload permissions.
From an industry standards perspective, this vulnerability is classified under CWE-409, which describes the exploitation of highly compressible data to cause excessive resource consumption, commonly known as a decompression bomb or zip-bomb attack. The operational impact aligns with MITRE ATT&CK technique T1496, Resource Hijacking, specifically through environmental hijacking where an attacker consumes shared resources to disrupt service availability for other tenants or users in the same environment. In multi-tenant SaaS platforms like Malcolm, which rely on centralized logging and network analysis tools sharing a common storage backend, such resource exhaustion can have cascading effects beyond just disk space depletion, potentially leading to database corruption if write operations fail due to lack of space, or causing critical security monitoring gaps as services crash unexpectedly.
To mitigate this vulnerability, the safe-extract.py script must be updated to enforce consistent decompression limits across all supported file formats, not just multi-entry archives. This involves implementing a hard cap on the maximum number of bytes that can be written during the extraction process for single-stream compressed files such as .gz, .bz2, and others. Additionally, input validation should include checks for compression ratios to detect potential bombs before full decompression begins where feasible. The system should also implement disk space monitoring with automated alerts or automatic termination mechanisms if usage exceeds a safe threshold relative to the allocated volume size. Furthermore, applying principle of least privilege by restricting upload permissions to only those users who absolutely require it and implementing rate limiting on file uploads can reduce the attack surface. Regular security audits of the extraction pipeline are recommended to ensure that future updates do not reintroduce similar inconsistencies in limit enforcement across different archive types.