CVE-2026-120006: Elevation of Privilege in .NET Aspire via Unintended Dashboard Endpoint Tunneling

.NET Aspire is an orchestration framework designed for building observable, production-ready distributed applications. A central component of its local development experience is the Developer Control Plane (DCP) and the .NET Aspire Dashboard. The DCP manages the lifecycle and network connectivity between host-run projects, executables, and containerized services, while the Aspire Dashboard collects telemetry and provides an administrative user interface for inspecting distributed traces, logs, metrics, and runtime configurations.

When containerized workloads need to communicate with services executing directly on the developer's host machine, .NET Aspire utilizes a container tunneling mechanism controlled by the EnableAspireContainerTunnel configuration option. This feature instructs the DCP to instantiate proxy tunnels that bridge the isolated container network namespace with designated ports on the host machine. A primary use case for this bridge is allowing containers to transmit telemetry data to the Aspire Dashboard via OpenTelemetry Protocol (OTLP) endpoints.

In .NET Aspire versions prior to 13.6.5, the orchestration engine fails to filter the endpoints exposed when establishing a dependency link between a containerized resource and the AspireDashboard host resource. Instead of restricting the proxy tunnel exclusively to the OTLP gRPC and OTLP HTTP ingestion ports, the DCP automatically tunnels all endpoints associated with the dashboard resource. This includes the administrative HTTP and HTTPS frontend management interfaces.

Tracked as CVE-2026-120006 and classified under CWE-201 (Insertion of Sensitive Information Into Sent Data), this flaw breaks the isolation boundary between containerized workloads and the host orchestration control plane. An attacker with code execution inside an application container can traverse the proxy tunnel to access the dashboard frontend, retrieve sensitive runtime data such as connection strings and bearer tokens across all orchestrated services, and execute administrative actions to elevate privileges on the host.

The root cause of CVE-2026-120006 resides in how the Developer Control Plane (DCP) resolves and provisions host dependencies during container creation inside src/Aspire.Hosting/Dcp/ContainerCreator.cs. When a container resource is configured to export telemetry—typically via the WithOtlpExporter() extension method—the orchestration engine registers an implicit dependency on the AspireDashboard host resource so that the container can resolve the dashboard's network address.

During the container provisioning lifecycle, ContainerCreator invokes GetHostDependenciesAsync to enumerate all host resources that the target container depends upon. Each discovered dependency is encapsulated in a HostResourceWithEndpoints structure, which pairs the resource definition with an array of its registered EndpointAnnotation objects. For the AspireDashboard resource, this collection encompasses both the telemetry receivers (OtlpGrpcEndpointName on port 4317 and OtlpHttpEndpointName on port 4318) and the user-facing web application endpoints (commonly bound to local ports such as 18888).

Prior to the patch, when _options.Value.EnableAspireContainerTunnel evaluated to true, the orchestration logic iterated through the resolved hostDependencies collection without inspecting the semantic role of the AspireDashboard endpoints. It treated the dashboard identically to standard host dependencies, instructing the DCP network proxy to bind tunnel listeners inside the container network for every endpoint present on the AspireDashboard resource.

Furthermore, legacy localhost URL resolution via HostUrl strings lacked granular endpoint association at the dependency-discovery boundary. Because the dashboard's administrative frontend is designed to aggregate diagnostic telemetry, environment variables, process launch arguments, and service secrets across the entire distributed application model, binding its management port into the container network exposed sensitive control-plane data to untrusted guest workloads.

Microsoft addressed CVE-2026-120006 in commit f017f668fd6e0938e23058dc0450a1403f409809 by introducing explicit endpoint filtering for the AspireDashboard resource inside ContainerCreator.cs and normalizing legacy HostUrl references during dependency discovery.

In src/Aspire.Hosting/Dcp/ContainerCreator.cs, the container creation pipeline was modified to intercept the AspireDashboard entry within the hostDependencies list whenever EnableAspireContainerTunnel is active. Rather than passing the unfiltered HostResourceWithEndpoints entry directly to the tunnel provisioning logic, the code now invokes GetDashboardTunnelEndpointsAsync to compute an allowlisted subset of endpoints:

