CVE-2026-118740: Missing Authorization in Microsoft Aspire Dashboard Blazor Router

The Microsoft Aspire Dashboard is an ASP.NET Core Blazor Interactive Server application designed to provide real-time observability, resource management, and telemetry inspection (including structured logs, distributed traces, and metrics) for distributed cloud-native applications. Because the dashboard exposes sensitive operational data and management controls—such as resource lifecycle actions and interactive console terminals—it supports frontend authentication mechanisms, notably FrontendAuthMode.BrowserToken and FrontendAuthMode.OpenIdConnect, to restrict access to authorized operators.

In Aspire Dashboard versions 13.6.1 through 13.6.4, the frontend routing architecture fails to enforce authentication policies on unmapped routes. Specifically, src/Aspire.Dashboard/Components/Routes.razor relies on Blazor's standard <Router> component, which splits request handling into two execution branches: <Found> for registered application routes and <NotFound> for unrecognized URL paths. While the <Found> branch wraps matched pages in an <AuthorizeRouteView> component to enforce authorization policies, the <NotFound> branch omits authorization checks entirely.

When an unauthenticated user requests an arbitrary, non-existent path (for example, /this-page-does-not-exist), the Blazor router executes the <NotFound> template and unconditionally renders <LayoutView Layout="@typeof(Layout.MainLayout)">. Furthermore, the <Found> branch configures <AuthorizeRouteView> with DefaultLayout="@typeof(Layout.MainLayout)", which causes Blazor to render the protected MainLayout shell even when access to a matched route is denied.

This Missing Authorization vulnerability (CWE-862) allows unauthenticated network attackers to bypass frontend access controls and instantiate the core dashboard layout. Once MainLayout is initialized over an interactive Blazor Server circuit, downstream child components—including DashboardDialogProvider, InteractionsProvider, navigation menus, and session storage bindings—execute their initialization lifecycles (OnInitializedAsync) without verifying the caller's authentication state.

The root cause of CVE-2026-118740 lies in how ASP.NET Core Blazor handles layout rendering across router states when authentication is enforced solely at the route-view level rather than the router envelope or layout initialization level. In Blazor applications, <AuthorizeRouteView> evaluates the authorization requirements of a target page component discovered via route matching. However, <AuthorizeRouteView> only operates within the <Found> template of the <Router> component because it requires a valid RouteData object to inspect page-level [Authorize] attributes.

In the vulnerable implementation of Routes.razor, the <NotFound> template uses a standard <LayoutView> component pointing directly to typeof(Layout.MainLayout). Because <LayoutView> does not interact with ASP.NET Core's AuthenticationStateProvider or policy evaluation pipeline, it immediately constructs the specified layout component tree and renders its child content (<Aspire.Dashboard.Components.Pages.NotFound />).

A secondary architectural flaw compounds this issue within the <Found> branch itself. When <AuthorizeRouteView> evaluates a valid route for an unauthenticated user and determines that authorization fails, it renders its <NotAuthorized> template inside the layout specified by the DefaultLayout parameter. Because DefaultLayout was set to typeof(Layout.MainLayout), denied requests to valid pages still instantiated MainLayout rather than falling back to an unprivileged layout or terminating the view.

Furthermore, the global infrastructure components hosted inside MainLayout—specifically MainLayout.razor.cs, WindowLayout.razor.cs, DashboardDialogProvider.cs, and InteractionsProvider.cs—assumed that the routing layer had already validated the user's session prior to component construction. None of these components performed defensive checks against the cascading Task<AuthenticationState> during their OnInitializedAsync lifecycle methods. Consequently, rendering MainLayout through either the <NotFound> bypass or the <AuthorizeRouteView> denied fallback triggered full initialization of backend interactive services and event listeners for unauthenticated clients.

In versions prior to 13.6.5, src/Aspire.Dashboard/Components/Routes.razor defined the routing structure without policy wrappers around the layout views. The vulnerable code path is shown below:

<CascadingValue Value="@_viewportInformation">
    <Router AppAssembly="@typeof(App).Assembly">
        <Found Context="routeData">
            <!-- AuthorizeRouteView protects pages from being accessed when authorization is required -->
            <AuthorizeRouteView RouteData="@routeData" DefaultLayout="@typeof(Layout.MainLayout)" />
        </Found>
        <NotFound>
            <PageTitle>@Loc[nameof(Resources.Routes.NotFoundPageTitle)]</PageTitle>
            <!-- VULNERABILITY: LayoutView renders MainLayout without evaluating authentication state -->
            <LayoutView Layout="@typeof(Layout.MainLayout)">
                <Aspire.Dashboard.Components.Pages.NotFound />
            </LayoutView>
        </NotFound>
    </Router>
