CVE-2026-82477: MITRE SAF Heimdall SSRF Vulnerability

CVE-2026-82477 Overview

CVE-2026-82477 is a Server-Side Request Forgery (SSRF) vulnerability in MITRE Security Automation Framework (SAF) Heimdall 2. The flaw affects versions 2.11.6 through 2.13.x before 2.14.0. It resides in the Tenable proxy endpoint implemented in apps/backend/src/tenable/tenable.controller.ts. Remote attackers can abuse the endpoint to make the Heimdall backend issue arbitrary HTTP requests to internal network resources. The issue is tracked as CWE-918: Server-Side Request Forgery.

Critical Impact
A remote unauthenticated attacker can pivot through the Heimdall backend to reach internal services, altering integrity of proxied requests and exposing internal-only endpoints.

Affected Products

MITRE SAF Heimdall 2, versions 2.11.6 through 2.13.x
MITRE SAF Heimdall 2 deployments using the Tenable.SC integration
Fixed in Heimdall 2 v2.14.0

Discovery Timeline

2026-08-29 - CVE-2026-82477 published to NVD
2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-82477

Vulnerability Analysis

Heimdall 2 exposes a Tenable proxy endpoint that accepts a client-supplied host_url value and forwards HTTP requests to that host. Prior to v2.14.0, the controller in apps/backend/src/tenable/tenable.controller.ts did not validate this parameter against an allowlist and did not require authentication on the request path. An attacker reachable to the Heimdall backend can submit crafted host_url values pointing at internal addresses. The backend then issues the request from its own network position, enabling reconnaissance of internal services, metadata endpoints on cloud instances, and interaction with services that trust the backend's IP.

Root Cause

The root cause is missing input validation and missing authentication on the Tenable proxy handler. The controller trusted a user-supplied destination host, forwarding traffic without confirming the host matches an operator-approved target. Combined with an unauthenticated code path, this yields the classic SSRF preconditions defined in CWE-918.

Attack Vector

The vulnerability is exploitable over the network with low complexity and no authentication. An attacker sends a request to the Heimdall backend Tenable proxy route, specifying a host_url targeting an internal resource such as a link-local metadata service, an internal admin interface, or a private subnet host. The Heimdall backend performs the outbound request and returns response data to the attacker, breaking the security boundary between the untrusted client and the internal network (scope: changed).

The upstream fix requires authentication for the Tenable endpoint and validates each supplied host against a configured allowlist in TENABLE_HOST_URL:

text

TENABLE_HOST_URL=<Full URL for the Tenable.SC host, including port (defaults to :443 if the client doesn't specify one).
For multiple allowed hosts, wrap the value in quotes and separate with newlines, e.g.
TENABLE_HOST_URL='https://a.example.com
https://b.example.com:8443'
Client-supplied host_url values not matching an entry in this list are rejected>

Source: Heimdall2 commit b6a9cdb

The patch also wires a new URL validator into the application configuration:

typescript

import * as dotenv from 'dotenv';
import * as fs from 'fs';
import {parseHostUrl} from '../src/utils/url_validation';

export default class AppConfig {
  private envConfig: {[key: string]: string | undefined};

Source: Heimdall2 commit b6a9cdb

Detection Methods for CVE-2026-82477

Indicators of Compromise

Requests to the Heimdall backend Tenable proxy route containing host_url parameters that reference private IP ranges (RFC 1918), loopback addresses, or cloud metadata endpoints such as 169.254.169.254.
Outbound HTTP connections from the Heimdall backend host to internal targets that do not match the configured Tenable.SC host.
Unauthenticated access log entries against Tenable controller routes in Heimdall versions between 2.11.6 and 2.13.x.

Detection Strategies

Inspect reverse proxy or web server logs in front of Heimdall for host_url query or body parameters and compare values to the operator's approved Tenable.SC hosts.
Correlate Heimdall backend egress traffic with the process making the request; flag any outbound requests to non-Tenable destinations originating from the Tenable integration code path.
Alert on HTTP responses returned via the Tenable proxy endpoint that reference internal hostnames, private IPs, or cloud metadata JSON structures.

Monitoring Recommendations

Enable network egress logging on the Heimdall backend and restrict outbound destinations through a firewall or service mesh policy.
Track version metadata for all Heimdall deployments and generate an alert when a running instance reports a version below 2.14.0.
Monitor for spikes in request volume to the Tenable controller path, particularly from unauthenticated sources.

How to Mitigate CVE-2026-82477

Immediate Actions Required

Upgrade Heimdall 2 to v2.14.0 or later, which enforces authentication and host allowlisting on the Tenable endpoint.
Restrict network egress from the Heimdall backend so it can only reach the intended Tenable.SC host and required dependencies.
Audit access logs for anomalous host_url values submitted to the Tenable proxy route.

Patch Information

The fix is delivered in commit b6a9cdb and shipped in release v2.14.0. The patch requires authentication on the Tenable route and validates each client-supplied host_url against the TENABLE_HOST_URL allowlist configured in apps/backend/.env. Additional details are available in the GitHub Security Advisory GHSA-g9vx-2rpf-gpch.

Workarounds

Place Heimdall behind an authenticating reverse proxy that blocks unauthenticated requests to /tenable/* routes until the upgrade is completed.
Apply an egress firewall rule allowing only the approved Tenable.SC host and port from the Heimdall backend, dropping requests to internal subnets and metadata endpoints.
Temporarily disable the Tenable integration by unsetting TENABLE_HOST_URL where the integration is not required.

bash

# Configuration example: restrict Tenable proxy to an explicit allowlist
TENABLE_HOST_URL='https://tenable-sc.internal.example.com:443'

# For multiple approved hosts, use newline-separated entries within quotes
TENABLE_HOST_URL='https://a.example.com
https://b.example.com:8443'