CVE-2026-120778: Local Elevation of Privilege via Insecure Temporary Directory Handling and MSBuild Response File Hijacking in Microsoft .NET Aspire CLI

Microsoft .NET Aspire is a cloud-native application development stack designed for building observable, production-ready distributed applications. Its command-line interface (Aspire.Cli) includes a suite of SDK subcommands—specifically aspire sdk generate, aspire sdk dump, and aspire sdk export—that developers and continuous integration pipelines use to inspect, generate, and export metadata and integration bindings for Aspire AppHost projects.

To perform capability scanning and metadata generation, the Aspire CLI dynamically provisions temporary .NET projects on disk and invokes the .NET SDK (dotnet restore and dotnet build) against them. In Aspire.Cli versions from 13.5.4 up to 13.6.5, these temporary project directories were generated directly inside the system-wide temporary directory returned by Path.GetTempPath() or Directory.CreateTempSubdirectory(). On Linux and macOS systems, this resolves to /tmp or /var/tmp, which are world-writable directories shared across all local user accounts.

The vulnerability (tracked as CVE-2026-120778 and classified under CWE-379: Creation of Temporary File in Directory with Insecure Permissions and CWE-427: Uncontrolled Search Path Element) arises from the interaction between shared temporary directory placement and MSBuild's upward directory traversal behavior. When MSBuild runs, it searches the project directory and all ancestor directories up to the filesystem root for automatic configuration and response files, notably Directory.Build.rsp, Directory.Build.props, and Directory.Build.targets.

Because the temporary build projects were situated inside /tmp and invoked without suppressing automatic response file resolution, an unprivileged local user can plant a malicious Directory.Build.rsp file inside /tmp. When another user on the same host runs an aspire sdk command, the underlying MSBuild process parses the attacker's response file, resulting in arbitrary command execution under the victim user's privileges.

The root cause of CVE-2026-120778 is a combination of three distinct implementation flaws in how Aspire.Cli manages temporary workspaces and invokes child dotnet processes.

First, the CLI relied on standard .NET runtime temporary directory APIs (Directory.CreateTempSubdirectory and Path.Combine(Path.GetTempPath(), ...)) without isolating the workspace root per user. While Directory.CreateTempSubdirectory creates the immediate leaf directory with restricted permissions on modern .NET runtimes, its parent directory (/tmp) remains world-writable (1777). Furthermore, in SdkGenerateCommand.cs, the CLI constructed an intermediate directory (/tmp/aspire-sdk-gen/<guid>) using Directory.CreateDirectory(), which inherits the process umask (typically 0755), allowing other local users to traverse or pre-create directory structures.

Second, MSBuild implements an upward file discovery mechanism by default. Whenever dotnet restore or dotnet build is executed on a project file, the MSBuild engine walks up the directory tree from the target .csproj location toward the root filesystem (/) looking for Directory.Build.rsp. Any command-line switches or target definitions contained within a discovered Directory.Build.rsp file are automatically prepended to the MSBuild invocation arguments.

Third, when DotNetCliRunner constructed the command-line arguments for dotnet restore and dotnet build to compile the temporary AppHost capability scanner, it omitted the -noAutoResponse switch. Without this switch or an isolation boundary stopping upward traversal, any build occurring inside a subdirectory of /tmp implicitly trusts files placed in /tmp.

Additionally, a secondary insecure temporary file issue existed in DeprecatedMcpCommandScanner.cs, where diagnostic scan logs were appended directly to a hardcoded, predictable path (/tmp/aspire-deprecated-scan.log) without exclusive file creation flags or restrictive permissions (0600). Similarly, FileLoggerProvider.cs created diagnostic log streams without enforcing owner-only Unix file modes.

Reviewing commit 1ecd7cc70b5a5a5b8571fe3af69faa1646b8de47 reveals how the vulnerable code paths were structured and subsequently remediated across Aspire.Cli.

In the unpatched versions of SdkDumpCommand.cs, SdkExportCommand.cs, and SdkGenerateCommand.cs, temporary directories were allocated directly in the system temporary folder:

// Vulnerable code in SdkDumpCommand.cs & SdkExportCommand.cs
var tempDirectory = Directory.CreateTempSubdirectory("aspire-sdk-dump-");
try
{
    outputPath = Path.Combine(tempDirectory.FullName, "capabilities.json");
    // Invokes AppHost server build inside tempDirectory
}
 
// Vulnerable code in SdkGenerateCommand.cs
var tempDir = Path.Combine(Path.GetTempPath(), "aspire-sdk-gen", Guid.NewGuid().ToString("N")[..8]);
Directory.CreateDirectory(tempDir);