</CascadingValue>

In commit 0b6bfe2f538d4eed8a9ae7e11651c09dbbe886b8 (PR 66656), Microsoft remediated the flaw through a multi-layered approach. First, Routes.razor was restructured to wrap both <Found> and <NotFound> branches inside <AuthorizeView Policy="@FrontendAuthorizationDefaults.PolicyName">. This ensures that MainLayout is only accessible within the <Authorized> block, while unauthenticated requests are routed to <Layout.EmptyLayout> and handled by a dedicated <DashboardNotAuthorized /> component:

<CascadingValue Value="@_viewportInformation">
    <Router AppAssembly="@typeof(App).Assembly">
        <Found Context="routeData">
            <!-- AuthorizeRouteView also uses DefaultLayout for denied authorization.
                 Only allow the protected default layout after the frontend policy succeeds. -->
            <AuthorizeView Policy="@FrontendAuthorizationDefaults.PolicyName" Context="routeAuthenticationState">
                <Authorized>
                    <AuthorizeRouteView RouteData="@routeData" DefaultLayout="@typeof(Layout.MainLayout)" />
                </Authorized>
                <NotAuthorized>
                    <AuthorizeRouteView RouteData="@routeData" DefaultLayout="@typeof(Layout.EmptyLayout)">
                        <NotAuthorized>
                            <DashboardNotAuthorized />
                        </NotAuthorized>
                    </AuthorizeRouteView>
                </NotAuthorized>
            </AuthorizeView>
        </Found>
        <NotFound>
            <!-- Missing routes bypass AuthorizeRouteView, so enforce authorization before rendering the main layout. -->
            <AuthorizeView Policy="@FrontendAuthorizationDefaults.PolicyName">
                <Authorized>
                    <PageTitle>@Loc[nameof(Resources.Routes.NotFoundPageTitle)]</PageTitle>
                    <LayoutView Layout="@typeof(Layout.MainLayout)">
                        <Aspire.Dashboard.Components.Pages.NotFound />
                    </LayoutView>
                </Authorized>
                <NotAuthorized>
                    <DashboardNotAuthorized />
                </NotAuthorized>
            </AuthorizeView>
        </NotFound>
    </Router>
</CascadingValue>

Second, the patch introduced DashboardNotAuthorized.razor.cs to handle unauthenticated sessions consistently. When operating in FrontendAuthMode.BrowserToken, this component captures the requested URI path, query, and fragment, constructs a safe returnUrl parameter, and forces a client navigation to the login endpoint (DashboardUrls.LoginBasePath):

if (DashboardOptions.Value.Frontend.AuthMode == FrontendAuthMode.BrowserToken)
{
    var currentUri = NavigationManager.ToAbsoluteUri(NavigationManager.Uri);
    var returnUrl = currentUri.PathAndQuery + currentUri.Fragment;
    var loginUri = NavigationManager.ToAbsoluteUri(DashboardUrls.LoginBasePath);
    var loginUrl = QueryHelpers.AddQueryString(loginUri.AbsoluteUri, "returnUrl", returnUrl);
 
    NavigationManager.NavigateTo(loginUrl, new NavigationOptions { ReplaceHistoryEntry = true });
}

Third, to provide defense-in-depth against future routing misconfigurations, the patch added DashboardAuthenticationState.cs. This static helper enforces authentication checks directly inside the OnInitializedAsync methods of MainLayout, WindowLayout, DashboardDialogProvider, and InteractionsProvider, throwing an InvalidOperationException if an unauthenticated user attempts to initialize these components when authentication is enabled:

internal static class DashboardAuthenticationState
{
    public static async Task EnsureAuthenticatedAsync(
        DashboardOptions dashboardOptions,
        Task<AuthenticationState>? authenticationState)
    {
        if (dashboardOptions.Frontend.AuthMode is FrontendAuthMode.Unsecured or null)
        {
            return;
        }
 
        if (authenticationState is null || (await authenticationState.ConfigureAwait(false)).User.Identity?.IsAuthenticated is not true)
        {
            throw new InvalidOperationException("Dashboard authentication is required, but the current user is not authenticated.");
        }
    }
}

Finally, in an auxiliary hardening commit (f017f668fd6e0938e23058dc0450a1403f409809, PR 68055), ContainerCreator.cs was updated to restrict the Aspire container-to-host tunnel strictly to OpenTelemetry Protocol (OTLP) endpoints (OtlpGrpcEndpointName and OtlpHttpEndpointName). This prevents containerized workloads from leveraging internal telemetry tunnels to reach the dashboard's frontend ports. Together, the router restructuring and component-level state assertions provide a complete fix that prevents variant bypasses across both static rendering and interactive Blazor navigation.

