CISA’s August 18 advisory covers a mix of arbitrary-code-execution, authorization, path-traversal, dangerous-upload, and resource-exhaustion risks in Malcolm, an open-source suite used to analyze full packet captures, Zeek logs, and Suricata alerts. The advisory says no public exploitation specifically targeting these flaws had been reported to CISA at publication time. Still, Malcolm installations commonly ingest untrusted captures and log archives—the exact kind of workflow that makes input-handling defects more than a theoretical concern.
The project’s GitHub release records independently confirm that Malcolm v26.06.1 fixed the unrestricted PHP-upload issue and that v26.07.0 added fixes for the archive-extraction and authorization issues. But CISA’s newer advisory draws a clear line between those earlier fixes and two remaining findings affecting v26.07.1 and earlier. That leaves operators with a patch-status gap, not simply an overdue-update problem.
The six CVEs do not share one fix level
CISA divides the affected releases into three groups:
- Malcolm versions earlier than 26.06.1 are affected by CVE-2026-55676.
- Malcolm versions earlier than 26.07.0 are affected by CVE-2026-63133, CVE-2026-63134, and CVE-2026-63177.
- Malcolm versions up to and including 26.07.1 are affected by CVE-2026-19670 and CVE-2026-19671.
The first issue, CVE-2026-55676, is the most immediately consequential flaw with a published technical description. The CVE record and Malcolm’s v26.06.1 release notes describe an unrestricted .php upload in the file-upload component that could allow an authenticated user with the applicable upload permission to execute code as the web-service account. Security researcher Jan Kahmen’s TuringPoint advisory likewise characterizes it as authenticated remote code execution caused by an empty upload allow-list.
Malcolm v26.06.1, released on June 16, fixed that defect. Yet its release notes also carried an upgrade warning: the project said PostgreSQL databases used by NetBox and Keycloak could be incompatible when upgrading from prior Malcolm versions, recommending that users back up NetBox and avoid the release if they used Keycloak authentication until the issue was investigated. That history is worth remembering now. A security update can be necessary without being operationally frictionless, particularly on an appliance-like monitoring stack with stateful services.
v26.07.0 addressed archive extraction and RBAC bypasses
The next three CVEs were remediated in Malcolm v26.07.0, according to the project’s v26.07.1 release notes, which summarize the security changes introduced in the earlier release.
CVE-2026-63133 concerns unbounded archive extraction. Malcolm’s fix added limits on archive entry count, nesting depth, and expanded size, protecting the extraction path against inode and resource exhaustion. The current configuration defaults documented in the release are 5,000 entries, 20 directory levels, and 4 GiB of expanded data. Those values are practical controls, not merely code cleanup: archive uploads containing logs are a normal Malcolm ingestion path, and a compressed archive can expand into enough files or data to disrupt the container or host storage beneath it.
CVE-2026-63134 is a path-traversal flaw in archive extraction directory handling. Malcolm says it corrected the issue by validating resolved paths and enabling libarchive secure-extraction flags. This is the kind of bug that deserves attention even where uploads are limited to trusted analysts; path traversal changes the security boundary from “process a submitted archive” to “potentially write outside the intended extraction area.”
CVE-2026-63177 is an authorization bypass stemming from differences in how Nginx matches and normalizes a URI versus how Malcolm’s Lua authorization layer handles it. Malcolm’s release notes call it an RBAC bypass, while the CVE record describes unauthorized access to restricted back-end services through URI-normalization differences. For organizations that use Malcolm role-based access control to separate analysts, administrators, and upload-capable users, that is a direct challenge to an assumed boundary.
The practical remediation threshold for these three issues is straightforward: installations below v26.07.0 should be moved beyond that version after the usual backup and compatibility review. Malcolm v26.07.1 contains those fixes and also updates several bundled components, including Zeek, Arkime, Filebeat, Logstash, Keycloak, and Alpine base images.
The unresolved v26.07.1 problem
CISA’s advisory is more troubling at the newest version boundary. It says CVE-2026-19670 and CVE-2026-19671 affect Malcolm through v26.07.1, while the project’s GitHub repository identifies v26.07.1, released July 22, as the latest public release.
Neither CISA’s supplied advisory text nor the current v26.07.1 release notes identify a later fixed release, a commit to apply, a configuration mitigation specific to the two CVEs, or a way to distinguish vulnerable deployments beyond the version range. CISA associates the advisory with resource-limit, path-traversal, dangerous-upload, authorization, and decompression-amplification weakness classes, but the advisory does not map each weakness class to an individual CVE. Administrators should not guess which exposed feature corresponds to either remaining issue.
That omission changes the immediate response. Updating old Malcolm deployments remains necessary, but organizations on v26.07.1 should treat the two newest CVEs as unresolved at the release level until CISA or the Malcolm maintainers publish a fixed version or a documented workaround. “Current” is not synonymous with “clear” in this case.
What Malcolm administrators should do now
Begin by establishing the exact running version rather than relying on when the host was last patched. Malcolm’s own release notes advise existing installations to run ./scripts/status so its control scripts can migrate relevant settings before ./scripts/configure or ./scripts/start. Preserve that operational step during remediation; container-image updates without their configuration migration are not a dependable upgrade plan.
Then separate the response into two tracks:
- Systems below v26.06.1 should be prioritized because of the authenticated PHP upload leading to potential code execution.
- Systems below v26.07.0 should be upgraded to pick up the archive-extraction and RBAC fixes, while validating archive-ingestion workflows and authentication controls afterward.
- Systems already on v26.07.1 should reduce exposure while waiting for a defined remediation for CVE-2026-19670 and CVE-2026-19671. Restrict management and upload interfaces to required users and networks, review accounts with upload permissions, and avoid placing Malcolm’s web-facing services directly on the public internet.
CISA’s standard guidance to isolate operational technology and monitoring systems behind firewalls is particularly relevant here, though Malcolm is not itself an industrial controller. A network-monitoring system often has access to sensitive telemetry, credentials, packet captures, dashboards, and administrative integrations. Compromise of that system can become a route to reconnaissance or credential theft even if it never sends a command to an operational device.
For Windows administrators who run Malcolm alongside Windows collectors or manage it from Windows through Docker, PowerShell, or remote browser access, the key point is the same: patching the host OS does not change the Malcolm application version or correct its containerized services. Inventory the Malcolm deployment separately, including its exposed reverse proxy, identity provider, upload workflow, and persistent NetBox or Keycloak data.
CISA has confirmed that no public exploitation was known on August 18. The more immediate concern is that the advisory names two CVEs affecting the latest Malcolm release without identifying a newer safe release. Until that changes, v26.07.1 should be regarded as the best available baseline for the earlier four issues—not as a complete resolution of the advisory.