To eliminate reliance on the shared OS temp directory, Microsoft introduced CliPathHelper.CreateSdkWorkingDirectory and DirectoryHelper.CreateWithOwnerOnlyPermissions. Temporary SDK workspaces are now created inside the user's private Aspire home directory (<ASPIRE_HOME>/tmp/sdk/<guid>) with strict 0700 Unix permissions (UserRead | UserWrite | UserExecute). An empty aspire.config.json file is also written to the directory to act as a configuration boundary anchor:

// Patched code in src/Aspire.Cli/Utils/CliPathHelper.cs
internal static DirectoryInfo CreateSdkWorkingDirectory(DirectoryInfo aspireHomeDirectory)
{
    ArgumentNullException.ThrowIfNull(aspireHomeDirectory);
 
    // Enforce 0700 permissions on every level of the temporary hierarchy
    var tempRoot = DirectoryHelper.CreateWithOwnerOnlyPermissions(
        Path.Combine(aspireHomeDirectory.FullName, "tmp"));
    var sdkRoot = DirectoryHelper.CreateWithOwnerOnlyPermissions(
        Path.Combine(tempRoot.FullName, "sdk"));
    var directory = DirectoryHelper.CreateWithOwnerOnlyPermissions(
        Path.Combine(sdkRoot.FullName, Guid.NewGuid().ToString("N")));
 
    // Write an empty config anchor so configuration discovery stops here
    File.WriteAllText(
        Path.Combine(directory.FullName, Configuration.AspireConfigFile.FileName), "{}");
 
    return directory;
}

The helper DirectoryHelper.CreateWithOwnerOnlyPermissions enforces 0700 permissions both when creating new directories and when repairing pre-existing directories on Unix platforms:

// Patched code in src/Aspire.Cli/Utils/DirectoryHelper.cs
internal static DirectoryInfo CreateWithOwnerOnlyPermissions(string path)
{
    if (OperatingSystem.IsWindows())
    {
        return Directory.CreateDirectory(path);
    }
 
    const UnixFileMode ownerOnlyPermissions =
        UnixFileMode.UserRead | UnixFileMode.UserWrite | UnixFileMode.UserExecute;
 
    var directory = Directory.CreateDirectory(path, ownerOnlyPermissions);
    File.SetUnixFileMode(directory.FullName, ownerOnlyPermissions);
    return directory;
}

To address the MSBuild response file hijacking vector directly, DotNetCliRunner.cs was updated to support a NoAutoResponse option in ProcessInvocationOptions, appending -noAutoResponse to dotnet restore and dotnet build commands:

// Patched code in src/Aspire.Cli/DotNet/DotNetCliRunner.cs
string[] cliArgs = ["restore", projectFilePath.FullName];
if (options.NoAutoResponse)
{
    // Prevents MSBuild from loading Directory.Build.rsp from current or parent directories
    cliArgs = [.. cliArgs, "-noAutoResponse"];
}

In AppHostServerProject.cs, both RestoreAsync and BuildAsync now initialize ProcessInvocationOptions with NoAutoResponse = true. Finally, DeprecatedMcpCommandScanner.cs was stripped of its /tmp/aspire-deprecated-scan.log file writes, and FileLoggerProvider.cs was hardened to open log files using UnixCreateMode = UnixFileMode.UserRead | UnixFileMode.UserWrite (0600).

> [!NOTE] > Fix Completeness Assessment: The remediation applies defense-in-depth by addressing both the filesystem permission weakness and the MSBuild execution behavior. Relocating the working directory under <ASPIRE_HOME>/tmp/sdk with 0700 permissions prevents other local users from traversing or writing into the build hierarchy. Adding -noAutoResponse ensures that even if an ancestor directory above <ASPIRE_HOME> were writable by another party, MSBuild will not auto-load Directory.Build.rsp files. However, note that MSBuild still evaluates Directory.Build.props and Directory.Build.targets in ancestor directories unless /p:ImportDirectoryBuildProps=false and /p:ImportDirectoryBuildTargets=false are specified; relocating the build out of /tmp and into the user's private home directory mitigates that vector provided the user's home directory tree itself is not world-writable.

Exploiting CVE-2026-120778 requires local access to a shared multi-user Unix/Linux or macOS system where a victim user runs an affected version of .NET Aspire CLI (13.5.4 through 13.6.4). No special privileges are required by the attacker beyond standard write permissions to /tmp.

Attack Prerequisites

1. Local Access: The attacker must have a low-privileged local account or code execution within a shared environment (such as a shared build agent, development server, or multi-tenant host) that shares /tmp with the target user.
2. User Interaction: A victim user (or automated CI/CD service account) must execute aspire sdk generate, aspire sdk dump, or aspire sdk export.

