CVE-2026-118740: .NET Aspire Dashboard NotFound Route Deletes Telemetry Without Auth

Microsoft published CVE-2026-118740 and GHSA-4g86-54fm-h9h8 for the .NET Aspire Dashboard: an unauthenticated NotFound route can delete telemetry and, in some auth modes, leak a browser token. Every dashboard release through 13.6.4 is affected. 13.6.5 is the patched floor, and neither 13.6.3 nor 13.6.4 is a safe stopping point on the upgrade path.

Aspire is Microsoft's orchestration stack for local and cloud-native .NET microservices. Teams wire AppHost projects so dependencies, connection strings, and the Aspire Dashboard UI come up together—often on developer laptops and CI agents that also run Claude Code, Codex, or Cursor against the same repo. The flaw is not in your application code; it sits in dashboard authorization, where a route Microsoft classifies as NotFound still performed state-changing telemetry operations without checking identity.

TL;DR

What Microsoft disclosed

GitHub advisory GHSA-4g86-54fm-h9h8, reviewed November 12, 2026, mirrors Microsoft's bulletin in dotnet/announcements#526 (opened November 11, 2026). Microsoft credits Weeraphat Srisutham and points technical discussion to microsoft/aspire#22148.

The executive summary, in substance:

Aspire Dashboard's unauthenticated NotFound route can permit telemetry deletion in both standalone and AppHost-hosted deployments. In standalone deployments using browser-token authentication, it can also expose the browser token.

Weakness CWE-862 (Missing Authorization) matches the mechanism: the dashboard treated certain NotFound handling as reachable without an authorization check while still performing integrity- and confidentiality-relevant work.

CVSS 3.1 base score 9.1 (Critical) with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N signals unauthenticated network attack, high confidentiality and integrity impact, and no availability pillar in the scored vector. MSRC's update guide entry carries the same CVE identifier for enterprise patch trackers.

Revision V1.0 (November 10, 2026) on the advisory notes the bulletin shipped ahead of GitHub's reviewed publication on November 12—teams may have seen MSRC or dotnet announcements before the GHSA row appeared in automated feeds.

If you triage CVEs from agent-generated pull requests, treat Aspire.Dashboard.Sdk like any other critical dependency: diff manifests for image tag downgrades and SDK pins stuck on 13.6.4.

Affected packages (from the advisory FAQ tables)

Microsoft explicitly warns: both 13.6.3 and 13.6.4 contain the vulnerable NotFound route. If your change log shows a recent "security patch" hop to 13.6.4, you are still vulnerable until 13.6.5.

Attack chain step by step

Microsoft does not publish proof-of-concept code in the advisory. From the described missing authorization on a NotFound route, defenders should assume the following logical chain:

1. Reconnaissance — An attacker locates an Aspire Dashboard HTTP endpoint. That endpoint often appears on developer LANs, shared CI agents, or misbound 0.0.0.0 ports when someone toggles dashboard access for convenience.

2. Unauthenticated access to NotFound handling — The attacker issues requests that hit the dashboard's NotFound path (exact URL shape depends on dashboard routing; Microsoft names the route class, not every alias).

3. Telemetry deletion — Because authorization is missing, the handler can delete telemetry the dashboard stores for standalone and AppHost-hosted deployments. Impact is integrity and auditability: traces, resource events, or health timelines you expected to retain may disappear.

4. Optional browser-token disclosure — In standalone deployments that use browser-token authentication, the same route can expose the browser token, crossing into confidentiality impact. An attacker who obtains that token may inherit whatever session rights the dashboard granted the browser.

5. Follow-on agent or operator confusion — On machines where coding agents restart Aspire stacks, missing telemetry can look like "the service never failed" during an incident, or like flakiness in automated health checks—similar to how teams misread other unauthenticated admin surfaces on developer boxes.

This is not prompt injection and not an MCP skill issue. It is classic missing auth on an admin-adjacent observability UI—the same class of bug that makes unauthenticated RSC endpoints and OpenAPI-driven codegen RCE urgent on paths developers actually run locally.

How to check whether you are affected

Microsoft's FAQ lists several deployment shapes. Work through every path that applies—AppHost users often have three dashboard sources (SDK packages, CLI bundle, container tag).

AppHost with Dashboard SDK packages

From your AppHost project directory:

dotnet list package --include-transitive | grep -i Aspire.Dashboard.Sdk

Compare resolved versions to 13.6.5. If the AppHost pins Aspire.Hosting.AppHost or Aspire.AppHost.Sdk centrally, ensure those references are 13.6.5 or later, then restore, rebuild, and restart the AppHost so it launches the updated dashboard binaries.

CLI-bundled or custom dashboard paths

If the AppHost selects a CLI-bundled Dashboard or a custom Dashboard path, Microsoft says updating NuGet references alone does not replace that bundle. Open the bundle or custom install location and read its version string, then upgrade that artifact to 13.6.5+ and restart.

Container and Compose manifests

Search manifests for mcr.microsoft.com/aspire/dashboard (or nightly equivalents agents may have added):

grep -R "aspire/dashboard" .

Set the image to mcr.microsoft.com/aspire/dashboard:13.6.5, recreate containers, and replace nightly tags in generated Docker Compose or Kubernetes files. Microsoft warns explicitly: bumping AppHost packages without rewriting manifest image tags leaves the old dashboard running.

Standalone dashboard installs

Any standalone Aspire Dashboard release through 13.6.4 needs 13.6.5+. Browser-token mode needs patching before exposing the port beyond localhost.