// File: src/Aspire.Hosting/Dcp/ContainerCreator.cs
if (_options.Value.EnableAspireContainerTunnel)
{
    var dashboardIndex = hostDependencies.FindIndex(dependency =>
        StringComparers.ResourceName.Equals(dependency.Resource.Name, KnownResourceNames.AspireDashboard));
    if (dashboardIndex >= 0)
    {
        // Telemetry must not implicitly expose the dashboard frontend. Preserve explicit endpoint
        // references without narrowing the endpoints exposed for ordinary host dependencies.
        var dashboard = hostDependencies[dashboardIndex];
        var endpoints = await GetDashboardTunnelEndpointsAsync(resource, dashboard, cancellationToken).ConfigureAwait(false);
        
        // Remove the unfiltered dashboard dependency entry
        hostDependencies.RemoveAll(dependency =>
            StringComparers.ResourceName.Equals(dependency.Resource.Name, KnownResourceNames.AspireDashboard));
        
        // Re-insert the dashboard dependency only with the filtered endpoints
        if (endpoints.Length > 0)
        {
            hostDependencies.Add(new HostResourceWithEndpoints(dashboard.Resource, endpoints));
        }
    }
}

The newly added helper method GetDashboardTunnelEndpointsAsync initializes a HashSet<string> containing only KnownEndpointNames.OtlpGrpcEndpointName and KnownEndpointNames.OtlpHttpEndpointName. It then inspects the target container resource's environment variables and command-line arguments using ExecutionConfigurationGathererContext to determine if the application developer explicitly referenced any additional dashboard endpoints (for instance, via WithReference()):

// File: src/Aspire.Hosting/Dcp/ContainerCreator.cs
private async Task<EndpointAnnotation[]> GetDashboardTunnelEndpointsAsync(
    IResource resource,
    HostResourceWithEndpoints dashboard,
    CancellationToken cancellationToken)
{
    var context = new ExecutionConfigurationGathererContext();
    var resourceLogger = _loggerService.GetLogger(resource);
    await new EnvironmentVariablesExecutionConfigurationGatherer()
        .GatherAsync(context, resource, resourceLogger, _executionContext, cancellationToken).ConfigureAwait(false);
    await new ArgumentsExecutionConfigurationGatherer()
        .GatherAsync(context, resource, resourceLogger, _executionContext, cancellationToken).ConfigureAwait(false);
 
    // Baseline allowlist restricted strictly to OTLP ingestion endpoints
    var endpointNames = new HashSet<string>(StringComparers.EndpointAnnotationName)
    {
        KnownEndpointNames.OtlpGrpcEndpointName,
        KnownEndpointNames.OtlpHttpEndpointName
    };
    
    var callerNetwork = resource.GetDefaultResourceNetwork();
    foreach (var endpoint in context.GetEndpointReferences(_model, callerNetwork))
    {
        // Only add non-OTLP dashboard endpoints if they were explicitly referenced by the resource
        if (StringComparers.ResourceName.Equals(endpoint.Resource.Name, dashboard.Resource.Name) &&
            (endpoint.ContextNetworkID ?? callerNetwork) == KnownNetworkIdentifiers.DefaultAspireContainerNetwork)
        {
            endpointNames.Add(endpoint.EndpointName);
        }
    }
 
    return dashboard.Endpoints.Where(endpoint => endpointNames.Contains(endpoint.Name)).ToArray();
}

To ensure that legacy raw URL strings (represented by the HostUrl struct) do not bypass this endpoint filtering or break legitimate explicit references, the patch also updates src/Aspire.Hosting/ApplicationModel/ResourceExtensions.cs and HostUrl.cs. The new GetEndpointReferences extension method parses HostUrl instances at the dependency-discovery boundary, extracts the local port via HostUrl.TryGetLocalHostPort, and maps it back to a strongly-typed EndpointReference within the DistributedApplicationModel:

// File: src/Aspire.Hosting/ApplicationModel/ResourceExtensions.cs
internal static IReadOnlyList<EndpointReference> GetEndpointReferences(
    this IExecutionConfigurationGathererContext context,
    DistributedApplicationModel model,
    NetworkIdentifier networkContext)
{
    var references = new List<EndpointReference>();
    foreach (var reference in context.GetReferences<object>())
    {
        if (reference is EndpointReference endpoint)
        {
            references.Add(endpoint);
        }
        else if (reference is HostUrl hostUrl &&
            HostUrl.TryGetLocalHostPort(hostUrl.Url, out var port) &&
            HostUrl.GetEndpointReference(model, port, networkContext) is { } legacyEndpoint)
        {
            references.Add(legacyEndpoint);
        }
    }
 
    return references;
}

> [!NOTE] > Assessment of Fix Completeness: The patch effectively neutralizes the implicit exposure of the dashboard frontend during telemetry auto-configuration while preserving backward compatibility for developers who intentionally pass a reference to a specific dashboard endpoint into a container. By performing the normalization of HostUrl objects prior to endpoint filtering, the fix prevents discrepancies between string-based URL configurations and strongly-typed EndpointReference objects.

