CISA's own traffic-analysis suite carries six CVEs, including an archive bomb that starves shared mounts

CISA has published an advisory covering six CVEs in Malcolm, the network traffic analysis tool suite it ships itself, warning that successful exploitation could cause a denial-of-service condition or allow arbitrary code execution ^{[2] [3] [15] [4]}. The suite is deployed worldwide and categorised under the Information Technology critical infrastructure sector, which is to say the affected installs are mostly other people's monitoring stacks ^[5].

The most consequential item for anyone running Malcolm on shared storage is the extraction logic. Before version 26.07.0, `safe-extract.py` unpacked uploaded archives with no limit on entry count, directory depth, total entries, or output size ^[6]. A small malicious archive stuffed with directory or file entries makes the filebeat processing container create an unbounded number of filesystem objects, exhausting inodes or filesystem metadata and denying service not only to the processing pipeline but to any service sharing the same mount ^[7]. CISA classifies it as CWE-770, allocation of resources without limits or throttling ^[8]. The blast radius is the interesting part: the collateral is whatever else you colocated on that volume.

The same script had a second problem. File extraction was protected by libarchive's secure flags, but directory entries were created with a raw `os.makedirs(os.path.join(dest, entry.pathname))` and no traversal protection, so an archive containing a `../` sequence or an absolute path in a directory entry creates directories outside the intended extraction target ^[9].

The code execution path runs through the file-upload component. Its FilePond PHP backend accepts uploads at `POST /server/php/submit.php` and stores them in a directory served by the same nginx and php-fpm instance ^[10]. The allow-list meant to restrict file types is an empty array by default, making the type check a no-op that accepts every extension, and the filename sanitizer leaves `.php` intact ^[11]. Committed files land under `/var/www/upload/server/php/files`, the component's nginx routes any URL ending in `.php` to php-fpm, and an authenticated GET then runs the uploaded code as `www-data` ^[12]. Before 26.06.1, in RBAC mode, that endpoint was reachable by the granular `ROLE_UPLOAD` role, intended only for submitting capture files, so a user holding upload-only rights got arbitrary PHP execution inside the file-upload container ^[13].

RBAC itself fell open elsewhere. The role checks enforced in the nginx OpenResty Lua layer evaluated the raw, unnormalized `ngx.var.request_uri` while nginx routed on the normalized path, so an authenticated low-privilege user could prepend a traversal segment such as `/x/../upload/...` and have nginx deliver the request to a restricted backend while the Lua rule matched nothing and allowed it ^[1].

Version 26.06.1 fixes the upload flaw and 26.07.0 fixes the extraction and RBAC issues, with CISA pointing to pull requests 1026 and 1043 respectively ^[14]. Two of the six, CVE-2026-19670 and CVE-2026-19671, are listed as affecting versions up to and including 26.07.1, and the advisory material supplied contains no description of them and no named fixed version ^[16].

Watch for a release above 26.07.1 and for detail on those two open CVEs; until then, the honest read is that the current version is still listed as affected. Operators should also check whether their Malcolm mount is shared with anything they would miss.