CVE-2026-42273

Heimdall is a cloud native Identity Aware Proxy and Access Control Decision service. Prior to version 0.17.14, 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. This issue has been patched in version 0.17.14.

Heimdall is a cloud native Identity Aware Proxy and Access Control Decision service. Prior to version 0.17.14, 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. This issue has been patched in version 0.17.14.

### Summary 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: ```yaml 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 `--insecure` or the `--insecure-skip-secure-default-rule-enforcement` flags. * When using `regex` type 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.

### Summary 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: ```yaml 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 `--insecure` or the `--insecure-skip-secure-default-rule-enforcement` flags. * When using `regex` type 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.