Heimdall performs host matching in a case-sensitive manner, while HTTP hostnames are case-insensitive. This discrepancy can result in heimdall failing to match a rule for a request host that differs only in letter casing, potentially causing the request to be classified differently than intended.
Note: The issue can only lead to unintended access if heimdall is configured with an "allow all" default rule. Since v0.16.0, heimdall enforces secure defaults and refuses to start with such a configuration unless this enforcement is explicitly disabled, e.g. via --insecure-skip-secure-default-rule-enforcement or the broader --insecure flag.
This vulnerability can potentially be exploited by an adversary if rule matching relies on the request host.
For example, consider the following rule:
id: rule-1
match:
hosts:
- type: exact
value: admin.example.com
execute: # configured to require authentication and authorization
# ...
If an adversary now sends a request with the Host header set to Admin.Example.Com, rule-1 will not be matched, and the following will happen instead:
404 Not Found)Bypass of access control policies enforced by heimdall may lead to the following consequences:
--insecure or the --insecure-skip-secure-default-rule-enforcement flags.regex type for host matching, expressions shall be defined in a case-insensitive manner (e.g. (?i)^admin\.example\.com$){
"cwe_ids": [
"CWE-178",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:30:18Z",
"nvd_published_at": "2026-05-08T04:16:22Z",
"severity": "HIGH"
}