CVE-2026-107335: Improper Handling of Highly Compressed Data in Malcolm
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Malcolmto a version that resolves this vulnerability.Fixed in v26.08.0
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The attacker must be an authenticated user who is permitted to upload PCAP or log files. No user interaction is required.
Which compressed uploads bypass the extraction limits?
Single-stream compressed files such as .gz, .bz2, .xz, .lzma, and .lz are not subject to the entry-count, nesting-depth, and total-uncompressed-byte limits. Container archives handled through libarchive, including zip, tar, rar, and 7z, do have those limits applied.
What is the likely operational impact of a successful upload?
A small highly compressible upload can expand to an effectively unbounded size and exhaust the shared Docker volume. This can disrupt OpenSearch, Logstash, Arkime, and Zeek for all platform users.