Brief Summary: ASP.NET Core CVE-2026-114146 Incorrect Authorization Leading to Privilege Elevation

Introduction

According to Microsoft, a low-privileged ASP.NET Core user who can get a privileged user to open a specially crafted link can have an action executed with that privileged user's application authority. Microsoft rates CVE-2026-114146 at CVSS 9.0. The November 10, 2026 servicing release that fixes it touches every supported .NET branch from 8 through 11, two Visual Studio lines, and the standalone Microsoft.AspNetCore.Http.Connections NuGet package.

Technical information

Root cause: an authorization check performed incorrectly

The official description is short: "Incorrect authorization in ASP.NET Core allows an authorized attacker to elevate privileges over a network." The weakness is classified as CWE 863 (Incorrect Authorization), which MITRE defines as a product performing an authorization check for a resource or action but performing it incorrectly. The attacker is already identified to the application, so this is an authorization failure rather than an authentication bypass. The defect lies in how the server decides what an identified principal may do.

The patch information we reviewed attributes the following scenario to the MSRC FAQ: an authenticated attacker gets a privileged user to open a specially crafted link, and the action then runs with that user's application privileges. The fix therefore strengthens the server-side authorization check so that a request can no longer carry out work using the authority of whoever clicked the link.

During the briefing review the MSRC advisory page returned a 404, so the FAQ text itself was not directly available to us. The description above comes from the supplied patch information.

CVSS 3.1 vector

Microsoft's base vector is:

CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

Reading it field by field:

AV:N, AC:L: reachable over the network, with low attack complexity.
PR:L: the attacker needs a basic authenticated account, not zero privileges.
UI:R: a user must take an action. Per the MSRC FAQ, that action is opening a crafted link.
S:C: scope is Changed.
C:H, I:H, A:H: High impact on confidentiality, integrity, and availability.

Low complexity does not cancel the privilege and interaction requirements. They are independent conditions. The CVE record also carries the temporal fields E:U/RL:O/RC:C, which under the FIRST specification mean exploit code maturity Unproven, remediation level Official Fix, and report confidence Confirmed.

Attack flow

Based only on the published vector and the MSRC FAQ scenario:

The attacker holds a low-privileged, authenticated account in a vulnerable ASP.NET Core application (PR:L).
The attacker constructs a specially crafted link targeting the application.
The attacker induces a user who holds higher application privileges to open that link (UI:R).
Because the server-side authorization check is performed incorrectly, the resulting request executes with the privileged user's application authority rather than being rejected.

The public material does not identify the endpoint, request format, payload, required configuration, or the specific privilege gained, so we do not attempt to reconstruct them.

Where the fix likely lives (inference, not confirmed)

Most of the fix ships in the shared ASP.NET Core runtime (Microsoft.AspNetCore.App). Microsoft also released a separately fixed Microsoft.AspNetCore.Http.Connections 1.2.14. That package provides the HTTP connection layer used by SignalR, covering connection negotiation and transports. This suggests at least part of the authorization fix sits in the connection and negotiation code, not only in general MVC or Razor authorization. Microsoft has not published a root-cause write-up, so treat this strictly as an inference from the package list.

What is not public

The dotnet/core 10.0.15 release notes list this CVE only as a "TBD" placeholder, the usual dotnet/announcements issue has not been filled in, and no aspnetcore commit or diff has been tied to the CVE. Until Microsoft publishes those, the fixed version numbers are the only authoritative evidence of the patch.

Exploitation status

The retrieved CISA KEV feed (catalog version 2026.11.10) does not list CVE-2026-114146, and cve.now reports no tracked public exploit code. No threat actor, campaign, or indicators of compromise are associated with it. That absence is not proof that private exploitation has not occurred.

Patch information

Microsoft fixed CVE-2026-114146 on November 10, 2026, in its regular monthly (Patch Tuesday) .NET servicing release, rated Remediation Level: Official Fix. MSRC lists the following as first fixed builds, and NVD's affected ranges end at the same versions:

.NET 8.0 (Windows, Linux, macOS): fixed in 8.0.34, KB5135243
.NET 9.0 (Windows, Linux, macOS): fixed in 9.0.23, KB5135242
.NET 10.0 (Windows, Linux, macOS): fixed in 10.0.15 (SDK 10.0.404 / 10.0.115), KB5135241
.NET 11.0 (Windows, Linux, macOS): fixed in 11.0.0 GA, see release notes
Visual Studio 2022 v17.14: fixed in 17.14.45
Visual Studio 2026 v18.11: fixed in 18.11.4
Visual Studio 2026 v18.12: fixed build listed as 18.12.0
NuGet Microsoft.AspNetCore.Http.Connections: fixed in 1.2.14

Visual Studio appears because it bundles the .NET SDK and runtime. The 10.0.15 release notes state that SDK 10.0.404 ships in Visual Studio 18.11.4. Updating Visual Studio pulls in patched runtime bits rather than a separate code fix.

What a complete fix requires

Your deployment model determines what must change:

Framework-dependent apps pick up the fix when the host's ASP.NET Core shared runtime is updated (for example 10.0.15, or the Windows Hosting Bundle for IIS). Restart the app process afterward.
Self-contained apps and container images carry their own runtime copy. Rebuild against the patched runtime or a refreshed mcr.microsoft.com/dotnet base image, then redeploy. Updating the host does nothing for these.
Apps referencing Microsoft.AspNetCore.Http.Connections directly (the 1.x line) must move that reference to 1.2.14 and rebuild.

An upstream source cited 9.0.24 as the .NET 9 fix. That version belongs to CVE-2026-118747 (System.Formats.Cbor), fixed the same month. For CVE-2026-114146, MSRC and NVD both name 9.0.23.

No CVE-specific workaround or compensating control has been documented.

Affected systems and versions

.NET 8.0 on Linux, macOS, and Windows: 8.0.0 up to but not including 8.0.34
.NET 9.0 on Linux, macOS, and Windows: 9.0.0 up to but not including 9.0.23
.NET 10.0 on Linux, macOS, and Windows: 10.0.0 up to but not including 10.0.15
.NET 11.0 on Linux, macOS, and Windows: from the first preview (11.0.0 preview.1) up to but not including the 11.0.0 GA release
Visual Studio 2022 version 17.14: 17.14.0 up to but not including 17.14.45
Visual Studio 2026 version 18.11: 18.11.0 up to but not including 18.11.4
Visual Studio 2026 version 18.12: NVD displays the internally inconsistent range "18.12.0 < 18.12.0", while MSRC lists 18.12.0 as the fixed build. Confirm your build against Microsoft's release notes.
Microsoft.AspNetCore.Http.Connections NuGet package: 1.2.0 up to but not including 1.2.14

Self-contained deployments and container images built on any of the vulnerable runtimes remain affected until rebuilt, regardless of the host runtime version.

Vendor security history

Microsoft is both the vendor and the CNA for this CVE. The most relevant independent assessment of its security practices is the Cyber Safety Review Board report released April 2, 2024. The Board found that the Summer 2023 Exchange Online intrusion, attributed to the actor Microsoft tracks as Storm 0558 and assessed as affiliated with the People's Republic of China, was preventable. It criticized operational and strategic decisions pointing to a culture that deprioritized enterprise security investment and rigorous risk management, while noting that Microsoft fully cooperated.

Microsoft's July 2026 Secure Future Initiative progress report describes efforts to embed security across culture, governance, and engineering. Those are vendor-reported improvements. Neither the CSRB findings nor the SFI report have any connection to an exploitation campaign involving CVE-2026-114146, and the Storm 0558 attribution should not be transferred to it.

CVE Analysis

Experimental AI-Generated Content

Introduction

Technical information