Exploiting CVE-2026-120006 requires a specific set of operational prerequisites, which is reflected in the CVSS v3.1 High Attack Complexity (AC:H) and User Interaction Required (UI:R) metrics. First, a developer or administrator must execute a .NET Aspire application host (Aspire.Hosting.AppHost < 13.6.5) with the container tunneling option enabled (EnableAspireContainerTunnel = true). Second, the distributed application must include at least one containerized workload that has telemetry exporting enabled or otherwise holds a dependency on the AspireDashboard resource.

Once the application host initializes, the Developer Control Plane creates a virtual network bridge and spawns proxy listeners inside the container network namespace targeting all endpoints on the AspireDashboard resource. The container receives environment variables—such as OTEL_EXPORTER_OTLP_ENDPOINT—pointing to the tunnel gateway hostname (KnownHostNames.DefaultContainerTunnelHostName, typically host.docker.internal or an equivalent DCP proxy alias).

An attacker who achieves arbitrary code execution or command injection within the containerized workload (or an attacker who supplies a malicious third-party container image that a developer pulls and runs locally) can exploit the vulnerability through the following sequence:

1. Service Discovery: From inside the container, the attacker inspects environment variables to identify the DCP tunnel gateway hostname and performs a port scan or queries known dashboard port allocations against the tunnel interface.
2. Tunnel Traversal: The attacker establishes an HTTP/HTTPS connection from the container to the tunneled Aspire Dashboard frontend port.
3. Data Extraction and Privilege Escalation: Because the attacker is interacting directly with the administrative frontend and internal dashboard APIs over the local proxy tunnel, they can query structured logs, distributed traces (which frequently capture HTTP Authorization headers, session cookies, and internal API payloads), and resource environment variable configurations.

By harvesting database connection strings, cloud provider credentials, or host filesystem paths exposed in the dashboard UI, as well as invoking dashboard resource management operations, the attacker escapes the logical confines of the container and elevates privileges to the developer's host environment (S:C). As of publication, no automated proof-of-concept (PoC) scripts or weaponized exploits have been released publicly.

Microsoft assigned CVE-2026-120006 a CVSS v3.1 base score of 7.5 (High) with the vector string CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H. The Scope: Changed (S:C) metric is critical to understanding the severity of this flaw: while the vulnerable component is the .NET Aspire orchestration host and the entry point requires low privileges (PR:L) within a local or containerized context (AV:L), successful exploitation compromises resources beyond the container's security scope—specifically, sibling services and the underlying host workstation.

The impact across all three security pillars—Confidentiality (C:H), Integrity (I:H), and Availability (A:H)—is rated as High:

• Confidentiality (C:H): The .NET Aspire Dashboard acts as a centralized sink for all application telemetry, environment variables, and service launch configurations. Unauthorized access to its frontend allows an attacker to read all secrets, connection strings, and in-transit authentication tokens belonging to every service in the distributed application.
• Integrity (I:H): Using the harvested credentials or dashboard resource controls, an attacker can modify data in connected databases, alter application state across sibling containers, or manipulate host-bound services.
• Availability (A:H): The attacker can terminate orchestrated processes, exhaust host resources, or disrupt the Developer Control Plane.

From a threat intelligence perspective, the Exploit Prediction Scoring System (EPSS) has not registered active autonomous exploitation, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Because .NET Aspire's DCP and dashboard tunneling mechanisms are primarily utilized in local development and testing environments rather than internet-facing production deployments, the primary risk targets software developers and CI/CD build agents executing untrusted or compromised container dependencies.

To remediate CVE-2026-120006, organizations and developers must upgrade their .NET Aspire NuGet packages to version 13.6.5 or later. The fix is contained within the Aspire.Hosting assembly and should be applied across all AppHost projects in affected solutions.

Update the package references in your project file (.csproj) or centralized package management file (Directory.Packages.props) as follows:

<ItemGroup>
  <PackageReference Include="Aspire.Hosting.AppHost" Version="13.6.5" />
  <PackageReference Include="Aspire.Hosting" Version="13.6.5" />
</ItemGroup>

After updating the package references, run dotnet restore and rebuild the solution to ensure the patched Developer Control Plane (DCP) orchestration logic in ContainerCreator.cs is active.

> [!NOTE] > Workarounds and Compensating Controls: If an immediate upgrade to version 13.6.5 is not feasible, developers can mitigate the exposure by disabling automatic container tunneling in DcpOptions (EnableAspireContainerTunnel = false), provided that containerized services do not strictly rely on the DCP proxy tunnel to reach host-bound dependencies. Additionally, ensure that dashboard frontend authentication (such as browser token authentication) is enforced and avoid running untrusted third-party container images within privileged development environments.