Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privileged user
-
DeliveryTrigger rapid navigation or auth-state change
-
ExploitWin race applying stale async authorization result
-
ExecutionBypass current [Authorize] decision
-
ImpactAccess unauthorized protected Blazor component
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Concurrency control, locking
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires a Blazor application that uses the Microsoft.AspNetCore.Components.Authorization AuthorizeRouteView component to enforce [Authorize] on routes; apps not using Blazor component-level authorization are unaffected. The attacker must already be an authenticated user (PR:L) and must induce a navigation or authorization-state change at the right moment so a stale asynchronous authorization result is applied to the new authorization decision. Limiting factors: High attack complexity (AC:H) because the outcome depends on winning a non-deterministic timing race, prior valid authentication is required (not unauthenticated), and only the specific Blazor authorization-routing feature is in scope rather than all ASP.NET Core deployments. No end-user interaction beyond the attacker's own actions is needed (UI:N). |
| Impact | Signals are mixed and point to a credible-but-not-urgent issue. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N) describes a network-reachable flaw requiring an already-authenticated low-privileged user (PR:L) and carries High attack complexity (AC:H), which is consistent with a timing-dependent race condition (CWE-362) that cannot be triggered deterministically. CISA's SSVC framework reinforces low urgency: Exploitation=none (no observed active exploitation), Automatable=no (cannot be reliably mass-exploited), though Technical Impact=total, matching the C:H/I:H/A:H impact. Public POC/exploit code exists (a GitHub gist), but this is distinct from active exploitation - there is no CISA KEV listing and SSVC explicitly records no observed exploitation. Net assessment: this is a legitimate 7.5/High authorization-bypass bug in a very widely used framework, but the AC:H race condition and PR:L precondition make opportunistic mass exploitation unlikely; prioritize patching for internet-facing Blazor applications handling sensitive authorization boundaries, but it is not a drop-everything emergency. Note a minor framing tension worth verifying: the input Tags label this 'Information Disclosure,' while the authoritative GHSA advisory describes it as a Security Feature Bypass / authorization bypass and the CVE description frames it as privilege elevation - treat it primarily as an authorization bypass with full confidentiality/integrity/availability impact. |
| Exploit ScenarioDerived | An authenticated low-privileged user of a Blazor server/WebAssembly application that relies on AuthorizeRouteView rapidly navigates or forces an authorization-state change so that a stale asynchronous authorization result from a prior state is applied to the new route, bypassing the current [Authorize] decision and rendering a protected component they should not reach. Because this is a race condition (AC:H), the attacker may need many timed attempts to win the race. Public exploit code exists in a referenced GitHub gist, lowering the research barrier, though no active in-the-wild exploitation has been reported. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 14, 2026
Privilege escalation and security-feature bypass in Microsoft ASP.NET Core's Blazor authorization stack lets an authenticated remote user defeat an application's [Authorize] decision and reach content or operations their role should not permit. The flaw is a race condition in the Microsoft.AspNetCore.Components.Authorization AuthorizeRouteView component, where a stale asynchronous authorization result can be applied after a navigation or an authorization-state change, so the current authorization decision is silently overwritten by an earlier one. Only Blazor applications that use AuthorizeRouteView for route-level authorization are in scope; ASP.NET Core deployments that do not use Blazor component-level authorization are unaffected. Exploitation is non-deterministic (CVSS AC:H) and requires the attacker to already hold a valid authenticated session (PR:L), and publicly available exploit code exists as a published proof-of-concept gist, but CISA SSVC rates exploitation as none and the issue is not automatable. Vendor patches are available across all supported ASP.NET Core release trains.
RemediationAI
Vendor-released patches: update ASP.NET Core to 8.0.32, 9.0.21, 10.0.13 or 11.0.0-rc.2 depending on the train you run, and update the corresponding Microsoft.AspNetCore.App.Runtime.* shared-framework packages to the same fixed versions; Visual Studio users should move to 2022 17.14.42 or 2026 18.10.4 (or later) because the affected runtime is bundled with the IDE. Confirm the fix by verifying the installed runtime patch level (for example via dotnet --list-runtimes and your NuGet lock file) rather than assuming an SDK update covered the shared framework. If immediate patching is not possible, the most effective compensating control is to stop relying solely on AuthorizeRouteView for access decisions: re-validate authorization on the server for every protected operation or resource (API endpoints, data queries) so that a stale client-side render cannot yield real unauthorized access - this is a defense-in-depth change and does not eliminate the rendering bypass, but it removes the confidentiality and integrity impact. Where the application can tolerate it, avoid triggering authorization state changes (login/logout, role refresh) during in-flight navigation, or harden the flow by forcing an explicit re-evaluation of authorization after any navigation event; this reduces race likelihood but is timing-dependent and should not be treated as a fix. Note that authentication is already required to exploit this (PR:L) and exploitation is not automatable per CISA's SSVC evaluation, so exploit attempts are limited to already-authenticated parties. Advisory references for tracking and patch guidance: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-70183, https://github.com/dotnet/aspnetcore/security/advisories/GHSA-494h-xx7x-5frh, https://github.com/dotnet/announcements/issues/460 and https://github.com/dotnet/aspnetcore/discussions/69796.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 18 packages in nuget, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The CWE-362 root cause is a concurrency defect in Blazor's route-level authorization component, Microsoft.AspNetCore.Components.Authorization's AuthorizeRouteView. Blazor evaluates authorization asynchronously as the user navigates; when a navigation or an authentication/authorization state change occurs while an earlier authorization task is still in flight, the completed (stale) result can be committed after the newer authorization context has already been established. Because the rendered decision is derived from that late-arriving task rather than from the current user's claims, the component may render content that the present [Authorize] policy should have denied - effectively a security feature bypass (Microsoft's advisory title) with confidentiality and integrity impact scored High, plus availability High. The affected code ships as part of the shared framework/runtime rather than as a standalone library, which is why the advisory enumerates runtime packages such as Microsoft.AspNetCore.App.Runtime.linux-x64, linux-arm, linux-arm64, linux-musl-arm, linux-musl-arm64, linux-musl-x64, osx-arm64, osx-x64 and win-arm, each vulnerable at >= 8.0.0, <= 8.0.31 and fixed in 8.0.32. Equivalent trains are Microsoft.AspNetCore.App.Runtime in 9.0 (<9.0.21), 10.0 (<10.0.13) and 11.0 (<11.0.0-rc.2), and the same shared framework is bundled with Visual Studio tooling (2022 17.14 before 17.14.42 and 2026 18.10 before 18.10.4). The vulnerability is a logic/timing bug rather than memory corruption, so exploitation does not require malformed payloads - only the ability to trigger navigation or an authorization-state change at a favorable moment.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Network-reachable (AV:N) but a timing-dependent race gives AC:H; attacker must be an authenticated user so PR:L, and winning the race fully bypasses authorization yielding C:H/I:H/A:H.
Primary rating from Vendor (microsoft).
CVSS VectorVendor: microsoft
Lifecycle Timeline
2DescriptionCVE.org
Concurrent execution using shared resource with improper synchronization ('race condition') in ASP.NET Core allows an authorized attacker to elevate privileges over a network.
Technical POC Analysis
Evidence supplied: the GitHub advisory GHSA-494h-xx7x-5frh (vendor text), and an auto-generated gist (alon710/d53a578a0f8f19f39ff618766fb7fe70) that is a CVE report template, not exploit code.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Latest POC
1 public PoC link from github
Sign in to open the public PoC links collected for this CVE.
Executive ViewAI
A high-severity authorization weakness in Microsoft ASP.NET Core's Blazor component framework could allow a signed-in user of an affected application to reach pages and operations their assigned role should not permit, quietly undermining the role-based access controls that protect internal and customer-facing Blazor apps. Only Blazor deployments that rely on the AuthorizeRouteView component for route-level authorization are exposed; other ASP.NET Core workloads are unaffected. Because exploitation requires an already-valid authenticated session and produces intermittent results, leadership should treat this as an account-compromise and insider-risk problem rather than a broad internet-wide threat.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Race conditions occur when multiple concurrent requests exploit the brief time gap between checking a condition and acting upon it (TOCTOU - Time of Check, Time of Use).
EUVD-2026-99698
GHSA-494h-xx7x-5frh
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB