CVE-2026-107336 in Malcolm
Summary
by MITRE • 10/08/2026
Malcolm's front nginx reverse proxy defines a "Dashboards → Arkime shortcut" location using a case-insensitive regex matcher but a case-sensitive rewrite. A request whose path segment is not exact-lowercase (for example /IDDASH2ARK/...) enters the location (the matcher fires) but evades the rewrite (no redirect is issued), so nginx falls through to the location's proxy_pass to the Arkime backend. That location is the one proxied location in the shipped config that does not include the per-location authentication file, so the request reaches Arkime unauthenticated. The same location also forwards a client-supplied X-Forwarded-User header un-overwritten, and Arkime is configured to trust X-Forwarded-User as the authenticated username — so an unauthenticated network caller can reach the Arkime backend while supplying a forged, auto-provisioned identity.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/08/2026
The vulnerability stems from a configuration error in Malcolm's front-end Nginx reverse proxy that creates an authentication bypass for the Arkime analytics platform. The specific issue lies within the location block designated as "Dashboards → Arkime shortcut," which utilizes a case-insensitive regular expression matcher to identify valid requests but employs a case-sensitive rewrite rule to handle URL redirection. This mismatch in logic allows attackers to exploit the discrepancy by submitting request paths that do not match the exact lowercase format expected by the rewrite directive. When such a non-lowercase path is submitted, the location block's regex condition evaluates as true, causing Nginx to enter the block, but the subsequent case-sensitive rewrite fails to trigger because the input does not strictly conform to the required casing. Consequently, instead of being redirected or handled securely, the request falls through to the proxy_pass directive associated with that location block.
This fall-through behavior is particularly dangerous because this specific location block in the default configuration lacks an include statement for a per-location authentication file. In standard secure configurations, such intermediate proxies typically enforce access controls before forwarding traffic to backend services. The absence of these checks means that any request reaching this proxy_pass directive bypasses all frontend authentication mechanisms entirely. As a result, unauthenticated external actors can directly interact with the Arkime backend service without presenting valid credentials or session tokens, effectively treating the reverse proxy as an open door rather than a secure gateway.
The severity of this vulnerability is significantly amplified by how Arkime handles identity verification through HTTP headers. The vulnerable location block forwards the client-supplied X-Forwarded-User header to the backend without overwriting it with any verified server-side session data or authenticated user identifier. Arkime is configured to trust the value contained in the X-Forwarded-User header as the definitive source of truth for the current user's identity. This architectural decision, while common in internal microservices architectures behind trusted proxies, becomes a critical flaw when combined with the authentication bypass described above. An attacker can simply inject arbitrary values into this header to impersonate any existing user or create new identities within Arkime’s auto-provisioning system.
The operational impact of this vulnerability allows for complete identity spoofing and unauthorized access to sensitive network traffic analysis data. By forging the X-Forwarded-User header, an unauthenticated attacker can assume the privileges of high-level administrators, view restricted dashboards, export raw packet captures, or manipulate search queries that could lead to further exploitation within the Arkime ecosystem. This undermines the integrity of the entire security monitoring infrastructure, as all actions performed under these forged identities will be logged with false attribution, potentially masking malicious activity from legitimate security teams. The ability to auto-provision new accounts also means an attacker can establish persistent access points without needing prior knowledge of valid credentials.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity within the context of proxy configurations. It is further categorized under MITRE ATT&CK technique T1078 Valid Accounts, as it allows an attacker to use legitimate-looking credentials that were never properly validated by the authentication subsystem. The root cause is a classic configuration drift where security controls are applied inconsistently across different URL patterns or location blocks within the web server software.
Mitigation requires immediate remediation of the Nginx configuration to ensure consistent handling of case variations and enforce strict access control on all proxied locations. Administrators should modify the regex matcher in the Arkime shortcut location block to be strictly case-sensitive, ensuring that only exact lowercase paths are processed by this specific logic path. Alternatively, if mixed-case support is required for legacy reasons, the rewrite rule must also be adjusted to handle these variations correctly without falling through to an unprotected proxy_pass directive. Crucially, a per-location authentication file or equivalent access control module such as auth_request must be included in every location block that proxies traffic to sensitive backends like Arkime. This ensures that even if URL matching logic varies, the fundamental requirement for valid session tokens is enforced before any backend interaction occurs. Additionally, relying solely on forwarded headers for identity should be re-evaluated; implementing mutual TLS or cookie-based session validation at the proxy level provides a more robust defense against header injection attacks.