Heimdall: IP Spoofing via Unvalidated Forwarding HeadersGHSA-38x9-25wx-7fg2
GHSA-38x9-25wx-7fg2 is a Improper Input Validation vulnerability in https://github.com/dadrus/heimdall. A fix is available for https://github.com/dadrus/heimdall — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-38x9-25wx-7fg2.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
https://github.com/dadrus/heimdallReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Summary
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.
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.
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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | https://github.com/dadrus/heimdall | all versions | 0.17.17go get https://github.com/dadrus/heimdall@v0.17.17 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for https://github.com/dadrus/heimdall, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update https://github.com/dadrus/heimdall to 0.17.17 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-38x9-25wx-7fg2 is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
Frequently Asked Questions
Is GHSA-38x9-25wx-7fg2 in your dependencies?
Find it across Go, including transitive dependencies.