CISA's ICSA-26-230-01 advisory covering Malcolm is particularly interesting because Malcolm is itself a defensive network traffic analysis platform used for network security monitoring, packet analysis and investigation. In other words, the software designed to help defenders observe attackers also needs defending from attackers. The advisory covers six vulnerabilities spanning remote code execution, authorization bypass, path traversal and multiple forms of resource-exhaustion denial of service. The affected versions vary by CVE: Malcolm versions earlier than 26.06.1 are affected by CVE-2026-55676; versions earlier than 26.07.0 are affected by CVE-2026-63133, CVE-2026-63134 and CVE-2026-63177; and versions up to and including 26.07.1 are affected by CVE-2026-19670 and CVE-2026-19671.

CVE-2026-55676: unrestricted file upload leading to remote code execution

CVE-2026-55676 is the most serious vulnerability in the advisory, carrying a CVSS v3.1 score of 8.8. Malcolm's FilePond PHP upload component accepted files through its upload interface, but the file-extension allow-list was empty by default. As a result, the validation effectively permitted any file type. An authenticated user with the ROLE_UPLOAD permission could upload a PHP file, retain the `.php` extension and subsequently request that file through the web server, causing the PHP code to execute as the `www-data` user inside the file-upload container. The vulnerability affects Malcolm versions earlier than 26.06.1.

This is a particularly important example of why upload functionality should never rely only on filename sanitisation or extension checking. An upload feature intended for PCAPs or logs becomes a code-execution mechanism if attacker-controlled content is stored inside a web-accessible executable directory. The security boundary should therefore exist at several levels: strict file-type allow-lists, content validation, randomised storage names, storage outside the web root, disabled script execution within upload directories and appropriate container isolation. Depending on a single upload validation check is effectively asking one configuration mistake to carry the entire security architecture.

The ROLE_UPLOAD requirement reduces the immediate attack surface, but it should not make organisations comfortable. An upload permission is normally interpreted as a relatively limited operational privilege, not permission to execute arbitrary server-side code. The vulnerability therefore represents a serious privilege-boundary failure. In environments where several analysts, partners or teams have access to Malcolm, compromise of one low-privilege upload account could potentially provide code execution inside the platform.

CVE-2026-63133: archive extraction resource exhaustion and denial of service

CVE-2026-63133, rated CVSS 6.5, affects Malcolm versions prior to 26.07.0 and involves uncontrolled resource consumption during archive extraction. Malcolm's `safe-extract.py` could process uploaded archives without imposing sufficient limits on the number of entries, directory depth or overall extraction size. A relatively small malicious archive containing enormous numbers of directories or files could therefore force the Filebeat processing container to create large numbers of filesystem objects until available inodes or filesystem metadata were exhausted. This could disrupt Malcolm's processing pipeline and potentially other services sharing the same storage.

This vulnerability demonstrates an aspect of denial-of-service attacks that is sometimes overlooked. Disk capacity is not the only finite filesystem resource. A system can have gigabytes or even terabytes of free disk space and still become unusable if its available inodes are exhausted. An attacker therefore does not necessarily need to upload a massive file. A carefully constructed archive containing huge numbers of very small entries can exhaust filesystem metadata far more efficiently.

In an ICS monitoring environment, availability of security infrastructure is itself important. If Malcolm is being used to analyse network traffic from industrial networks, disrupting that analysis platform creates a monitoring blind spot. An attacker may therefore gain value from attacking the visibility layer even if the vulnerability provides no direct access to the industrial control system. Security monitoring infrastructure should consequently be considered part of the critical defensive architecture rather than an auxiliary IT service.

Malcolm addressed this weakness by introducing limits on archive entry count, nesting depth and expanded size. The project documentation lists defaults of 5,000 entries, 20 directory levels and 4 GiB of expanded data. This is a useful defensive principle for any service processing attacker-controlled archives: validation should consider what a file becomes after processing, rather than judging risk merely by the size of the compressed object received over the network.

CVE-2026-63134: path traversal during archive extraction

CVE-2026-63134 carries a CVSS score of 5.4 and affects Malcolm versions prior to 26.07.0. The vulnerability exists in the same archive-processing area but has a very different impact. Although Malcolm used libarchive security flags while extracting file content, directory creation was performed using a path derived from the archive entry without sufficient containment validation. A malicious archive containing `../` traversal sequences or an absolute directory path could therefore cause Malcolm to create directories outside the intended extraction location.

The interesting lesson here is that secure extraction must protect every filesystem operation, not merely extraction of ordinary files. Developers may carefully validate file writes while assuming directory creation is harmless. Path traversal turns that assumption against them. If an attacker can influence where directories are created, the application is already crossing an important filesystem security boundary and may create conditions that can be combined with other weaknesses.