Exploiting CVE-2026-118740 requires network access to the Aspire Dashboard HTTP/HTTPS frontend interface when the dashboard is configured with authentication enabled (FrontendAuthMode.BrowserToken or FrontendAuthMode.OpenIdConnect). No authentication credentials, privileges, or user interaction are required to trigger the vulnerability.

An attacker can trigger the bypass through two primary vectors: direct HTTP navigation or client-side Blazor router manipulation. In the direct navigation scenario, the attacker sends an HTTP GET request or directs a browser to any URI path that does not map to a defined @page directive in the Aspire.Dashboard assembly (for example, https://<target-dashboard>/nonexistent-path). Instead of halting execution or redirecting to /login, the server responds by rendering the <NotFound> block wrapped in MainLayout and establishing an interactive SignalR WebSocket circuit (/_blazor?id=...).

Alternatively, as demonstrated in the official Playwright regression test (BrowserTokenAuthenticationTests.cs) included in the patch commit, an attacker sitting on the unauthenticated /login page can invoke Blazor's client-side JavaScript interop directly from the browser console to transition the active circuit into the vulnerable state:

// Executed from an unauthenticated session on the /login page
Blazor.navigateTo('/this-page-does-not-exist');

When Blazor.navigateTo is called with an unmapped route in vulnerable versions (13.6.1 to 13.6.4), the client-side router communicates over the existing Blazor SignalR connection to request the target view. The server processes the route transition within the active circuit, enters the <NotFound> branch in Routes.razor, and instantiates MainLayout along with its child providers (InteractionsProvider and DashboardDialogProvider) on the server, returning the rendered DOM diffs for the dashboard chrome directly to the unauthenticated client.

Microsoft and NVD assigned CVE-2026-118740 a CVSS v3.1 base score of 9.1 (Critical) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. The attack complexity is low (AC:L) and requires no privileges (PR:N) or user interaction (UI:N) over a network vector (AV:N).

The high confidentiality (C:H) and integrity (I:H) ratings reflect the consequences of allowing unauthenticated actors to initialize MainLayout and establish authenticated-equivalent component lifecycles within an interactive Blazor Server circuit. In Blazor Interactive Server architectures, component instances reside in server memory and interact directly with dependency-injected backend services. When MainLayout, DashboardDialogProvider, and InteractionsProvider initialize without authentication validation, they bind event listeners, subscribe to internal state notification channels, and expose interactive UI handlers over the WebSocket connection.

> [!NOTE] > As of November 2026, CVE-2026-118740 is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no standalone weaponized exploits have been published on ExploitDB or GitHub. The FIRST.org EPSS score is 0.00923 (60.87th percentile).

If the Aspire Dashboard is exposed to untrusted networks—or reachable from adjacent container networks prior to the PR 68055 tunnel restrictions—an unauthenticated attacker can interact with global dashboard providers, read exposed layout state and metadata, and invoke interactive handlers that assume the caller has passed frontend policy verification.

To remediate CVE-2026-118740, operators and developers must upgrade Microsoft Aspire Dashboard installations and SDK dependencies to version 13.6.5 or later. Version 13.6.5 incorporates both the Routes.razor policy enforcement and the DashboardAuthenticationState.EnsureAuthenticatedAsync lifecycle guards.

For projects referencing the Aspire Dashboard SDK package directly, update the package reference in the project file (.csproj) or Directory.Packages.props to version 13.6.5:

<ItemGroup>
  <PackageReference Update="Aspire.Dashboard.Sdk.linux-x64" Version="13.6.5" />
</ItemGroup>

If immediate upgrading is not feasible, security teams should implement network-level access controls to prevent unauthenticated requests from reaching the Aspire Dashboard application layer:

1. Enforce Reverse Proxy Authentication: Deploy the Aspire Dashboard behind an authenticating reverse proxy or ingress controller (such as NGINX, YARP, or Azure Application Gateway) configured to require OAuth2/OIDC or mutual TLS (mTLS) authentication for all URI paths before forwarding traffic to the backend Blazor server.
2. Restrict Network Binding: Configure the Aspire Dashboard frontend endpoints to bind exclusively to loopback interfaces (127.0.0.1 / localhost) during local development, or restrict access via firewall rules to trusted management subnets and VPNs in staging and production environments.
3. Monitor Blazor Circuit Negotiations: Audit web server and reverse proxy access logs for HTTP requests targeting non-existent paths that do not result in a 302 Found redirect to /login, particularly when followed by WebSocket upgrade requests to /_blazor.