CVE-2026-19671 in Malcolm
Summary
by MITRE • 08/18/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 • 08/19/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 logical flaw exists in the conditional logic governing file type handling: 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 lzh (.lz), the system bypasses the decompression limit checks entirely. This discrepancy creates a significant security gap where attackers can exploit the absence of size validation for these specific file types to trigger uncontrolled resource consumption on the host infrastructure.
An authenticated user with permissions to upload PCAP or log files can leverage this flaw by uploading a carefully crafted small compressed file, commonly known as a gzip bomb or zip slip variant adapted for single-stream formats. These maliciously constructed archives are designed to have an extremely high compression ratio, meaning that a few kilobytes of input data decompresses into gigabytes or even terabytes of output data on disk. Because the extraction process does not monitor the expanding size of the uncompressed stream, the system continues writing data until it exhausts available storage space. This attack vector is particularly dangerous because it requires only authentication and standard upload privileges, which are often granted to legitimate users for routine operational tasks such as ingesting network traffic captures or security logs into the platform.
The operational impact of this vulnerability extends beyond a single user's session due to the shared infrastructure architecture typical of modern security information and event management (SIEM) platforms like Malcolm. The decompressed data is written to a Docker volume that is concurrently utilized by critical components including OpenSearch for indexing, Logstash for log processing, Arkime for network packet analysis, and Zeek for protocol analysis. When an attacker triggers the unbounded expansion of disk space through a compressed bomb attack, it rapidly fills the shared storage pool. This leads to immediate service degradation or complete outage for all users on the platform. The inability of OpenSearch and Logstash to write new data results in loss of visibility into network activity, while Zeek and Arkime may crash or fail to process incoming traffic, effectively blinding the security operations center to ongoing threats during the incident window.
From a classification perspective, this vulnerability aligns with CWE-409, which describes Improper Handling of Highly Compressed Data (Data Amplification). The root cause is also consistent with CWE-756, Missing or Incorrect Explanation of Mandatory Features, as the security feature present for one class of inputs was not correctly extended to a logically similar but technically distinct input type. In terms of offensive tactics, this exploitation technique maps directly to MITRE ATT&CK T1496, Resource Hijacking via Crypto Mining or other resource-intensive processes, although in this case the intent is denial of service rather than cryptomining. The attack represents a classic algorithmic complexity vulnerability where the system fails to account for the exponential growth potential inherent in compression algorithms when input constraints are not rigorously enforced across all code paths.
Mitigation strategies must focus on closing the logical gap in the extraction pipeline by applying uniform decompression limits regardless of file format. Developers should implement size checks that monitor the output stream during decomposition, ensuring that any single-stream compressed file is subject to the same maximum uncompressed byte thresholds as multi-entry archives. Additionally, implementing a temporary storage quota for each user session or upload job can provide an additional layer of defense against disk exhaustion. It is also advisable to validate compression ratios and limit the number of decompression iterations if nested streams are possible within single-file formats. Regular security audits should verify that all input validation controls are consistently applied across every supported file type in the ingestion pipeline to prevent similar bypasses for other potential attack vectors such as path traversal or arbitrary file overwrites.