The direct impact of CVE-2026-63134 is more limited than the remote-code-execution flaw, hence its lower severity rating, but it remains significant when considered alongside the other vulnerabilities. Security teams should avoid analysing CVEs purely as isolated entries in a vulnerability scanner. Attackers frequently combine weaknesses. A directory traversal flaw, authorization bypass and upload vulnerability may create attack possibilities that are substantially more serious than any individual CVSS score suggests.

The fix introduced in Malcolm 26.07.0 validates resolved paths and uses secure libarchive extraction controls so that extracted content remains within its intended destination.

CVE-2026-63177: authorization bypass through URI normalization differences

CVE-2026-63177 is a high-severity authorization vulnerability rated CVSS 7.1 and affects versions before 26.07.0. Malcolm's role-based access control is enforced in an Nginx OpenResty Lua layer. The problem was that this security layer evaluated the raw request URI while Nginx performed routing using a normalized version of the path. An authenticated low-privilege user could craft a request containing path traversal-style components so that the authorization layer evaluated one logical path while Nginx ultimately routed the request to another, restricted backend.

This type of vulnerability is particularly instructive because neither component is necessarily making an obviously unsafe decision when considered independently. The weakness appears because two layers interpret the same request differently. The authorization mechanism believes it is approving access to one resource while the routing layer sends the request somewhere else. Security controls positioned in proxies, gateways and application middleware therefore need to make authorization decisions using exactly the same canonical representation of a request that the downstream application will process.

The issue also demonstrates why path normalization is a security function rather than merely a URL-processing detail. Encoded paths, traversal components, repeated separators and other URI variations can produce dangerous inconsistencies whenever a reverse proxy, WAF, authorization layer and application server canonicalise requests differently.

CVE-2026-63177 becomes even more interesting when considered beside CVE-2026-55676. The upload RCE required an authenticated user with ROLE_UPLOAD privileges, while the URI normalization flaw could allow a lower-privilege authenticated user to reach functionality that should have been protected by role controls. Whether a particular deployment permits a complete exploit chain depends on configuration and reachable endpoints, but defenders should always evaluate vulnerabilities collectively rather than assuming that each attacker's prerequisite remains neatly isolated from every other flaw. CISA's vulnerability data indicates no known active exploitation for CVE-2026-63177 at the time of assessment.

CVE-2026-19670: incorrect authorization in Malcolm's RBAC layer

CVE-2026-19670 is another authorization vulnerability in Malcolm's Nginx Lua role-based access-control implementation. CISA describes the issue as incorrect authorization affecting the logic that determines whether an authenticated user is permitted to reach role-restricted resources. The vulnerability affects Malcolm versions up to and including 26.07.1 and has been assigned a CVSS score of 5.4.

While CVE-2026-63177 concerns disagreement between URI normalization in Nginx and the Lua authorization layer, CVE-2026-19670 further demonstrates how fragile security can become when access control depends on request parsing and application routing behaving identically. Authentication answers the question "Who is this user?" Authorization answers the much more difficult question "What exactly should this user be allowed to reach?" A flaw in the second question can make perfectly functioning authentication largely irrelevant.

For environments using differentiated Malcolm roles, this deserves particular attention. Security monitoring platforms often contain captured packet data, session metadata, credentials accidentally transmitted across networks, internal addresses, asset information and details of operational protocols. Consequently, improper authorization inside a monitoring platform can expose information that is extremely useful for reconnaissance. An attacker gaining visibility into the defensive monitoring system may effectively receive a map of the network the organisation is attempting to protect.

CVE-2026-19671: compressed-data amplification and disk exhaustion

CVE-2026-19671 is another resource-exhaustion vulnerability, rated CVSS 6.5, but it is subtly different from CVE-2026-63133. Malcolm had introduced limits when extracting container archives such as ZIP, TAR, RAR and 7-Zip files. However, those protections were not applied in the same way when handling single-stream compression formats such as `.gz`, `.bz2`, `.xz`, `.lzma` and `.lz` when they were not part of a `.tar.*` archive. An authenticated user permitted to upload PCAP or log files could therefore provide a very small, highly compressible object that expanded to an extremely large size after decompression.

This is essentially the classic decompression-bomb problem appearing inside a modern network-analysis workflow. The malicious file can be tiny while compressed, meaning upload-size restrictions provide little protection. The actual resource consumption occurs later when the application processes it. According to the vulnerability description, decompression can exhaust the shared Docker volume used by components including OpenSearch, Logstash, Arkime and Zeek, potentially disrupting Malcolm for all users.

