CVE-2026-26131: Local Elevation of Privilege via Incorrect Default Permissions in .NET 10.0

Microsoft .NET 10.0 on Linux platforms suffers from a critical Elevation of Privilege (EoP) vulnerability tracked as CVE-2026-26131. The flaw affects versions 10.0.0 through 10.0.3 and manifests as incorrect default permissions (CWE-276) assigned to runtime binaries during the installation process. Installation artifacts such as DEB, RPM, and tarballs are generated with excessively permissive file mode bits.

This misconfiguration exposes critical runtime components, including the primary dotnet executable and core libraries like libcoreclr.so, to unauthorized modification by unprivileged local users. When a high-privileged user or a system-level service subsequently executes a .NET application, the compromised components are loaded into the elevated process space.

The resulting impact is local privilege escalation, allowing an attacker to execute arbitrary code with the privileges of the victim process. The vulnerability strictly requires local access to the target system but operates with low attack complexity and no user interaction requirements.

The root cause of CVE-2026-26131 lies within the automated CI/CD build and packaging pipeline responsible for generating .NET distribution artifacts for Linux. The Microsoft.DotNet.Build.Tasks.Installers component and the Arcade SDK failed to explicitly define restrictive POSIX file mode bits during the package assembly process. The build environment relied on generic ubuntu-latest hosted runners, which operate with default umask settings that do not enforce the strict file permissions necessary for system-level software distribution.

Due to the absence of explicit permission masking during the artifact generation phase, critical files and directories were packaged with insecure mode bits. Directories such as /usr/share/dotnet/ and key shared objects within the runtime were assigned world-writable permissions (e.g., 0777 or 0666). When these packages are installed on a target Linux system, the package manager applies the permissions exactly as defined in the archive metadata.

The failure to sanitize these permissions before the final artifact generation creates a permanent binary planting vector on the host system. Any local user with standard access can exploit this state by overwriting the affected binaries or libraries before they are loaded by a higher-privileged process.

The remediation for CVE-2026-26131 focused on hardening the build environment and explicitly enforcing file permissions during the packaging process. The Microsoft development team transitioned the build jobs from generic runners to managed, hardened build pools. This change ensures a deterministic build environment where file creation masks are strictly controlled.

Commit 68e6a46ca3621a23ad64073615232df744c053f8 demonstrates the transition of the path evaluation jobs away from the generic ubuntu-latest image. The patched configuration explicitly routes builds to designated internal or public pools with strict OS overrides.

- job: evaluate_paths
  pool:
-      vmImage: 'ubuntu-latest'
+      ${{ if eq(variables['System.TeamProject'], 'public') }}:
+          name:  $(DncEngPublicBuildPool)
+          demands: ImageOverride -equals Build.Ubuntu.2204.Amd64.Open
+      ${{ else }}:
+          name: $(DncEngInternalBuildPool)
+          demands: ImageOverride -equals Build.Ubuntu.2204.Amd64
+          os: linux

A subsequent commit, a73f1f6a642ff779590ece8d2a70952f6f65a3fb, further hardened this infrastructure by enforcing the use of the Azure-Linux-3-Amd64 image. Alongside infrastructure changes, the Arcade SDK was updated to explicitly set permissions to 0755 for directories and executables, and 0644 for non-executable data files. This multi-layered fix ensures that artifacts are both built in a secure environment and explicitly tagged with safe POSIX permissions before distribution.

Exploitation of CVE-2026-26131 requires an attacker to possess valid local access to a system running a vulnerable installation of .NET 10.0. The attacker begins by enumerating the filesystem to identify .NET runtime components deployed with world-writable permissions. Standard POSIX utilities, such as find /usr/share/dotnet -perm -o+w, are sufficient to locate vulnerable targets like libcoreclr.so or the host dotnet binary itself.

Once a target is identified, the attacker compiles a malicious shared object or executable designed to replace the legitimate component. Because the file is world-writable, the attacker can use standard file operations (cp or mv) to overwrite the runtime library without requiring elevated privileges. The malicious payload is typically designed to execute a reverse shell or establish persistence upon loading, before proxying execution back to the original runtime logic to avoid immediate detection.

The exploitation chain concludes when a high-privileged entity, such as a root cron job, an administrative user, or a systemd service, executes a .NET application. The .NET host process unwittingly loads the attacker-controlled component, executing the embedded malicious code within the security context of the invoking user. This grants the attacker full control over the execution environment and, depending on the victim process, full administrative control of the system.

The successful exploitation of CVE-2026-26131 results in a complete compromise of the execution environment running the .NET application. If the application is invoked by the root user or a highly privileged service account, the attacker achieves full system compromise. This allows for arbitrary data exfiltration, modification of system configurations, and lateral movement within the network.

The vulnerability is assessed with a CVSS v3.1 base score of 7.8, reflecting its high severity (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). The Attack Vector is Local (AV:L), indicating the attacker must already have a foothold on the system. The Attack Complexity is Low (AC:L) because exploitation relies on fundamental filesystem operations and deterministic runtime behavior, requiring no advanced race conditions or memory corruption techniques.

Despite the high severity, the current EPSS score is 0.00042 (12.50th percentile), suggesting a low probability of active exploitation in the wild. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The primary risk remains within multi-tenant environments or systems where standard users operate alongside high-privileged automation scripts.

The primary remediation for CVE-2026-26131 is to upgrade the .NET SDK and runtime environments to version 10.0.4. This release includes the corrected package configurations and hardened build metadata. System administrators must use their respective package managers to pull the updated packages and verify that the permissions in /usr/share/dotnet/ have been corrected to 0755 for directories and 0644 for files.

A critical edge case exists for Self-Contained Deployments (SCD). Applications compiled as self-contained binaries package the vulnerable runtime components directly into the application directory. Updating the global system runtime does not patch these applications. Developers must recompile and republish all self-contained applications using the patched .NET 10.0.4 SDK to ensure the deployed artifacts carry the correct file permissions.

In environments where immediate patching is not feasible, administrators can apply a temporary workaround by manually correcting the file permissions on existing .NET installations. Executing chmod -R o-w /usr/share/dotnet/ recursively removes world-writable permissions from the runtime directory, immediately neutralizing the local binary planting vector. This manual intervention must be strictly audited and reapplied if the system is altered or partially updated before the official patch is deployed.