How severe is GHSA-72h4-mxfc-jx37?

No CVSS score has been assigned to GHSA-72h4-mxfc-jx37 yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-72h4-mxfc-jx37?

GHSA-72h4-mxfc-jx37 affects the following packages: github.com/dadrus/heimdall (Go). Ecosystems affected: Go.

How do I fix GHSA-72h4-mxfc-jx37?

Update github.com/dadrus/heimdall to 0.17.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-72h4-mxfc-jx37 is resolved across your whole dependency graph.

How do I detect GHSA-72h4-mxfc-jx37 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/dadrus/heimdall. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-72h4-mxfc-jx37 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-72h4-mxfc-jx37?

O3 pinpoints whether GHSA-72h4-mxfc-jx37 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-72h4-mxfc-jx37 actively exploited in the wild?

No public exploit code has been indexed for GHSA-72h4-mxfc-jx37 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-72h4-mxfc-jx37 published, and has it been updated?

GHSA-72h4-mxfc-jx37 was published on April 25, 2026 and was last updated on June 25, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

GHSA-72h4-mxfc-jx37

GHSA-72h4-mxfc-jx37 is a security vulnerability in github.com/dadrus/heimdall. O3 Security confirms whether GHSA-72h4-mxfc-jx37 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Heimdall: Case-sensitive host matching may lead to policy bypass

Also known asCVE-2026-42273GO-2026-5200

Published

Apr 25, 2026

Updated

Jun 25, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐹github.com/dadrus/heimdall

Real-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

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:

id: rule-1
match:
  hosts:
    - type: exact
      value: admin.example.com
execute: # configured to require authentication and authorization
  # ...

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 request will result in an error (404 Not Found)
If a default rule is configured, it will be executed. If the default rule is configured in an overly permissive way (e.g. allowing anonymous access), this results in a policy bypass.

Impact

Bypass of access control policies enforced by heimdall may lead to the following consequences:

Access to or modification of data that should be restricted
Invocation of functionality that is expected to require authentication or authorization
In certain configurations, escalation of privileges depending on the exposed functionality

Workarounds

Normalize request hosts to lowercase in the layers in front of heimdall.
Do not configure a permissive default rule. Respectively, do not make use of the --insecure or the --insecure-skip-secure-default-rule-enforcement flags.
When using regex type for host matching, expressions shall be defined in a case-insensitive manner (e.g. (?i)^admin\.example\.com$)
Include the ID of the rule expected to be executed in the JWT issued by heimdall and check that value in the consuming project's service.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/dadrus/heimdall`	all versions	0.17.14

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/dadrus/heimdall. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/dadrus/heimdall to 0.17.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-72h4-mxfc-jx37 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-72h4-mxfc-jx37 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-72h4-mxfc-jx37. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary 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-sec

O3 Security · Impact-Aware SCA

Is GHSA-72h4-mxfc-jx37 in your dependencies?

O3 detects GHSA-72h4-mxfc-jx37 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works

GHSA-72h4-mxfc-jx37

Blast Radius

Description

Summary

Details

Impact

Workarounds

Affected Packages

Detection & mitigation playbook

Detect

Fix

Workarounds

How O3 protects you

Frequently Asked Questions

Is GHSA-72h4-mxfc-jx37 in your dependencies?