The distinction between CVE-2026-63133 and CVE-2026-19671 is useful. CVE-2026-63133 can exhaust resources by creating huge numbers of filesystem objects, while CVE-2026-19671 attacks storage capacity through extreme decompression expansion. Both show that applications accepting archives or compressed telemetry must enforce limits after decompression, not simply at upload time. Entry limits, nesting limits, expanded-size limits, compression-ratio thresholds, filesystem quotas and isolated processing volumes should all be considered when handling untrusted compressed data.

There is a broader point worth making about the entire advisory. Malcolm occupies a highly trusted position because it is built specifically to collect and inspect network traffic. That can include PCAP files, Zeek logs and telemetry from sensitive network segments. A compromise of the monitoring platform can therefore be disproportionately valuable. An attacker could potentially gain insight into internal addressing, protocols, assets, communication patterns and defensive monitoring practices. Security products do not become inherently trustworthy simply because their purpose is security. Sometimes they are more attractive targets precisely because organisations grant them exceptional access and visibility.

The vulnerabilities also highlight the danger created by complex processing pipelines. Malcolm combines web interfaces, Nginx/OpenResty authorization, file upload functionality, archive extraction, Filebeat, Logstash, Zeek, Arkime, OpenSearch and container infrastructure. Every transition between those components creates a trust boundary. One component validates a URL, another routes it. One accepts an archive, another extracts it. One checks a role, another exposes the backend resource. Attackers spend a remarkable amount of time studying precisely those boundaries because that is where assumptions made by one component frequently stop matching assumptions made by another.

From an ICS perspective, this matters even more because network monitoring tools are often deliberately positioned where they can observe highly sensitive operational traffic. Organisations should therefore segment Malcolm itself, restrict administrative and upload access, avoid exposing the management interface directly to untrusted networks, apply multi-factor authentication where possible, limit roles according to operational necessity and isolate processing containers and storage. Logs from the Malcolm platform should ideally also be exported to an independent monitoring location, because asking a compromised monitoring system to provide trustworthy evidence of its own compromise is an architectural optimism attackers are happy to exploit.

Administrators also need to pay careful attention to versioning because the six CVEs do not share the same affected range. Upgrading an old installation only to 26.06.1 resolves CVE-2026-55676 but does not address the vulnerabilities fixed in 26.07.0. Likewise, CISA states that CVE-2026-19670 and CVE-2026-19671 affect versions up to and including 26.07.1, so organisations should verify CISA's and the Malcolm project's latest remediation guidance rather than assuming that 26.07.1 addresses every vulnerability listed in the August 18 advisory.

Perhaps the most important takeaway from ICSA-26-230-01 is that cybersecurity infrastructure itself must be treated as critical infrastructure. SIEM platforms, packet-analysis systems, log collectors, network sensors, forensic platforms and security-management consoles frequently possess broader visibility than ordinary production applications. If attackers compromise the defensive layer, they may gain both access and an understanding of how the defender sees the network.

The Malcolm vulnerabilities therefore reinforce a principle that applies far beyond this particular platform: security controls should never be assumed trustworthy merely because they are security products. Their access-control logic, file-processing pipelines, APIs, storage, network exposure and internal privileges need the same continuous scrutiny applied to the systems they are supposed to protect. A monitoring system that can see everything can also become an extremely informative place for an attacker to stand.

View CSAF Summary Successful exploitation of these vulnerabilities could allow an attacker to cause a denial-of-service condition or execute arbitrary code. The following versions of CISA Malcolm are affected: Malcolm <26.06.1 (CVE-2026-55676) Malcolm <26.07.0 (CVE-2026-63133, CVE-2026-63134, CVE-2026-63177) Malcolm <=26.07.1 (CVE-2026-19670, CVE-2026-19671) CVSS Vendor Equipment Vulnerabilities v3 8.8 CISA CISA Malcolm Allocation of Resources Without Limits or Throttling, Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal'), Unrestricted Upload of File with Dangerous Type, Incorrect Authorization, Improper Handling of Highly Compressed Data (Data Amplification) Background Critical Infrastructure Sectors: Information Technology Countries/Areas Deployed: Worldwide Company Headquarters Location: United States Vulnerabilities Expand All + CVE-2026-63133 Malcolm is a network traffic analysis tool suite. Prior to version 26.07.0, safe-extract.py extracts uploaded archives with no limit on entry count, directory depth, total entries, or output size. A small malicious archive containing a large number of directory or file entries causes the filebeat processing container to create an unbounded number of filesystem objects, exhausting inodes or filesystem metadata and denying service to the processing pipeline and any service sharing the same mount. Version 26.07.0 fixes the issue. View CVE Details Affected Products CISA Malcolm Vendor: CISA Product Version:

Source: CISA Malcolm via CISA Advisories — published 18 Aug 2026.