CISA Malcolm Security Alert: Seven CVEs Put ICS Network Monitoring at Risk—Upgrade to v26.09.0

Developed by CISA in collaboration with Idaho National Laboratory (INL), Malcolm is a container-based telemetry powerhouse used across Information Technology, Energy, and Water and Wastewater Systems sectors worldwide. It ingests full packet capture (PCAP) artifacts, Zeek logs, and Suricata alerts, presenting them through OpenSearch Dashboards and Arkime so defenders can hunt threats and conduct forensic investigations. Because security operations centers (SOCs), incident-response workstations, and operational technology (OT) defenders rely on Malcolm to inspect sensitive network traffic, flaws in the platform itself carry high operational stakes.

Every vulnerability listed in advisory ICSA-26-280-01 was reported by Seth Grover of Idaho National Laboratory—who also serves as a lead developer maintaining the project on GitHub—and patched in Malcolm v26.08.0, released on August 25, 2026. Notably, the project's subsequent v26.09.0 release on September 30, 2026, remediated three additional security issues in related components, making a move to the latest stable build the smartest path for defenders.

The Anatomy of the Flaws: Seven CVEs Across the Malcolm Stack​

While the top-level summary table in CISA's advisory header contains a minor formatting quirk that says "5 Vulnerabilities," the body of ICSA-26-280-01 explicitly catalogs seven distinct CVEs. (This discrepancy stems from how the upstream v26.08.0 release notes grouped the fixes into five overarching remediation bullet points.) Similarly, CISA's summary header shows a dangling Malcolm <=v26.08.0 () line with no CVEs attached, while every individual CVE record in the advisory specifies CISA Malcolm <=v26.07.1 as the affected product status and v26.08.0 as the vendor fix.

Here is the complete breakdown of the seven vulnerabilities affecting Malcolm <= v26.07.1:

*Note: In CISA's published advisory text, CVE-2026-107361 carries a 4.2 base score alongside a "HIGH" text label, and CVE-2026-107335/CVE-2026-107334 display copy-paste "Cross-Site Request Forgery" labels next to their actual CWE-409 and CWE-863 identifiers. The technical descriptions and CWE numbers accurately reflect the underlying flaws.

Section Summary: The seven vulnerabilities span authentication bypasses, role-based access control (RBAC) evasions, server-side request forgery (SSRF), cross-site request forgery (CSRF), and storage exhaustion. All seven affect Malcolm <= v26.07.1 and are resolved in v26.08.0.

Deep Dive: Reverse Proxy Tricks and Forged Identities​

Three of the most intriguing vulnerabilities in this advisory illustrate a classic architectural hazard in modern containerized applications: what happens when a reverse proxy, an embedded scripting layer, and a backend service make slightly different assumptions about HTTP requests.

1. The Case-Sensitivity Trap (CVE-2026-107336)​

Malcolm sits behind an Nginx reverse proxy that handles authentication before passing traffic to backend containers like Arkime and OpenSearch Dashboards. To provide a "Dashboards → Arkime shortcut," the Nginx configuration defined a location block using a case-insensitive regular expression matcher, paired with a case-sensitive URL rewrite rule.

What happens if an attacker sends a request using uppercase letters, such as /IDDASH2ARK/...?

1. The case-insensitive location matcher fires, pulling the request into that specific Nginx block.
2. The case-sensitive rewrite rule fails to match the uppercase letters, so no redirect occurs.
3. Nginx falls through to the block's proxy_pass directive, sending the request directly to the Arkime backend.
4. Crucially, this specific shortcut block was the only proxied location in the shipped configuration that omitted the per-location authentication include file.
5. Even worse, the block forwarded client-supplied X-Forwarded-User headers without overwriting them—and Arkime was configured to trust X-Forwarded-User as the authenticated identity.

The result? An unauthenticated network caller could simply capitalize the path, waltz right past Nginx authentication, and hand Arkime a forged X-Forwarded-User header to auto-provision an identity. In v26.08.0 (tracked upstream as GHSA-7j32-cf27-cp6h), the team closed this gap across case-variant paths including /IDDASH2ARK/ and /DASHBOARDS/APP/EXTRACTED-FILES/.

2. Lua RBAC vs. Nginx URI Normalization (CVE-2026-107333 and CVE-2026-107334)​

Even when a user is properly authenticated with a low-privilege account, Malcolm uses a Lua-based Role-Based Access Control (RBAC) layer inside Nginx to block access to sensitive administrative paths like /htadmin, /auth, /admin_login, /arkime/api/esadmin, NetBox, PHP server routes, and artifact upload interfaces.

