Heimdall EUVD-2026-68115

The Tenable integration controller routes must be network-reachable, which is the default for any Heimdall deployment. Critically, in versions prior to 2.14.0 the Tenable controller had no authentication guard (JwtAuthGuard was added only in the fix commit), so exploitation requires zero credentials - no account, no session token. The attacker must supply a host_url parameter in the request body pointing to an internal host; the backend must be able to initiate outbound TCP connections to that host on the specified port. Exploitation is limited to hosts reachable from the Heimdall server's network position, so cloud-metadata or internal API endpoints co-located in the same VPC or subnet are the primary risk targets. No special Heimdall configuration beyond a running instance is required to be vulnerable.

The NVD CVSS 5.8 reflects a Scope-Changed network vector (AV:N/AC:L/PR:N/UI:N/S:C) with low integrity and no confidentiality impact (C:N/I:L/A:N). However, the C:N rating appears conservative: the vulnerable endpoint is a bidirectional proxy, meaning server responses from internal hosts would likely be returned to the attacker, suggesting C:L is more accurate (raising the effective score toward 6.x). No EPSS data was provided; no KEV entry and no public POC exist at time of analysis, which materially lowers immediate exploitation priority. The most significant real-world risk signal is the complete absence of authentication on the Tenable controller prior to the fix - any network-reachable Heimdall instance was exposed without credential requirements. Exploitation is constrained by Heimdall's limited deployment footprint (primarily government and security-team environments). The C:N vs. C:L discrepancy should be verified against vendor interpretation of the proxy response path.

An unauthenticated attacker who can reach the Heimdall web interface sends a crafted POST request to the Tenable login or proxy endpoint, supplying a host_url value pointing to an internal service (e.g., a cloud metadata endpoint at 169.254.169.254 or an internal API server). The Heimdall backend forwards the request to that internal host and returns the response to the attacker, exposing internal network topology or sensitive service data. No exploit code is publicly available, but the attack requires only standard HTTP tooling given the lack of authentication on the vulnerable endpoint.