CVE-2026-114155: Local Elevation of Privilege via TOCTOU Race Condition in Microsoft .NET dotnet-watch

dotnet-watch is a file watcher and development tool bundled with the Microsoft .NET SDK that automatically recompiles and reloads applications when source code changes are detected. When monitoring multiple projects simultaneously under Hot Reload, dotnet-watch aggregates the target project references into an on-the-fly XML solution file (.slnx) and invokes MSBuild to evaluate and build the solution.

In affected versions of .NET 10.0 and .NET 11.0, the HotReloadDotNetWatcher component generates these temporary .slnx files directly within the default system temporary directory (/tmp on Unix-like operating systems). Because /tmp is a shared, world-writable namespace on Linux and macOS, creating files in this directory without strict permission enforcement or exclusive file locking exposes those files to manipulation by other local users.

This behavior introduces a Time-of-Check Time-of-Use (TOCTOU) race condition tracked as CVE-2026-114155 (CWE-367). Between the moment dotnet-watch writes the .slnx file to disk and the moment the child MSBuild process parses it, the file handle is closed and left unlocked. A local unprivileged user can exploit this timing window to replace or modify the .slnx file, injecting malicious MSBuild directives that execute arbitrary commands under the privileges of the developer or automated build service running dotnet-watch.

The root cause of CVE-2026-114155 lies in the insecure use of the Path.GetTempFileName() API combined with premature stream closure in src/sdk/src/Dotnet.Watch/Watch/HotReload/HotReloadDotNetWatcher.cs. When BuildAsync processes a non-empty list of projectPaths, it constructs a path for the temporary solution file using the expression Path.Combine(Path.GetTempFileName() + ".slnx").

When Path.GetTempFileName() executes on POSIX systems, it creates an empty file in /tmp with a unique name (for example, /tmp/tmpa1b2.tmp) using exclusive creation flags (O_CREAT | O_EXCL) and restrictive permissions. However, appending the string ".slnx" to the returned path references a second, distinct file path (/tmp/tmpa1b2.tmp.slnx) that has not yet been created or reserved on the filesystem. Furthermore, the original /tmp/tmpa1b2.tmp file is left behind as an orphaned artifact whose name is immediately visible to any local user listing /tmp.

Once dotnet-watch populates the XDocument object in memory, it writes the XML content to the .slnx path by calling doc.Save(solutionFile). This method opens a file stream, writes the serialized XML, and immediately closes and disposes of the underlying file handle. After doc.Save() returns, dotnet-watch invokes BuildFileOrProjectOrSolutionAsync(solutionFile, ...), which spawns or signals MSBuild to read and evaluate the file from disk.

Because the .slnx file is neither created with O_EXCL inside a private directory nor held open with a write-restricting lock, two distinct attack vectors emerge during the TOCTOU window. First, an attacker watching /tmp via inotify (Linux) or kqueue (macOS) can detect the creation of /tmp/tmpXXXX.tmp, immediately predict the target filename /tmp/tmpXXXX.tmp.slnx, and pre-create the .slnx file or a symbolic link before doc.Save() runs. Second, if the user's umask is permissive, or if the attacker pre-created the file and granted write permissions to the victim, the attacker can overwrite the contents of /tmp/tmpXXXX.tmp.slnx after doc.Save() closes the stream but before MSBuild opens it.

Prior to the patch, HotReloadDotNetWatcher.cs managed the lifecycle of the temporary .slnx file manually using string concatenation and a try/finally deletion block. The vulnerable implementation is shown below:

// Vulnerable implementation in src/sdk/src/Dotnet.Watch/Watch/HotReload/HotReloadDotNetWatcher.cs
else if (projectPaths is not [])
{
    // 1. Creates /tmp/tmpXXXX.tmp, but derives unreserved path /tmp/tmpXXXX.tmp.slnx
    var solutionFile = Path.Combine(Path.GetTempFileName() + ".slnx");
    var solutionElement = new XElement("Solution");
 
    foreach (var projectPath in projectPaths)
    {
        // populate solution elements
    }
 
    var doc = new XDocument(solutionElement);
    // 2. Writes file to /tmp and immediately closes the file stream
    doc.Save(solutionFile);
 
    try
    {
        // 3. TOCTOU Window: MSBuild reads the unlocked file by path name
        if (!await BuildFileOrProjectOrSolutionAsync(solutionFile, targetFramework, device, action, cancellationToken))
        {
            return false;
        }
    }
    finally
    {
        try
        {
            File.Delete(solutionFile);
        }
        catch
        {
            // ignore
        }
    }
}

In commit c46253a634a2725fd34820ad8a36a3f106f5d01d, Microsoft remediated the vulnerability by introducing a dedicated TemporaryFileManager class and refactoring HotReloadDotNetWatcher.cs to write directly to an open, locked FileStream:

// Patched implementation in src/sdk/src/Dotnet.Watch/Watch/HotReload/HotReloadDotNetWatcher.cs
else if (projectPaths is not [])
{
    // Keep the file open and allow other processes to read it (but not modify) after the content is written:
    using var solutionFile = _context.TemporaryFileManager.Create(".slnx", FileShare.Read);
    var solutionElement = new XElement("Solution");
 
    foreach (var projectPath in projectPaths)
    {
        // populate solution elements
    }
 
    var doc = new XDocument(solutionElement);
    // Save directly to the open FileStream without closing the handle
    doc.Save(solutionFile.Stream);
 
    if (!await BuildFileOrProjectOrSolutionAsync(solutionFile.Stream.Name, targetFramework, device, action, cancellationToken))
    {
        return false;
    }
}

The new TemporaryFileManager class eliminates both the shared directory exposure and the unlocked file state:

// New file: src/sdk/src/Dotnet.Watch/Watch/TemporaryFileManager.cs
namespace Microsoft.DotNet.Watch;
 
internal sealed partial class TemporaryFileManager : IDisposable
{
    internal readonly struct TemporaryFile(FileStream stream) : IDisposable
    {
        public FileStream Stream => stream;
 
        public void Dispose()
        {
            try { stream.Dispose(); } catch { }
            try { File.Delete(stream.Name); } catch { }
        }
    }
 
    private const string TempDirectoryPrefix = "dotnet-watch-";
 
    // Creates a subdirectory with 0700 (owner-only) permissions on Unix
    private readonly string _directory = Directory.CreateTempSubdirectory(TempDirectoryPrefix).FullName;
 
    private int _uniqueFileId;
 
    public void Dispose()
    {
        try { Directory.Delete(_directory, recursive: true); } catch { }
    }
 
    public TemporaryFile Create(string extension, FileShare share)
        => new(new FileStream(
            path: Path.Combine(_directory, Interlocked.Increment(ref _uniqueFileId) + extension),
            mode: FileMode.CreateNew,
            access: FileAccess.ReadWrite,
            share: share));
}

> [!NOTE] > Fix Completeness Assessment: The fix is comprehensive on POSIX systems because Directory.CreateTempSubdirectory invokes mkdtemp, which atomically creates a directory with 0700 (rwx------) permissions owned by the effective user ID. Because the parent directory lacks group and other execute/search bits, unprivileged local users cannot traverse into the dotnet-watch-* subdirectory to pre-create, read, or modify files regardless of file locking semantics.

Exploiting CVE-2026-114155 requires local code execution capabilities as a low-privileged user on the same Linux or macOS host where a victim user (such as a senior developer, system administrator, or CI/CD runner) executes dotnet watch across multiple projects. Windows environments are not affected under default configurations because Path.GetTempPath() resolves to a user-isolated directory (%USERPROFILE%\AppData\Local\Temp).

