Summary
Heimdall: IP Spoofing via Unvalidated Forwarding Headers
When the trusted_proxies option is configured, heimdall extracts client IP addresses from the Forwarded (for= parameter) 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 , and ; without accounting for RFC 7239 quoted strings, which can cause a single quoted value to be parsed as multiple entries, with fragments, including trailing quote characters, treated as independent addresses.
Attack Scenarios
All scenarios require that trusted_proxies is configured. If this option is not set, heimdall ignores forwarding headers entirely, and this vulnerability is not exploitable. Scenarios A and C (see below) additionally require that rules reference Request.ClientIPAddresses in their pipeline.
Scenario A, Manipulation of rule evaluation
An attacker who can influence forwarding headers, either by connecting directly to heimdall or through a proxy that does not sanitize these headers, can inject arbitrary values into Request.ClientIPAddresses. In deployments where a rule references this property (e.g. to restrict access to specific IP ranges), this may allow an attacker to bypass the intended access control logic.
Scenario B, IP spoofing against upstream services (proxy mode)
In proxy mode, injected or malformed values in Request.ClientIPAddresses are written unchanged into the X-Forwarded-For header sent to upstream services. Upstream services that trust this header may therefore receive and act on attacker-controlled IP values.
Scenario C, Malformed entries via quoted-string misparse
A Forwarded header containing a quoted value with embedded delimiters (, or ;) is misparsed, producing unintended additional entries in Request.ClientIPAddresses, including malformed fragments with trailing quote characters.
Workarounds
- Ensure at the network level that only trusted proxies can communicate directly with heimdall.
- Ensure that the proxy forwarding the requests to heimdall sanitizes or overrides (not merely appends to)
ForwardedorX-Forwarded-Forheaders before forwarding them. - Avoid relying on
Request.ClientIPAddressesfor security-sensitive decisions until patched
Impact
Request.ClientIPAddresses is available to all pipeline mechanisms. Its contents can therefore influence rule evaluation in deployments where rules reference this property, for example, in a CEL authorizer that checks whether a request originates from a trusted IP range using the networks() function, or in a Remote authorizer that forwards the client IP as part of its payload to an external authorization system. Whether and how Request.ClientIPAddresses is used is entirely determined by the rule configuration.
Additionally, in proxy mode, Request.ClientIPAddresses is used directly to construct the X-Forwarded-For and Forwarded headers forwarded to upstream services. Injected or malformed values are therefore propagated to upstream services unchanged.
The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-57210? CVE-2026-57210 is a high-severity improper input validation vulnerability in https://github.com/dadrus/heimdall (go), affecting versions <= 0.17.16. It is fixed in 0.17.17. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
- Which versions of https://github.com/dadrus/heimdall are affected by CVE-2026-57210? https://github.com/dadrus/heimdall (go) versions <= 0.17.16 is affected.
- Is there a fix for CVE-2026-57210? Yes. CVE-2026-57210 is fixed in 0.17.17. Upgrade to this version or later.
- Is CVE-2026-57210 exploitable, and should I be worried? Whether CVE-2026-57210 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-57210 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-57210? Upgrade
https://github.com/dadrus/heimdallto 0.17.17 or later.