CVE-2026-105544: Local Elevation of Privilege in .NET Test Platform CLI

CVE-2026-105544 (tracked also as GHSA-6856-87HX-P5X7) is a local elevation of privilege vulnerability affecting the Microsoft .NET SDK, .NET Runtime environments, and Microsoft Visual Studio. The flaw resides specifically within the Microsoft.TestPlatform.CLI component, which is maintained in the microsoft/vstest repository and bundled across standard .NET SDK distributions on Windows, Linux, and macOS.

The Visual Studio Test Platform (vstest) serves as the primary test execution engine for .NET applications, powering command-line invocations such as dotnet test and vstest.console.exe as well as integrated test runners inside Visual Studio. During a test run, the CLI acts as an orchestration harness that initializes child runner processes, manages test discovery, and brokers results back to the calling user or continuous integration pipeline.

Classified under CWE-284 (Improper Access Control), the vulnerability occurs because the test platform fails to enforce strict access control policies on local communication resources, file handles, or process execution brokers created during a test run. When a legitimate user or automated service executes tests on a multi-user system, a low-privileged local attacker can intercept or manipulate these inadequately protected resources.

Successful exploitation allows the attacker to breach the authorization boundary of the test runner (Scope: Changed) and execute arbitrary code within the security context of the user invoking the test suite. If the invoking user holds administrative privileges or operates as a privileged build agent, the attacker achieves complete compromise of the host's confidentiality, integrity, and availability.

To isolate test execution from the primary build process and support multiple target frameworks, Microsoft.TestPlatform.CLI employs a distributed process architecture. When a user invokes dotnet test or vstest.console.exe, the parent CLI process spawns isolated child runner processes—most notably testhost.exe (or testhost on POSIX systems) and data collector brokers. The parent process coordinates with these child processes over local Inter-Process Communication (IPC) channels, such as named pipes or local sockets, and exchanges runtime configuration via temporary files on disk.

The root cause of CVE-2026-105544 is the failure to apply restrictive discretionary access control lists (DACLs) on Windows, or restrictive file and socket permissions (chmod/umask) on Linux and macOS, when initializing these IPC endpoints, named kernel objects, or temporary execution artifacts. Because these objects are instantiated with overly permissive access controls, they remain accessible to other local user accounts residing on the same machine.

During the window between test runner initialization and child process connection, an authorized low-privileged local user can interact with the exposed IPC channel or replace temporary runner artifacts. Because the parent vstest process and its child testhost processes implicitly trust data and commands traversing this boundary without secondary caller authentication, the attacker can inject arbitrary test assemblies, manipulate runtime broker configurations, or hijack the IPC stream.

This architectural flaw explains the Scope: Changed (S:C) designation in the CVSS vector. The vulnerable component (Microsoft.TestPlatform.CLI) operates within one security authority, while the vulnerability permits a low-privileged user from a separate security context to cross the OS user boundary and dictate execution inside the target's process space.

While Microsoft has not linked the exact line-by-line commit diff in the public MSRC advisory, the mechanics of CWE-284 within the microsoft/vstest and dotnet/sdk architecture follow a well-defined pattern regarding local IPC and temporary file management in .NET.

In vulnerable versions of Microsoft.TestPlatform.CLI (versions >= 17.2.0 and < 18.11.1), communication channels and temporary state directories are established using default operating system security descriptors or predictable paths in shared temporary directories (/tmp on Unix or standard shared folders).

// Conceptual representation of vulnerable IPC initialization in TestPlatform
// Missing explicit PipeSecurity / ACL restrictions allows cross-user connection or pre-creation
var pipeServer = new NamedPipeServerStream(
    pipeName: $"vstest_ipc_{processId}",
    direction: PipeDirection.InOut,
    maxNumberOfServerInstances: 1,
    transmissionMode: PipeTransmissionMode.Byte,
    options: PipeOptions.Asynchronous
);

