Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
When the trusted_proxies option is configured, heimdall extracts client IP addresses from the Forwarded and X-Forwarded-For headers and exposes them as Request.ClientIPAddresses to the rule pipeline. However, extracted values are not validated to be syntactically valid IP addresses. Arbitrary strings, malformed IP literals, and RFC 7239 unknown values and obfuscated identifiers are accepted without further checks. In addition, the Forwarded header parser splits on commas and semicolons without accounting for RFC 7239 quoted strings, which can cause a single quoted value to be parsed as multiple entries, with fragments treated as independent addresses. Request.ClientIPAddresses is available to all pipeline mechanisms. Its contents can therefore influence rule evaluation in deployments where rules reference this property. Additionally, in proxy mode, Request.ClientIPAddresses is used directly to construct the X-Forwarded-For and Forwarded headers forwarded to upstream services.…
Recommended action: Upgrade to 0.17.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When Heimdall operates in proxy mode, it constructs the Forwarded HTTP header after executing the matched rule pipeline by inserting the incoming request's Host header value directly into the header string without sanitizing commas or semicolons. This allows an attacker to inject additional parameters into the Forwarded header, potentially spoofing IP addresses for upstream services. Vulnerable Code File: proxy/requestcontext.go (line 201) Go's net/http allows commas and semicolons in Host header values. No sanitization is applied before string concatenation. PoC This produces the following Forwarded header sent to the upstream service: Upstream services that parse the Forwarded header according to RFC 7239 will see two entries. If the service trusts the last or any for= value, the attacker successfully spoofs 127.0.0.1 as the client IP. Impact - IP spoofing: Upstream services behind Heimdall may trust the injected for= value, believing the request originates from an…
Recommended action: Upgrade to 0.17.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 allowencodedslashes option to be set to on or nodecode.) 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. 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…
Recommended action: Upgrade to 0.17.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 0.17.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Heimdall handles URL-encoded slashes (%2F) in a case-sensitive manner, while percent-encoding is defined to be case-insensitive. As a result, the lowercase equivalent (%2f) is not recognized and therefore not processed as expected when allowencodedslashes is set to off (the default setting). This discrepancy can lead to differences in how request paths are interpreted by heimdall and upstream components, which may result in authorization bypass. 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 Consider the following rule configuration: If an adversary sends a request such as /admin%2fsecret, neither is the above rule matched, nor is the request rejected (as would be expected…
Recommended action: Upgrade to 0.17.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/dadrus/heimdall >= 0.7.0-alpha, <= 0.17.10
Fixed in
0.17.11· Vendor fix available
Issue
When using heimdall in envoy gRPC decision API mode, wrong encoding of the query URL string allows rules with non-wildcard path expressions to be bypassed. The HTTP based decision API is NOT affected, and proxy mode is NOT affected either. 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 Envoy splits the requested URL into parts, and sends the parts individually to heimdall. Although query and path are present in the API, the query field is documented to be always empty and the URL query is included in the path field [1]. The implementation uses go's url library to reconstruct the url which automatically encodes special characters in the path.…
Recommended action: Upgrade to 0.17.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.