Heimdall CVE-2026-57210

Exploitation requires that the trusted_proxies option is configured - if it is not set, heimdall ignores the Forwarded and X-Forwarded-For headers entirely and the vulnerability is not exploitable. The attacker must additionally be able to influence those forwarding headers, either by connecting directly to heimdall or through a proxy that appends rather than sanitizes/overrides them. For manipulation of rule evaluation (Scenario A) and the quoted-string misparse abuse (Scenario C), the deployment's rules must reference Request.ClientIPAddresses (e.g. a CEL authorizer using networks() for IP-range checks, or a Remote authorizer forwarding client IP); where no rule consumes this property these scenarios do not apply. In proxy mode (Scenario B), injected/malformed values are written unchanged into the X-Forwarded-For/Forwarded headers sent upstream, so impact depends on upstream services trusting that header. Limiting factors: non-default configuration (trusted_proxies) is mandatory, rule dependence on ClientIPAddresses gates the access-control-bypass path, and placing heimdall behind a proxy that overrides these headers neutralizes the attack.

This is a configuration- and rule-dependent access-control/spoofing flaw in heimdall, not a broadly critical remote-code issue. The supplied CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N, base 7.0) is internally telling: the vulnerable system itself has no confidentiality, integrity or availability impact (VC/VI/VA:N), and all impact falls on SUBSEQUENT systems (SC:H/SI:H) - i.e. the access-control decisions and upstream services that consume heimdall's Request.ClientIPAddresses. AT:P (attack requirements present) correctly encodes that exploitation is not universal: it requires trusted_proxies to be configured, and for the rule-evaluation scenarios, rules that actually reference Request.ClientIPAddresses. The vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a meaningful but non-emergency priority. No EPSS score, no CISA KEV listing, and no exploit/PoC reference were provided in the input, so there is no signal of active or imminent exploitation - the risk is driven by exploitability of a logic/validation flaw, not by observed attacks. Net: real and worth patching promptly where the preconditions hold, but its severity is entirely gated by deployment configuration rather than being a blanket high-risk exposure. Note the Tags label this 'Information Disclosure', whereas the GHSA (CWE-116/CWE-290) frames it as IP spoofing / access-control bypass - treat the primary impact as spoofing and access-control manipulation, not data disclosure.

A heimdall deployment has trusted_proxies configured and a rule (e.g. a CEL authorizer using networks()) that restricts access based on Request.ClientIPAddresses. An attacker who can set forwarding headers - by connecting directly to heimdall or via a proxy that does not sanitize them - sends a crafted Forwarded or X-Forwarded-For header containing a spoofed or malformed value, which is accepted without IP validation and used to appear as if originating from a trusted IP range, bypassing the intended access control. No public exploit was identified at time of analysis; only the advisory and release references are provided.