ASP.NET Core Elevation of Privilege Vulnerability
Only affects Linux .NET tarball installs (source-build and ASP.NET Core) that an administrator extracted, since the tarballs ship with root ownership metadata. Fixed in 8.0.33, 9.0.22 and 10.0.14.
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 10.0.403, 11.0.100-rc.3, 8.0.427, 9.0.320, 10.0.403-servicing.26523.112, and 1 more
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 1 proof of concept on GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
Incorrect default permissions in ASP.NET Core allows an authorized attacker to elevate privileges locally.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- Microsoft .NET 10.0 installed on Linux
From 10.0.0 · fixed in 10.0.403
- Microsoft .NET 10.0 installed on Mac OS
From 10.0.0 · fixed in 10.0.403
- Microsoft .NET 10.0 installed on Windows
From 10.0.0 · fixed in 10.0.403
- Microsoft .NET 11.0 installed on Linux
From 11.0.0-preview.1 · fixed in 11.0.100-rc.3
- Microsoft .NET 11.0 installed on Mac OS
From 11.0.0-preview.1 · fixed in 11.0.100-rc.3
- Microsoft .NET 11.0 installed on Windows
From 11.0.0-preview.1 · fixed in 11.0.100-rc.3
- Microsoft .NET 8.0 installed on Linux
From 8.0.0 · fixed in 8.0.427
- Microsoft .NET 8.0 installed on Mac OS
From 8.0.0 · fixed in 8.0.427
- Microsoft .NET 8.0 installed on Windows
From 8.0.0 · fixed in 8.0.427
- Microsoft .NET 9.0 installed on Linux
From 9.0.0 · fixed in 9.0.320
- Microsoft .NET 9.0 installed on Mac OS
From 9.0.0 · fixed in 9.0.320
- Microsoft .NET 9.0 installed on Windows
From 9.0.0 · fixed in 9.0.320
- Microsoft .NET source-build Linux tarballs (all archive types)
From 8.0.100 · fixed in 10.0.403-servicing.26523.112
- Microsoft ASP.NET Core runtime and targeting-pack Linux tarballs (Microsoft-published)
From 8.0.0 · fixed in 9.0.22
References 2
msrc.microsoft.com
GitHub · Ghost-Bx1/DotNet-Tarball-CVE-2026-114148
Questions about CVE-2026-114148
What does this mean?
The Linux .NET tarballs include root uid/gid ownership metadata on critical executables. When an administrator extracts them to install .NET, that ownership is applied, which can lead to local privilege escalation to root, for example by injecting a SUID executable or overwriting a system binary.Source: github.com
Am I affected, and how do I check?
The affected Linux tarballs are the .NET source-build tarballs (8.0.100 up to 10.0.403-servicing.26523.112) and the Microsoft-published ASP.NET Core runtime and targeting-pack tarballs (8.0.0 up to 9.0.22). The issue applies when the tarball is extracted on the system to install .NET. To check, run dotnet --list-runtimes to see the installed runtime versions and compare them with the fixed versions.Source: github.com
What should I do about it?
Update to .NET 8.0.33, 9.0.22 or 10.0.14, matching your installed major version.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. Public exploit code exists (a proof of concept on GitHub).Source: cve.now feed data