GHSA-3Q34-RX83-R6MQ
Vulnerability from github – Published: 2026-04-25 23:30 – Updated: 2026-05-12 13:29Summary
Heimdall performs rule matching on the raw (non-normalized) request path, while downstream components may normalize dot-segments according to RFC 3986, Section 6.2.2.3. This discrepancy can result in heimdall authorizing a request for one path (e.g., /user/../admin, or URL-encoded variants such as /user/%2e%2e/admin or /user/%2e%2e%2fadmin. The latter would require the allow_encoded_slashes option to be set to on or no_decode.) while the downstream ultimately processes a different, normalized path (/admin).
Details
This vulnerability can be exploited by an adversary if rule matching is performed using free (named or unnamed) wildcards without further constraints, as shown in the example snippets below.
id: rule-1
match:
routes:
- path: /user/**
execute: # configured to require authentication and authorization
# ...
id: rule-2
match:
routes:
- path: /public/**
execute: # configured to allow anonymous access
# ...
If an adversary sends a request to /public/../user/whatever, rule-2 will be matched and executed. The downstream service may, however, normalize the request path and interpret it as /user/whatever.
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 HTTP paths or reject HTTP paths containing relative path expressions in the layers in front of Heimdall - this is good practice anyway. Some proxies do that by default, such as Traefik; others, such as Envoy, require additional configuration (for Envoy see
normalize_path). - 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-42274"
],
"database_specific": {
"cwe_ids": [
"CWE-35",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:30:46Z",
"nvd_published_at": "2026-05-08T04:16:22Z",
"severity": "HIGH"
},
"details": "### Summary\n\nHeimdall performs rule matching on the raw (non-normalized) request path, while downstream components may normalize dot-segments according to [RFC 3986, Section 6.2.2.3](https://www.rfc-editor.org/rfc/rfc3986#section-6.2.2.3). This discrepancy can result in heimdall authorizing a request for one path (e.g., `/user/../admin`, or URL-encoded variants such as `/user/%2e%2e/admin` or `/user/%2e%2e%2fadmin`. The latter would require the `allow_encoded_slashes` option to be set to `on` or `no_decode`.) while the downstream ultimately processes a different, normalized path (`/admin`).\n\n### Details\n\nThis vulnerability can be exploited by an adversary if rule matching is performed using free (named or unnamed) wildcards without further constraints, as shown in the example snippets below.\n\n```yaml\nid: rule-1\nmatch:\n routes:\n - path: /user/**\nexecute: # configured to require authentication and authorization\n # ...\n```\n\n```yaml\nid: rule-2\nmatch:\n routes:\n - path: /public/**\nexecute: # configured to allow anonymous access\n # ...\n```\n\nIf an adversary sends a request to `/public/../user/whatever`, rule-2 will be matched and executed. The downstream service may, however, normalize the request path and interpret it as `/user/whatever`.\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 HTTP paths or reject HTTP paths containing relative path expressions in the layers in front of Heimdall - this is good practice anyway. Some proxies do that by default, such as Traefik; others, such as Envoy, require additional configuration (for Envoy see [`normalize_path`](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path)).\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-3q34-rx83-r6mq",
"modified": "2026-05-12T13:29:02Z",
"published": "2026-04-25T23:30:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-3q34-rx83-r6mq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42274"
},
{
"type": "WEB",
"url": "https://github.com/dadrus/heimdall/pull/3209"
},
{
"type": "WEB",
"url": "https://github.com/dadrus/heimdall/commit/b5dfa484b7a8c2ce6d8691c026f9da867719947a"
},
{
"type": "PACKAGE",
"url": "https://github.com/dadrus/heimdall"
},
{
"type": "WEB",
"url": "https://github.com/dadrus/heimdall/releases/tag/v0.17.14"
},
{
"type": "WEB",
"url": "https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-normalize-path"
},
{
"type": "WEB",
"url": "https://www.rfc-editor.org/rfc/rfc3986#section-6.2.2.3"
}
],
"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 has an authorization bypass via path normalization mismatch"
}
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.