However, CVE-2026-107333 (CVSS 8.1) and CVE-2026-107334 (CVSS 5.4) revealed that the Lua authorization script and Nginx's internal router were not speaking the same dialect of URL normalization. In CVE-2026-107334, the Lua RBAC layer checked restrictions by pattern-matching the raw, percent-encoded request URI, whereas Nginx selected the destination location block using the percent-decoded, normalized URI.

By requesting /%68tadmin.php (where %68 is the hex encoding for the lowercase letter h), a low-privilege user could fool the Lua script—which saw /%68tadmin.php and found no rule against it—while Nginx dutifully decoded the string to /htadmin.php and routed the caller straight into the restricted administrative interface. As the v26.08.0 release notes detail (GHSA-jr6p-63pg-hr6g), the fix required overhauling the Lua authorization layer to properly handle percent-encoded, case-varied, and slash-doubled request paths.

3. Side-Stepping the Proxy Entirely on Port 8005 (CVE-2026-107361)​

Why bother tricking the front door if a window on the side of the building is wide open? In Malcolm <= v26.07.1, the Arkime live capture service (arkime-live) ran with Docker's network_mode: host, binding port 8005 across all network interfaces (viewHost=0.0.0.0). Because Arkime was configured to trust the X-Forwarded-User header from any IP address (userAuthIps=::,0.0.0.0/0), auto-create users with full access, and rely on a hardcoded passwordSecret set to the public string "Malcolm", a network-adjacent attacker could bypass Nginx altogether by connecting directly to port 8005 with a forged identity header.

In v26.08.0 (GHSA-86h3-7rf8-8j34), the developers explicitly configured Arkime's authMode and defaulted sensor and live-capture nodes to server-to-server (s2s) authentication, ensuring port 8005 reachback requires a proper shared secret and timestamp rather than falling back to weaker defaults.

Section Summary: Parser differentials between security middleware and backend routers remain one of the most reliable ways to break web proxies. Whether through uppercase path segments, hex-encoded characters, or host-mode ports exposed to adjacent networks, these three flaws allowed attackers to impersonate privileged users or reach admin consoles.

SSRF, Kiosk Self-Destruct, and Gzip Bombs​

Beyond authentication and authorization, the remaining three CVEs target Malcolm's operational utilities and storage pipeline.

• FilePond SSRF (CVE-2026-107362): Malcolm's file-upload container ships the upstream FilePond PHP server (pqina/filepond-server-php). While Malcolm overwrote config.php and submit.php, the Dockerfile copied the rest of the upstream *.php files intact—including index.php. That file exposed a fetch API route that uses curl (with FOLLOWLOCATION enabled) to download arbitrary URLs. If an authenticated attacker sent a HEAD request to this route, the server stored the fetched response body in the upload container's transfer directory and returned a transfer ID, allowing the attacker to read back the full contents of internal URLs.
• The Kiosk "Wipe Everything" CSRF (CVE-2026-107337): For operators running Malcolm's kiosk Flask application, the service exposed an unauthenticated POST /script_call/ endpoint configured with wildcard Cross-Origin Resource Sharing (CORS(app)). If an operator had a browser open on the sensor and visited a malicious or compromised webpage, a Cross-Site Request Forgery (CSRF) payload could silently instruct the kiosk endpoint to execute arbitrary management commands. CISA specifically notes that an attacker could trigger control.py --wipe—which permanently deletes all captured network traffic and forensic logs—or control.py --stop, blinding network security monitoring right when an intruder wants the cameras turned off. In v26.08.0 (GHSA-w8gq-4v5x-xrrm), the team enforced same-origin requests via the Sec-Fetch-Site header and replaced free-text command execution with a fixed allowlist of operations.
• Single-Stream Decompression Bombs (CVE-2026-107335): Earlier in summer 2026, Malcolm patched an archive-extraction resource exhaustion flaw (CVE-2026-63133) in v26.07.1 by adding entry-count, nesting-depth, and total-uncompressed-byte limits to scripts/safe-extract.py when extracting container archives like .zip, .tar, .rar, and .7z via libarchive. However, CVE-2026-107335 revealed that those guardrails did not apply when an authenticated user uploaded a single-stream compressed format (.gz, .bz2, .xz, .lzma, or .lz) that wasn't wrapped in a .tar.* archive. A low-privilege user permitted to upload PCAPs or logs could submit a tiny gzip bomb that expanded unbounded on disk, filling up the shared Docker volume used by OpenSearch, Logstash, Arkime, and Zeek and taking down the entire platform. Version 26.08.0 (GHSA-f2v6-8cj4-mhr6) extended the extraction limits to raw-stream and lzip-compressed uploads.

