CVE-2026-107361 in Malcolm
Summary
by MITRE • 10/08/2026
The Arkime live capture service (arkime-live) in Malcolm runs with network_mode: host, exposing port 8005 on all network interfaces (viewHost=0.0.0.0). Arkime trusts the X-Forwarded-User header from any IP address (userAuthIps=::,0.0.0.0/0) and auto-creates users with full access. The passwordSecret is hardcoded to the public value "Malcolm". A network-adjacent attacker bypasses nginx entirely by connecting directly to port 8005 with a forged identity header.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability in question stems from a critical misconfiguration within the Malcolm platform, specifically regarding its integration with the Arkime live capture service known as arkime-live. This component is deployed using Docker networking settings that utilize host mode rather than bridge or overlay networks. Consequently, the internal port 8005 associated with the Arkime interface is bound directly to all available network interfaces on the host machine, effectively making it accessible from any external IP address without passing through a reverse proxy such as Nginx. This architectural decision removes the primary layer of access control and request filtering that would typically be enforced by an upstream web server, leaving the application endpoint exposed to direct network interaction.
The core technical flaw lies in how Arkime handles authentication when operating under these specific configuration parameters. The service is configured with a setting called userAuthIps set to accept trust headers from any IP address, represented as :: and 0.0.0.0/0. This means that the application blindly trusts the X-Forwarded-User header sent by clients connecting directly to port 8005. Furthermore, the system is configured to automatically create user accounts upon receiving this header if they do not already exist. When a request arrives with an arbitrary value in the X-Forwarded-User field, Arkime creates a new session for that identity and grants it full administrative privileges by default due to the lack of explicit role restrictions during auto-provisioning. This mechanism allows any network-adjacent attacker to impersonate any user or assume complete control over the system simply by crafting an HTTP request with a forged header.
Compounding this authentication bypass is the use of a hardcoded and publicly known password secret, identified as "Malcolm". While the primary attack vector described relies on header forgery due to the trust configuration, the presence of such weak credentials indicates a broader failure in security hygiene regarding key management. In scenarios where token-based or cookie-based sessions are validated using this secret, an attacker could potentially forge valid session tokens if they understand the underlying cryptographic implementation details associated with Arkime's authentication flow. The combination of trusting unverified headers and utilizing static secrets creates a severe risk environment where identity verification is effectively nullified for any external actor capable reaching port 8005.
The operational impact of this vulnerability is profound, as it results in complete unauthorized access to the Malcolm platform and its underlying Arkime data ingestion infrastructure. An attacker can bypass all intended authentication mechanisms without needing valid credentials or exploiting complex code-level bugs. Once inside, the attacker gains full read and write access to network traffic captures, user configurations, and system settings. This level of compromise allows for extensive surveillance capabilities, including the ability to view sensitive communications captured by Arkime, modify capture rules to exclude malicious activity from logs, or potentially inject false data into the analysis pipeline. The exposure also facilitates lateral movement within the organization if the host machine is part of a larger network segment containing other critical assets.
To mitigate this vulnerability, immediate remediation steps must focus on restricting access and hardening configuration parameters. First, the Docker container for arkime-live should be reconfigured to use bridge networking or explicitly bind port 8005 only to localhost (127.0.0.1) if direct external access is not required. If remote access is necessary, it must be routed through a reverse proxy like Nginx that enforces strict authentication and TLS termination before requests reach the Arkime service. The userAuthIps configuration should be updated to restrict trusted IP ranges to only those of legitimate proxies or internal services, rather than accepting headers from any source (0.0.0.0/0). Additionally, the hardcoded passwordSecret must be replaced with a strong, randomly generated secret stored securely in environment variables or a secrets manager. Regular audits of container configurations and application settings are essential to prevent similar misconfigurations that undermine security controls.
This vulnerability aligns with CWE-287, which describes Improper Authentication, specifically involving the failure to verify identity before granting access. It also relates to CWE-16, known as Configuration Error, where insecure default configurations or hard-coded credentials lead to compromise. From a threat intelligence perspective, this scenario maps to MITRE ATT&CK technique T1078, Valid Accounts, as an attacker leverages forged identities to gain legitimate-looking access without detection by standard authentication logs. The exploitation method also reflects aspects of T1592, Gather Victim Host Information, since the initial connection reveals service details that facilitate further attacks on the host infrastructure.