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$)| Score | Percentile |
|---|---|
| 0.06% | 17.41% |
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 7.8 | 4.0 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-72h4-mxfc-jx37 ↗ |
| CVE | CVE-2026-42273 ↗ |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| go | github.com/dadrus/heimdall | < 0.17.14 | 0.17.14 | — |