Section Summary: An attacker with low privileges or a lured operator browser could abuse these three flaws to read internal container services via SSRF, exhaust shared Docker storage with a single-stream gzip bomb, or trick the kiosk service into wiping all forensic evidence.

Why Jumping Straight to Malcolm v26.09.0 Matters​

While CISA's ICSA-26-280-01 advisory lists v26.08.0 as the remediation target for these seven CVEs, examining the official cisagov/Malcolm GitHub release notes reveals why administrators should not stop at v26.08.0.

On September 30, 2026, the Malcolm team released v26.09.0, which patches three additional security vulnerabilities in the exact same architectural neighborhoods:

1. FilePond SSRF Remediation (GHSA-cvx2-hj33-vc4q): Explicitly strips the FETCH_REMOTE_FILE route from the vendored FilePond PHP server at build time and pins the upstream branch to a specific commit so authenticated users cannot probe internal services like OpenSearch, the Malcolm API, Dashboards, or NetBox.
2. Nginx /./ Path Segment RBAC Bypass (GHSA-v66f-cwcm-hf73): Fixes an issue where single-dot /./ path segments were not resolved by normalize_uri_for_rbac() in Lua even though Nginx resolves them before location selection—a flaw that previously let authenticated users prefix paths with ./ to reach /upload, /server/php, /htadmin, and /auth in Keycloak RBAC deployments.
3. NetBox Proxy Auth Gate & Case-Sensitivity Fix (GHSA-1107 / #1107): Closes a missing authentication gate and case-sensitivity mismatch on the /dashboards/app/netbox/ proxy location—the exact same class of defect as CVE-2026-107336.

In short, upgrading from v26.07.1 to v26.08.0 resolves the October 15 CISA advisory list, but upgrading to v26.09.0 closes follow-on variants in the Nginx proxy and FilePond upload container while upgrading the htadmin container from end-of-life Debian 11 / PHP 7.4 to Debian 13 / PHP 8.4.

Actionable Remediation and Upgrade Guide for Administrators​

CISA notes that no known public exploitation specifically targeting these vulnerabilities had been reported at the time of publication. However, because Malcolm holds the keys to your network telemetry and forensic history, patching and network hygiene should be treated as immediate priorities.

Step 1: Audit Your Current Malcolm Version​

Check the version of your deployed Malcolm instances. As noted in AcidPeak's vulnerability guidance for Malcolm, operators can verify their running version through the web interface by viewing the About or Settings page, or by inspecting the deployment tags in their Docker or Kubernetes environment. Any instance running v26.07.1 or earlier is vulnerable to the seven CVEs in ICSA-26-280-01.

Step 2: Follow the Mandatory Script Migration Sequence​

Whether you deploy Malcolm on Linux hosts, Windows Subsystem for Linux 2 (WSL2) / Docker Desktop lab environments, or cloud container clusters, do not simply pull new container images and restart. According to the official Malcolm GitHub release notes for both v26.08.0 and v26.09.0:

1. Before running configuration or startup scripts on an existing installation, run:
   ./scripts/status
   (This allows Malcolm to automatically migrate existing settings across versions.)
2. Only after ./scripts/status completes its migration should you proceed with ./scripts/configure, ./scripts/start, or other Malcolm control scripts.

Step 3: Lock Down Network Exposure and Port 8005​

Following CISA's recommended practices and defense-in-depth principles:

• Eliminate Direct Exposure: Ensure Malcolm interfaces and control-system monitoring nodes are never directly accessible from the public internet. Isolate sensor and analysis networks behind firewalls, separated from general business networks.
• Verify Port 8005 Access Controls: If you have live-capture sensors (arkime-live) running prior to upgrading, ensure host firewall rules (such as ufw or iptables) restrict incoming traffic on TCP port 8005 strictly to trusted Malcolm management nodes.
• Harden Remote Access: Require updated Virtual Private Networks (VPNs) and multi-factor authentication before allowing analysts to reach the Malcolm web proxy, and remind operators never to browse untrusted external websites from kiosk or sensor terminals where CSRF attacks (like CVE-2026-107337) could fire against local management endpoints.

Security monitoring tools are prime targets during an intrusion—because blinding the defender or stealing their packet captures is the fastest way for an attacker to stay invisible. Giving Seth Grover and the CISA/INL team credit for transparently finding, documenting, and fixing these flaws in their own open-source stack is easy; making sure your SOC actually applies the update is what keeps your forensic logs intact.