Heimdall EUVD-2026-94738

Exploitation requires the POST /test_config and/or GET /get_stats endpoints (the enhanced-application test and live-stats features backed by SupportedApps::execute()) to be reachable and, per the description, accessible via CSRF in a given installation - the author explicitly scopes this to 'some realistic installations,' so it is not universal across all deployments. A victim with network reachability to the Heimdall instance must be tricked into loading attacker-controlled content (UI:R), since the request is delivered through their browser rather than by direct attacker authentication. The impact of the cloud-metadata vector (169.254.169.254) is further conditioned on Heimdall running on a cloud instance exposing an unauthenticated metadata service. Limiting factors: mandatory user interaction, dependence on the test/stats endpoints being CSRF-reachable in that specific install (AC:H), and confidentiality-only impact limited to a status/port oracle plus partial response data.

This is a genuine but low-urgency issue, not a high-priority emergency. The CVSS base score is only 3.4, and the input vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N) is internally consistent with the description: network-reachable (AV:N) but requiring both high attack complexity (AC:H, reflecting the 'in some realistic installations' caveat) and user interaction (UI:R, reflecting the CSRF delivery vector), with only low confidentiality impact (C:L, a status/port oracle plus partial response data) and no integrity or availability impact. Exploitation status is 'publicly available exploit code exists' - a POC repo (kashishtopi/heimdall-unauth-ssrf) is referenced - but there is NO CISA KEV listing and NO EPSS score in the provided data, so there is no evidence of active or widespread exploitation; POC availability must not be conflated with in-the-wild use. The 'unauthenticated' framing is accurate per PR:N, but note the attacker does not directly authenticate - exploitation is laundered through a victim's browser via CSRF, which materially lowers real-world reliability. The main legitimate concern is the cloud-metadata angle (169.254.169.254), which could expose IAM credentials if Heimdall runs on a cloud instance, but that is an environment-dependent amplifier rather than a property of the base flaw. Missing signals: EPSS and KEV are both absent from input - treat exploitation likelihood as low-to-moderate and targeted, not mass-scanning.

An attacker crafts a malicious web page that auto-submits a POST to /test_config (or triggers GET /get_stats) on a victim's reachable Heimdall instance and lures a user who can reach that instance into visiting it. Because SupportedApps::execute() uses a GuzzleHttp client with no IP restrictions, the server is coerced into contacting an attacker-chosen internal host/port - including the cloud metadata endpoint 169.254.169.254 - returning a status/port oracle and partial response data. A public POC (kashishtopi/heimdall-unauth-ssrf) exists, but the AC:H/UI:R requirements mean success depends on a reachable instance and a cooperating victim browser.