When NamedPipeServerStream or local temporary configuration files are created without explicit security descriptors (or when a client connects to a named endpoint without verifying the server owner's security identifier), two primary failure modes emerge:

1. Endpoint Pre-creation / Squatting: If the IPC endpoint name or temporary artifact path is predictable (e.g., derived from process IDs or static GUIDs), a local attacker can pre-create the named pipe or file before the privileged test runner initializes, assuming control over the communication channel.
2. Unauthorized Client Connection: If the server endpoint does not restrict access exclusively to the CurrentUser or CreatorOwner SID, a local attacker running a tight polling loop can connect to the newly opened vstest IPC server ahead of the legitimate testhost child process.

// Conceptual representation of remediated access control enforcement
var pipeSecurity = new PipeSecurity();
var currentUser = WindowsIdentity.GetCurrent().User;
 
if (currentUser != null)
{
    // Restrict pipe access strictly to the user identity running the test process
    pipeSecurity.AddAccessRule(new PipeAccessRule(
        currentUser,
        PipeAccessRights.FullControl,
        AccessControlType.Allow
    ));
}
 
var pipeServer = NamedPipeServerStreamAcl.Create(
    pipeName: secureRandomPipeName,
    direction: PipeDirection.InOut,
    maxNumberOfServerInstances: 1,
    transmissionMode: PipeTransmissionMode.Byte,
    options: PipeOptions.Asynchronous | PipeOptions.CurrentUserOnly,
    inBufferSize: 0,
    outBufferSize: 0,
    pipeSecurity: pipeSecurity
);

By enforcing PipeOptions.CurrentUserOnly (which translates to FILE_FLAG_FIRST_PIPE_INSTANCE and strict owner verification in modern .NET runtimes) alongside user-isolated temporary directories (permissions 0700 on POSIX), the patched versions (18.11.1 and corresponding .NET SDK releases) ensure that no external local user can read, write, or bind to the test platform's execution channels.

Exploiting CVE-2026-105544 requires a specific set of operational prerequisites, reflected in its CVSS exploitability metrics (AV:L/AC:H/PR:L/UI:R). First, the attacker must already possess low-privileged code execution on the target host (PR:L), such as a standard user account on a shared development workstation, a multi-tenant build server, or a compromised low-privilege service account.

Second, exploitation requires user interaction (UI:R) and exhibits high attack complexity (AC:H). The attacker cannot trigger the privileged execution independently; instead, a legitimate higher-privileged user or an automated scheduled task running under a privileged account must initiate a test run using a vulnerable version of dotnet test, vstest.console.exe, or Visual Studio.

To overcome the high attack complexity, the attacker typically deploys a local monitoring process that watches for indicators of an impending test run—such as process creation events for dotnet or filesystem activity in shared build directories. Once the target user triggers the test execution pipeline, the attacker's process races the legitimate test runner (testhost) to interact with the improperly secured IPC channel or temporary test configuration files.

By winning this race condition, the attacker supplies a crafted test payload—such as a malicious .dll test assembly, a custom data collector, or a modified .runsettings configuration pointing to an attacker-controlled binary. When the privileged vstest broker processes this input, it loads and executes the attacker's code under the security token of the victim user.

> [!NOTE] > As of the advisory publication date, Microsoft assesses the Exploit Code Maturity for CVE-2026-105544 as Unproven (E:U). No public Proof-of-Concept (PoC) exploits exist on GitHub, ExploitDB, or PacketStorm, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

Despite the high attack complexity and the requirement for local access and user interaction, CVE-2026-105544 carries a CVSS v3.1 Base Score of 7.5 (High) due to its severe post-exploitation impact across security boundaries (S:C/C:H/I:H/A:H).

In enterprise software development and CI/CD environments, build servers and shared developer machines frequently host multiple user contexts. Self-hosted CI/CD runners (such as GitHub Actions runners, Azure DevOps agents, or Jenkins nodes) often execute dotnet test workflows to validate code commits. If an attacker compromises a low-privileged service or gains access to an unprivileged build worker on the same physical or virtual host, they can leverage CVE-2026-105544 to pivot into higher-privileged build pipelines or administrative user sessions.

Once arbitrary code execution is achieved in the context of the target user:

• Confidentiality (C:H): The attacker gains full read access to sensitive source code, code-signing certificates, cloud deployment credentials, NuGet API keys, and environment variables accessible to the privileged user or CI/CD agent.
• Integrity (I:H): The attacker can modify compiled build artifacts, inject backdoors into production release packages (supply chain compromise), or alter system-wide configurations if the victim holds administrative rights.
• Availability (A:H): The attacker can terminate critical services, corrupt local repositories, or render the host inoperable.

Microsoft has addressed CVE-2026-105544 by releasing security updates across all supported .NET branches, Visual Studio versions, and the standalone Microsoft.TestPlatform.CLI NuGet package. Organizations must update their development workstations, build servers, and container base images to the patched releases listed below.

In addition to upgrading the .NET SDK and Visual Studio installations on hosts, development teams must audit their project files (.csproj, Directory.Packages.props, and packages.lock.json) and .config/dotnet-tools.json manifests. If a project explicitly pins Microsoft.TestPlatform.CLI or Microsoft.NET.Test.Sdk to a vulnerable version below 18.11.1, the NuGet package reference must be updated so the build pipeline does not pull vulnerable test runner binaries during package restore.

<!-- Ensure explicit references in .csproj or Directory.Packages.props use 18.11.1 or higher -->
<ItemGroup>
  <PackageReference Include="Microsoft.TestPlatform.CLI" Version="18.11.1" />
</ItemGroup>

Where immediate patching is not feasible on multi-user build systems, administrators should enforce strict environment isolation:

• Avoid running dotnet test or Visual Studio under administrative or SYSTEM / root accounts.
• Configure per-user isolated temporary directories (TMP, TEMP, TMPDIR) with 0700 permissions (or strict user-only NTFS ACLs) so that other local accounts cannot access temporary test runner artifacts.
• Transition shared CI/CD build agents to ephemeral, single-tenant containers or virtual machines that are destroyed immediately after each build job completes.