GHSA-72H4-MXFC-JX37
Vulnerability from github – Published: 2026-04-25 23:30 – Updated: 2026-05-04 21:59Summary
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.
Details
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:
- If no default rule is configured, the request will result in an error (
404 Not Found) - If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.
Impact
Bypass of access control policies enforced by heimdall may lead to the following consequences:
- Access to or modification of data that should be restricted
- Invocation of functionality that is expected to require authentication or authorization
- In certain configurations, escalation of privileges depending on the exposed functionality
Workarounds
- Normalize request hosts to lowercase in the layers in front of heimdall.
- Do not configure a permissive default rule. Respectively, do not make use of the
--insecureor the--insecure-skip-secure-default-rule-enforcementflags. - When using
regextype for host matching, expressions shall be defined in a case-insensitive manner (e.g.(?i)^admin\.example\.com$) - Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project's service.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/dadrus/heimdall"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.17.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42273"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:30:18Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\n\nHeimdall 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.\n\n**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.\n\n### Details\n\nThis vulnerability can potentially be exploited by an adversary if rule matching relies on the request host.\n\nFor example, consider the following rule:\n\n```yaml\nid: rule-1\nmatch:\n hosts:\n - type: exact\n value: admin.example.com\nexecute: # configured to require authentication and authorization\n # ...\n```\n\nIf 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:\n\n* If no default rule is configured, the request will result in an error (`404 Not Found`)\n* If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.\n\n### Impact\n\nBypass of access control policies enforced by heimdall may lead to the following consequences:\n\n* Access to or modification of data that should be restricted\n* Invocation of functionality that is expected to require authentication or authorization\n* In certain configurations, escalation of privileges depending on the exposed functionality\n\n### Workarounds\n\n* Normalize request hosts to lowercase in the layers in front of heimdall.\n* Do not configure a permissive default rule. Respectively, do not make use of the `--insecure` or the `--insecure-skip-secure-default-rule-enforcement` flags.\n* When using `regex` type for host matching, expressions shall be defined in a case-insensitive manner (e.g. `(?i)^admin\\.example\\.com$`)\n* Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project\u0027s service.",
"id": "GHSA-72h4-mxfc-jx37",
"modified": "2026-05-04T21:59:21Z",
"published": "2026-04-25T23:30:18Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-72h4-mxfc-jx37"
},
{
"type": "PACKAGE",
"url": "https://github.com/dadrus/heimdall"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Heimdall: Case-sensitive host matching may lead to policy bypass"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.