CVE-2026-107336: Authentication Bypass by Spoofing in Malcolm
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 proxypass 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Malcolmto a version that resolves this vulnerability.Fixed in v26.08.0
Event History
Frequently Asked Questions
Does this affect the shipped configuration or only customized deployments?
The affected Dashboards-to-Arkime shortcut is present in the shipped front nginx configuration. It is the proxied location that does not include the per-location authentication file.
What does an attacker need to exploit this?
An unauthenticated network caller can exploit the issue without credentials or user interaction. The request must use a path segment whose casing matches the case-insensitive location matcher but does not match the case-sensitive rewrite, such as /IDDASH2ARK/.
Can an attacker impersonate an Arkime user?
Yes. The affected proxy location forwards a client-supplied X-Forwarded-User header without overwriting it, and Arkime trusts that header as the authenticated username, allowing a forged auto-provisioned identity.