To reliably win the race condition, an attacker sets up a filesystem monitoring loop on /tmp using the Linux inotify API (specifically watching for IN_CREATE events). When the victim runs dotnet watch, Path.GetTempFileName() creates /tmp/tmpXXXXXX.tmp. This immediately triggers an IN_CREATE event before dotnet-watch even begins constructing the XElement tree in memory.

Upon receiving the notification for /tmp/tmpXXXXXX.tmp, the attacker's process immediately creates /tmp/tmpXXXXXX.tmp.slnx with world-writable permissions (0666) before doc.Save(solutionFile) is reached. Because doc.Save(string) opens existing files with FileMode.Create (which truncates rather than failing if the file already exists), dotnet-watch writes the legitimate XML into the attacker-owned file and closes the stream. Immediately after IN_CLOSE_WRITE fires on /tmp/tmpXXXXXX.tmp.slnx, the attacker truncates and overwrites the file with a malicious solution or MSBuild project payload.

Alternatively, the attacker can replace the .slnx reference with a project file path containing an MSBuild <Target> definition that executes an <Exec> task:

<Project Sdk="Microsoft.NET.Sdk">
  <Target Name="Build">
    <Exec Command="/bin/sh -c 'cp /bin/sh /tmp/rootsh &amp;&amp; chmod +s /tmp/rootsh'" />
  </Target>
</Project>

When BuildFileOrProjectOrSolutionAsync invokes MSBuild on /tmp/tmpXXXXXX.tmp.slnx (or a referenced project path injected into the .slnx file), MSBuild parses the attacker-controlled XML and executes the embedded shell commands under the UID and GID of the victim user.

Successful exploitation of CVE-2026-114155 grants the attacker arbitrary code execution within the security context of the user running dotnet-watch. In multi-user development servers, shared academic or enterprise build hosts, or containerized CI/CD environments where multiple agents share a host /tmp mount, an attacker can cross user boundaries and compromise higher-privileged accounts.

Microsoft assigned CVE-2026-114155 a CVSS v3.1 base score of 7.5 (High) with the vector CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H. The Scope: Changed (S:C) metric reflects that a vulnerability in the .NET SDK build tool allows an unprivileged local user to escape their OS user boundary and execute code as another user or service account.

Confidentiality, Integrity, and Availability impacts are all rated High (C:H/I:H/A:H). Once code execution is achieved in the victim's context, the attacker can exfiltrate source code, steal cloud credentials, SSH keys, or NuGet API tokens stored in the victim's home directory, modify build artifacts to introduce supply chain backdoors, or terminate the victim's processes.

At the time of publication, there are no known public proof-of-concept exploits in the wild, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The Attack Complexity is rated High (AC:H) because exploitation depends on both the victim running dotnet watch in a multi-project configuration and the attacker winning the filesystem race window.

The primary remediation is to update the Microsoft .NET SDK and associated NuGet packages to the patched releases that incorporate the TemporaryFileManager isolation mechanism. Specifically, administrators and developers on Linux and macOS should apply the following updates:

• Microsoft .NET 10.0: Upgrade SDK to version 10.0.404 (Runtime 10.0.15) or later.
• Microsoft .NET 11.0: Upgrade SDK to version 11.0.100 (Runtime 11.0.0) or later.
• Microsoft.DotNet.HotReload.Watch.Aspire: Update package references to version 11.0.100 or later.

For environments where immediate patching is not possible, system administrators and developers can completely neutralize the vulnerability by configuring a private, per-user temporary directory via the TMPDIR environment variable. Because .NET's Path.GetTempPath() and Path.GetTempFileName() respect TMPDIR on POSIX systems, pointing TMPDIR to a mode 0700 directory inside the user's home directory prevents other local users from accessing or racing temporary files:

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

In automated build pipelines or shared Linux hosts, administrators can also implement systemd PrivateTmp=yes directives for build services, or enable the Linux kernel fs.protected_regular sysctl parameter (sysctl -w fs.protected_regular=2), which restricts O_CREAT file opens in world-writable sticky directories (/tmp) when the file is owned by another user.