GHSA-38X9-25WX-7FG2

Vulnerability from github – Published: 2026-06-18 14:24 – Updated: 2026-06-18 14:24
VLAI
Summary
Heimdall: IP Spoofing via Unvalidated Forwarding Headers
Details

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) Forwarded or X-Forwarded-For headers before forwarding them.
  • Avoid relying on Request.ClientIPAddresses for security-sensitive decisions until patched
Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.17.16"
      },
      "package": {
        "ecosystem": "Go",
        "name": "https://github.com/dadrus/heimdall"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-116",
      "CWE-20",
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:24:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen 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.\nIn 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 \u2014 including trailing quote characters \u2014 treated as independent addresses.\n\n### Impact\n\n`Request.ClientIPAddresses` is available to all pipeline mechanisms. Its contents can therefore influence rule evaluation in deployments where rules reference this property \u2014 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.\n\nAdditionally, 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.\n\n### Attack Scenarios\n\nAll 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.\n\n#### Scenario A \u2013 Manipulation of rule evaluation\n\nAn attacker who can influence forwarding headers \u2014 either by connecting directly to heimdall or through a proxy that does not sanitize these headers \u2014 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.\n\n#### Scenario B \u2013 IP spoofing against upstream services (proxy mode)\n\nIn 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.\n\n#### Scenario C \u2013 Malformed entries via quoted-string misparse\n\nA `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.\n\n### Workarounds\n\n* Ensure at the network level that only trusted proxies can communicate directly with heimdall.\n* Ensure that the proxy forwarding the requests to heimdall sanitizes or overrides (not merely appends to) `Forwarded` or `X-Forwarded-For` headers before forwarding them.\n* Avoid relying on `Request.ClientIPAddresses` for security-sensitive decisions until patched",
  "id": "GHSA-38x9-25wx-7fg2",
  "modified": "2026-06-18T14:24:37Z",
  "published": "2026-06-18T14:24:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dadrus/heimdall/security/advisories/GHSA-38x9-25wx-7fg2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dadrus/heimdall"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Heimdall: IP Spoofing via Unvalidated Forwarding Headers"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…