How to fix and verify

1. Upgrade dashboard bits to 13.6.5 or later using the path that matches your deployment (NuGet SDK, container image, or CLI bundle).

2. Restart AppHost or standalone processes so the new dashboard binary is what listens on the port.

3. Re-verify resolved Aspire.Dashboard.Sdk versions and container digests in CI—the same week Microsoft disclosed large kernel bug batches, agent-driven repos often pick up Aspire template bumps without pinning dashboard images.

4. Restrict network exposure until verified: bind dashboard ports to localhost or place them behind VPN/zero-trust, especially on laptops that also hold cloud credentials for agent tooling.

5. Assume telemetry gaps if the dashboard was internet-exposed: deletion is integrity impact. Cross-check logs from application sinks (structured logging, APM agents) rather than trusting dashboard history alone.

Microsoft does not document in-the-wild exploitation in the advisory. EPSS on the GitHub page was modest at publication time, but CVSS 9.1 with PR:N still warrants same-day dashboard upgrades on shared networks.

What this means if you run AI coding agents

Coding agents increasingly scaffold Aspire AppHosts, edit Compose files, and restart local observability stacks while implementing features. That workflow matters for three reasons:

• Agents may pin vulnerable images when they "fix" build errors by freezing tags. Treat mcr.microsoft.com/aspire/dashboard:13.6.5 as the minimum stable tag after patch, and review agent diffs like any other supply-chain change—parallel to dependency CVE triage when agents add packages.

• Telemetry deletion attacks audit trails, not model weights. If your security story for agents is "we'll reconstruct from Aspire traces," this CVE breaks that assumption for unpatched dashboards. Keep independent evidence: git history, CI logs, and local agent action collectors that do not depend on Aspire's UI database.

• Browser-token leakage pairs badly with shared dev machines. A token grab on a laptop that also runs Codex or Claude Code can compound session theft beyond the dashboard itself. Patch first, then rotate tokens if exposure is plausible.

None of this replaces patching 13.6.5; it explains why agent-heavy teams should not downgrade this to "just a local UI bug."

What Beam can and cannot do here

Beam is local observability and policy for supported coding agents: it records tool and hook events, heuristically scans skills and MCP configs, and can deny matched PreToolUse patterns on Claude Code and Codex when enforce policy is cached. It does not patch Aspire, terminate dashboard HTTP handlers, or validate .NET authorization attributes.

Where Beam still helps on Aspire-heavy laptops:

• Independent action log — If dashboard telemetry vanishes, Beam's on-device event store may still show what the agent changed (file edits, package bumps, compose rewrites) when you had the collector running. Retention caps apply; see how Beam watches agents.

• Skill and MCP scanning — Agents that add shell installers or remote MCP endpoints while "fixing" Aspire get the same 11-pattern heuristic scan as any other session—not a fix for CVE-2026-118740, but a hedge against chained supply-chain moves.

Beam is not a network firewall for dashboard ports and fail-opens when cached policy is missing. Patch Aspire; use Beam as a secondary record of agent behavior.

Frequently asked questions

What is CVE-2026-118740?

It is a missing-authorization flaw (CWE-862) in the .NET Aspire Dashboard before version 13.6.5. Microsoft says an unauthenticated NotFound route can permit telemetry deletion in standalone and AppHost-hosted deployments, and in standalone browser-token authentication setups it can also expose the browser token.

Which Aspire versions are vulnerable?

The GitHub advisory lists Aspire Dashboard releases through 13.6.4 as affected, including standalone dashboard packages and every platform-specific Aspire.Dashboard.Sdk package below 13.6.5. Microsoft notes that both 13.6.3 and 13.6.4 still contain the vulnerable NotFound route.

Does updating the .NET SDK fix the dashboard?

No. Microsoft states that Aspire ships independently of .NET; installing a .NET runtime or SDK update does not replace the Dashboard. You must update the dashboard package, SDK reference, container image, or CLI-bundled dashboard path to 13.6.5 or later.

How do I patch container deployments?

Set the dashboard image explicitly to mcr.microsoft.com/aspire/dashboard:13.6.5, recreate or redeploy the container, and replace older version tags or nightly image references in Docker Compose or Kubernetes manifests. Updating AppHost NuGet references alone does not rewrite an existing manifest image tag.

What CVSS score did Microsoft assign?

The advisory lists CVSS 3.1 version 9.1 Critical with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. GitHub EPSS on the advisory page was about 0.923% at publication time.

What should AI coding agent users do on laptops running Aspire?

Check which dashboard your AppHost launches, upgrade to 13.6.5+, and avoid exposing the dashboard port beyond localhost until patched. Treat agent-generated Compose or Kubernetes edits as untrusted for image pins, and keep local action logging separate from Aspire telemetry you rely on for audits.

Related reading

• React CVE-2026-126187: unauthenticated RSC remote code execution
• FastAPI code generator CVE-2026-63470 from OpenAPI summaries
• Check dependencies for known CVEs in CI with Beam
• CVE volume in 2026: triage for agent users
• N-able hotfix after developer-machine exposure patterns
• Microsoft Forge: kernel bug volume for developer machines

Primary sources: GHSA-4g86-54fm-h9h8 · dotnet/announcements#526 · MSRC CVE-2026-118740 · NVD CVE-2026-118740 · Aspire release v13.6.5

Advisory text, version tables, and CVSS vectors reflect Microsoft and GitHub publications as of November 12, 2026. Confirm resolved package versions and container tags on each host before closing remediation.