CVE-2026-0827: LdeApi.Server.exe Assumes It Creates the Directory First

The directory's absence is not an installation bug

C:\ProgramData on Windows holds machine-wide application data shared across user accounts. Its ACL structure grants standard users the right to create new subdirectories through inherited permissions. Any user can create C:\ProgramData\Lenovo if it does not exist, and C:\ProgramData\Lenovo\LDE after that. Applications writing shared data under C:\ProgramData\<Vendor> are expected to pre-create their data directories at install time with restrictive DACLs, before any user can occupy a path.

LdeApi.Server.exe, part of Lenovo Vantage's hardware diagnostic infrastructure, writes MP27AM7W_estimation.json to C:\ProgramData\Lenovo\LDE\SYSTEM. On a machine where that write has never occurred, the directory is absent. The service does not create the directory at install time. It creates it at write time, which means any standard user who creates it first has arrived before the service. If they create it as an NTFS junction, the service arrives, resolves the path, follows the junction, and writes to wherever the junction points.

The PoC checks for the directory's presence before proceeding:

if (Directory.Exists(lde_system))
{
    Console.WriteLine("[-] SYSTEM directory already exists. Delete it first or clean up.");
    return;
}

This check is for the attacker's benefit, not the defender's. It tells the attacker whether the path is still unoccupied. The service has no equivalent check.

The mount point and the NT namespace symlink

The exploit chains two operations that individually require no elevated privileges.

First, the attacker creates C:\ProgramData\Lenovo\LDE\SYSTEM as a real directory, then converts it into an NTFS mount point targeting \RPC Control, a directory in the Windows NT object manager namespace:

static void SetMountPoint(string path, string target)
{
    using (var file = NtFile.Open(NtFileUtils.DosFileNameToNt(path), null,
        FileAccessRights.WriteAttributes))
    {
        file.SetMountPoint(target, string.Empty);
    }
}
// called as: SetMountPoint(lde_system, @"\RPC Control");

Second, an NT symbolic link at \RPC Control\MP27AM7W_estimation.json is created, pointing to the attacker-chosen target file. The symlink is held open during Console.ReadLine() inside a using block:

using (var link = NtSymbolicLink.Create(
    @"\RPC Control\" + targetFileName,
    NtFileUtils.DosFileNameToNt(targetFile)))
{
    Console.WriteLine("[*] Now trigger the Lenovo service to write the file...");
    Console.ReadLine();
}

While the PoC waits at Console.ReadLine(), the attacker opens Lenovo Vantage in a second window, starts a hardware scan, and waits for it to complete. When LdeApi.Server.exe writes MP27AM7W_estimation.json, the kernel follows the mount point from C:\ProgramData\Lenovo\LDE\SYSTEM to \RPC Control, resolves the symbolic link at \RPC Control\MP27AM7W_estimation.json, and performs the write at the attacker's chosen path under SYSTEM privileges.

The PoC's default target is C:\Windows\System32\test.json.

Why \RPC Control closes the symlink privilege gap

Creating symbolic links in the Windows file system requires SeCreateSymbolicLinkPrivilege, which standard users do not hold. \RPC Control sidesteps this. It is a directory in the Windows NT object manager namespace, not the file system. Standard users have write access to it for legacy reasons related to RPC endpoint registration, and NT symbolic links created there are not subject to the file system privilege requirement. The name \RPC Control is a historical artifact: the directory's open write access has nothing to do with controlling RPC communication and everything to do with the object manager not restricting symlink creation there.

The mount point requires only that the attacker own the directory they are converting, which they do because they just created it. It bridges the file system into the NT namespace. The NT symlink, which standard users can create in \RPC Control, handles the final redirect. Two steps, neither requiring elevated privilege, composing into an arbitrary write as SYSTEM.

This exact mechanism is the subject of James Forshaw's public Windows privilege escalation research at Google Project Zero. The PoC's only external dependency is NtApiDotNet version 1.1.24, the NT API wrapper library authored by Forshaw. The PoC credits Forshaw and Project Zero.

The content is not attacker-controlled

The file written is MP27AM7W_estimation.json: hardware estimation output from Lenovo's diagnostic cycle. The attacker controls the destination path. They do not control the file's contents, which are JSON data produced by the service. Writing that JSON to C:\Windows\System32\test.json, the PoC's default, creates a file. It does not execute.

The CVSS 3.1 vector is C:N I:H A:H. No confidentiality impact. The high integrity and availability scores reflect what arbitrary-destination file write produces: corruption of files a SYSTEM process depends on, or substitution of a config a process reads. Advancing from this primitive to code execution requires identifying a SYSTEM-level process on the target that reads a JSON-format config from a path reachable by the estimation write, where MP27AM7W_estimation.json's content satisfies or disrupts that read in a useful way. That second stage is not in the PoC.

The attack requires a machine where Lenovo Diagnostics or HardwareScanAddin is installed and C:\ProgramData\Lenovo\LDE\SYSTEM does not yet exist, meaning the path has not been created by a prior diagnostic write. The standard user then triggers the scan through Lenovo Vantage with the junction already in place.

A class documented since 2015, arriving in new software anyway

The mount point plus NT namespace symlink technique for Windows local privilege escalation has been in the public research record since approximately 2015, across Forshaw's Project Zero posts, conference presentations, and the NtApiDotNet tooling itself. The recurring shape is junction preemption: a SYSTEM service writes to a path under C:\ProgramData or a similar user-accessible location, without pre-creating that path with restrictive ACLs and without checking whether the target directory has been replaced with a reparse point before writing.

Lenovo's hardware diagnostic service, whose function is to determine whether hardware is operating correctly, writes its output to a path of exactly that shape. The service arrived at CVE-2026-0827 the same way dozens of products before it did: writing to a C:\ProgramData subdirectory it assumed it owned, in a directory it did not create at install time.

CWE-59 names this "link following." The NVD description says "arbitrary file write with elevated privileges." Neither phrase explains why the service has no defense: it is not checking for link presence before writing because it never expected to find anything at a path it thought it was creating.

You don't overwrite the file. You redirect where it lands. The service is the delivery mechanism.

PoC: ZeroMemoryEx/CVE-2026-0827