Exploitation Steps

1. Stage Malicious Target and Response File: The attacker creates an MSBuild targets file /tmp/payload.targets containing an inline <Exec> task, and a response file /tmp/Directory.Build.rsp that instructs MSBuild to import or execute that target.

<!-- /tmp/payload.targets -->
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="HijackBuild" BeforeTargets="Restore;Build">
    <Exec Command="/bin/sh -c 'id > /tmp/pwned_by_aspire; chmod +s /tmp/victim_shell'" />
  </Target>
</Project>

2. Plant the Response File in /tmp: The attacker writes /tmp/Directory.Build.rsp to inject the custom target or property into any MSBuild process running beneath /tmp:

-p:CustomBeforeMicrosoftCommonTargets=/tmp/payload.targets
-target:HijackBuild

3. Trigger via Victim CLI Execution: When the victim user runs aspire sdk dump or aspire sdk generate in their own workspace, the Aspire CLI creates /tmp/aspire-sdk-dump-<random>/ or /tmp/aspire-sdk-gen/<guid>/ and invokes dotnet restore and dotnet build on the generated capability scanner project.
4. Payload Execution: MSBuild walks up from /tmp/aspire-sdk-.../ to /tmp, finds /tmp/Directory.Build.rsp, appends the attacker's arguments, and executes HijackBuild under the victim's UID/GID.

In the regression test suite added in commit 1ecd7cc70b5a5a5b8571fe3af69faa1646b8de47 (SdkResponseFileTests.cs), Microsoft verified this exact mechanism by writing -target:ResponseFileMustNotBeLoaded into a parent Directory.Build.rsp file and confirming that unpatched builds trigger the injected target while patched aspire sdk commands ignore it.

CVE-2026-120778 is rated High severity with a CVSS v3.1 score of 7.3 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H). The primary impact is local elevation of privilege across user boundaries on shared workstations, build servers, and development hosts.

When successfully exploited, the attacker achieves arbitrary code execution in the security context of the user invoking the Aspire CLI. This grants the attacker full Confidentiality (High), Integrity (High), and Availability (High) impact over the victim user's environment:

• Confidentiality: The attacker can read sensitive source code, cloud credentials, NuGet API keys, SSH private keys, and environment variables belonging to the victim developer or CI runner.
• Integrity: The attacker can modify the victim's source repositories, inject malicious backdoors into compiled application artifacts during the SDK build step, or persist access by modifying the victim's shell profile (~/.bashrc, ~/.zshrc).
• Availability: The attacker can terminate processes, corrupt build outputs, or delete files owned by the victim account.

As of disclosure, there are no reports of active exploitation in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Windows environments are generally less exposed to the cross-user /tmp vector because Path.GetTempPath() on Windows resolves to per-user directories (C:\Users\<username>\AppData\Local\Temp), whereas Linux and macOS resolve /tmp or /var/tmp to a shared global directory unless TMPDIR is explicitly isolated per user.

Microsoft resolved CVE-2026-120778 in .NET Aspire version 13.6.5, released on November 10, 2026. All users and administrators operating multi-user development environments or shared CI/CD build agents should upgrade to version 13.6.5 or later.

Applying the Update

To update the .NET Aspire workload and CLI tool to the patched release, run the following commands:

# Update .NET workloads
dotnet workload update
 
# Update the Aspire CLI global tool (if installed as a standalone tool)
dotnet tool update -g Aspire.Cli --version 13.6.5
 
# Verify the installed CLI version is 13.6.5 or newer
aspire --version

Temporary Workarounds

If an immediate upgrade to .NET Aspire 13.6.5 is not feasible, administrators and developers on shared Unix/Linux and macOS hosts can mitigate the vulnerability using the following controls:

1. Isolate TMPDIR Per User: Configure the environment so TMPDIR points to an owner-only directory inside the user's home directory (0700) before invoking aspire commands:

   mkdir -m 0700 -p "$HOME/.tmp"
   export TMPDIR="$HOME/.tmp"

   Because .NET's Path.GetTempPath() respects the TMPDIR environment variable on Unix-like platforms, setting TMPDIR to a private directory inside $HOME prevents traversal through /tmp.
2. Audit /tmp for MSBuild Files: Monitor and clean /tmp and /var/tmp for unauthorized Directory.Build.rsp, Directory.Build.props, and Directory.Build.targets files.
3. Use pam_namespace or Private /tmp Mounts: On shared Linux hosts, configure per-user polyinstantiated /tmp directories via pam_namespace or execute CI jobs inside isolated container namespaces with private /tmp tmpfs mounts.