CVE-2025-55680 PoC: Turning a Windows Cloud Files Race Condition into Real-World Privilege Escalation

When Microsoft ships another local elevation-of-privilege fix, it is easy to treat it as “just one more CVE in Patch Tuesday.” CVE-2025-55680 deserves more attention than that. It is a Time-of-check Time-of-use (TOCTOU) race condition in the Windows Cloud Files Mini Filter Driver (cldflt.sys) that lets a low-privileged local user create arbitrary files in sensitive locations and ride that to SYSTEM.(NVD)

For defenders, this is one more data point in a long history of Cloud Files–related bugs; for red teamers and exploit developers, it is a modern case study in how cloud sync abstractions open up kernel-adjacent attack surface. Since AI-assisted pentesting is increasingly used to reason about such bugs, CVE-2025-55680 is also a natural testbed for automated PoC generation.

This article walks through the vulnerability mechanics, exploitation model, and realistic mitigation strategies, then looks at how AI-driven tooling like Penligent can move teams from “we have a CVE” to “we have proof this is (or isn’t) exploitable in our environment.”

Understanding CVE-2025-55680 in Context

According to NVD and the official CVE.org record, CVE-2025-55680 is a TOCTOU race condition in the Windows Cloud Files Mini Filter Driver that enables a local, authenticated attacker to elevate privileges. It carries a CVSS v3.1 base score in the high range (around 7.0–7.8 depending on scoring authority), with the typical vector:

AV:L / AC:(L or H) / PR:L / UI:N / S:U / C:H / I:H / A:H (NVD)

Cloud security vendor Wiz highlights a few important meta-facts:(wiz.io)

• It affects multiple supported Windows versions, both client and server.
• It is classified as CWE-367 (TOCTOU Race Condition).
• It is already associated with public exploit code and considered “high value” because it delivers SYSTEM on a very common feature stack (OneDrive / Files On-Demand).

Multiple advisories (Wiz, Tenable, H-ISAC) note that CVE-2025-55680 is yet another entry in a line of Cloud Files Mini Filter vulnerabilities that have shipped since 2022.(wiz.io) For teams maintaining large Windows fleets or VDI farms, this family of issues should now be treated as a standing risk category, not a one-off bug.

What the Cloud Files Mini Filter Actually Does

To understand the bug, you have to understand what the driver does in the first place. The Cloud Files Mini Filter (cldflt.sys) is part of the Windows cloud sync stack. It underpins features such as OneDrive Files On-Demand, where files can exist locally as “placeholders” and hydrate from the cloud when accessed.(Exodus Intelligence)

At a high level:

• A sync provider registers a sync root via CfRegisterSyncRoot in cldapi.dll.
• Under that root, files can be: fully hydrated, pinned, or placeholders that only hydrate on use.
• User-mode APIs such as CfCreatePlaceholders drive the creation of these placeholder entries.
• In the kernel, cldflt.sys intercepts I/O and manages these operations, including creating files and directories via FltCreateFileEx2.

The vulnerability sits right in the path where user-supplied filenames for placeholders are validated and turned into real kernel-mode file creations.

Root Cause: A Classic TOCTOU Race in a Modern Sync Stack

Exodus Intelligence published a detailed technical analysis of CVE-2025-55680, walking through how the bug arises inside the HsmpOpCreatePlaceholders() function in cldflt.sys.(Exodus Intelligence)

In simplified terms:

1. User-mode code invokes CfCreatePlaceholders() to create one or more placeholder files under a sync root.
2. In the filter driver, HsmpOpCreatePlaceholders() receives an I/O control (IOCTL 0x903BC) with a buffer that includes a relative filename field (relName).
3. The driver:
   • Probes and maps the user buffer into kernel space (using an MDL and MmMapLockedPagesSpecifyCache).
   • Iterates through relName to ensure it does not contain forbidden characters like \\ or : (a mitigation introduced after an earlier CVE).
4. If validation passes, the driver prepares OBJECT_ATTRIBUTES and calls FltCreateFileEx2() to create the file, using the validated filename and a root directory handle derived from the sync root.

The bug is in steps 3–4: there is a time window between validating the user buffer and using it in FltCreateFileEx2(), during which the attacker can modify the same mapped memory from user mode. Because the kernel and user views share the physical page, any change in the user buffer is reflected in the kernel’s pointer as well.(Exodus Intelligence)

Expressed in pseudocode, the logic looks roughly like this:

// Pseudocode, simplified for illustration
NTSTATUS HsmpOpCreatePlaceholders(USER_BUFFER* userBuf) {
    // Map user buffer into kernel space
    KERNEL_VIEW* kview = MapUserBuffer(userBuf);

    WCHAR* relName = kview->relName;

    // 1. Validate filename: reject '\\' and ':' characters
    if (contains_forbidden_chars(relName)) {
        return STATUS_INVALID_PARAMETER;
    }

    // 2. Build OBJECT_ATTRIBUTES with RootDirectory = sync root
    OBJECT_ATTRIBUTES oa = {0};
    oa.RootDirectory = SyncRootHandle;
    oa.ObjectName    = relName; // still pointing into mapped user memory

    // 3. Create the file
    return FltCreateFileEx2(..., &oa, IO_IGNORE_SHARE_ACCESS_CHECK, ...);
}

The TOCTOU is clear: contains_forbidden_chars(relName) reads the string once and decides it is safe, but there is no guarantee that relName remains the same string by the time FltCreateFileEx2() runs.

By carefully racing that window, an attacker can:

• Pass validation with something that looks like a benign relative name under the sync root, e.g. JUSTASTRINGDnewfile.dll, and then
• Flip one character in the mapped buffer so that by the time the file is created it becomes JUSTASTRING\\newfile.dll, where JUSTASTRING is a junction or symlink pointing into a privileged directory such as C:\\Windows\\System32.(Exodus Intelligence)

Because the file creation path does not enforce additional safeguards around symlinks or junction traversal, the driver ends up creating an attacker-controlled file in a location that should not be writable by a low-privileged user.

Exploitation Model: From Low-Priv Shell to SYSTEM

Exodus and multiple news outlets outline an exploitation model that is technically non-trivial but very realistic for a determined attacker or red team:(Exodus Intelligence)

1. Environment setup
   • Register a sync root directory using CfRegisterSyncRoot.
   • Create a directory under that root (e.g. JUSTASTRING) and make it a junction to a high-value target directory (e.g. C:\\Windows\\System32).
2. Race orchestration
   • Use multiple threads to:
     • Continuously issue placeholder creation requests (CfCreatePlaceholders → IOCTL 0x903BC) with a “safe” relative name.
     • Continuously flip one byte in the mapped filename buffer to introduce or remove a \\ at just the right moment.
     • Monitor whether the target file (e.g. System32\\newfile.dll) has appeared.
3. Privilege escalation via DLL hijacking
   • Once an arbitrary DLL or executable has been dropped into a privileged directory, use a known DLL sideloading or service hijack vector to get code running with SYSTEM privileges.
4. Cleanup
   • Remove traces such as the junction and temporary files to reduce forensic artifacts.

From a defender’s point of view, this translates into a chain of observable behaviors rather than a single “exploit event.” The following table summarizes the stages:

None of these are exotic for modern EDRs or DFIR teams, but they require correlating seemingly innocuous operations (cloud sync configuration, junctions, placeholder churn) with the creation of a single “weird” DLL.

Defensive View: Detection, Hardening, and Patch Strategy

The obvious first step is still the most effective one: apply Microsoft’s October 2025 Patch Tuesday updates that remediate CVE-2025-55680.(Cyber Security News)

However, patching alone does not answer the operational questions security engineers usually care about:

• Where in my estate could this bug have been exploited before patching?
• Which systems are still lagging behind on updates?
• What telemetry would actually fire if someone tried it?

Host and EDR Telemetry

From an endpoint perspective, it is worth tuning detection and hunting around:

• Abnormal Cloud Files behavior
  • Rare or one-off sync root registrations on servers or high-value workstations.
  • Unexpected IOCTL 0x903BC volume on systems that are not heavy OneDrive users.(Cyber Security News)
• Junction and symlink abuse
  • Junctions created from user-writable paths into privileged directories (System32, Program Files, etc.).
• Suspicious file creation in privileged directories
  • New DLLs or executables in System32 or other OS directories with non-standard names or compiled recently.
  • Correlations between such creations and high-frequency activity in cldflt.sys.

Mapping this to MITRE ATT&CK, CVE-2025-55680 is a vehicle to achieve techniques like T1068 (Exploitation for Privilege Escalation) and then pivot into service or DLL hijacking for persistence.

Architectural and Policy Mitigations

Beyond patching and detection, consider:

H-ISAC and other industry groups have already published threat bulletins pointing out that PoC exploits are available and encouraging rapid patching and targeted monitoring.(American Hospital Association)

Why CVE-2025-55680 Matters for AI-Powered Pentesting

CVE-2025-55680 also illustrates a more general pain point: by the time a security team hears about a fresh Cloud Files privilege escalation, public PoCs are often either unavailable, incomplete, or deliberately redacted. Yet the hard question is not “does the CVE exist” but:

“Can an attacker meaningfully use CVE-2025-55680 in our environment, on our endpoints, with our EDR and hardening in place?”

Answering that requires:

• Understanding the exact preconditions (Cloud Files enabled, OneDrive usage, junction creation capabilities).
• Translating advisory language into a concrete exploitation attempt in a controlled lab.
• Capturing evidence (logs, created files, process trees) to prove impact or demonstrate that existing controls block it.

This is where AI-assisted pentest tooling starts to look less like hype and more like a pragmatic way to close the loop between vulnerability feeds and real-world risk.

One-Click PoC Triage with Penligent

Platforms like Penligent are designed to automate exactly that kind of reasoning. For a CVE such as CVE-2025-55680, a typical AI-driven workflow looks like:

1. Ingest structured intelligence
   • Pull the NVD / CVE.org entry, MSRC advisory, and technical analyses (Exodus, Wiz, CyberPress).(NVD)
   • Extract constraints: local auth required, Cloud Files enabled, junction-based path manipulation, race around HsmpOpCreatePlaceholders and FltCreateFileEx2.
2. Map to the actual target environment
   • Identify Windows hosts that run cldflt.sys with Cloud Files / OneDrive enabled.
   • Check whether sync roots and relevant policies exist on those machines.
3. Synthesize a controlled PoC scenario
   • Generate skeleton exploit logic that registers a test sync root, sets up a benign junction, and attempts a placeholder-based file creation race only inside an isolated lab environment.
   • Instrument it heavily with logging so defenders get maximum observability rather than a black-box exploit.

Here is what such a non-weaponized skeleton might look like conceptually:

# Pseudocode: race harness (for lab validation only, not a full exploit)
def run_lab_race(target_path):
    shared = create_mapped_buffer(initial_name="SAFEPLACEHOLDER")
    stop_flag = False

    def creator_thread():
        while not stop_flag:
            issue_placeholder_ioctl(shared)

    def flipper_thread():
        while not stop_flag:
            flip_buffer_byte(shared)
            tiny_sleep()

    def monitor_thread():
        while not stop_flag:
            if privileged_file_exists(target_path):
                log("[+] Potential race won, file created at", target_path)
                stop_flag = True

    start_threads([creator_thread, flipper_thread, monitor_thread])

The point is not to ship another copy-paste exploit, but to let the system reason from natural-language advisories to code structure, then let human operators decide how and where to run it.

1. Capture evidence and generate a report
   • If the race succeeds, Penligent can automatically collect:
     • File system artifacts (which file was created where).
     • Relevant Windows events and ETW traces.
     • A narrative explaining impact and recommended remediations.
   • If it fails under realistic conditions, that is also valuable: it tells you that your patching and hardening are doing their job.

From CVE Feed to Validated Impact

Most organizations now ingest vulnerability feeds and Patch Tuesday bulletins automatically. The gap is between listing CVEs and ranking them by validated exploitability in your environment.

By combining structured sources like NVD and MSRC with deep technical write-ups such as Exodus’ Cloud Files research, and then letting an AI-driven engine orchestrate the code and experiments, you can:

• Treat CVE-2025-55680 not just as an entry in a spreadsheet, but as a specific, tested risk on specific machines.
• Build detections and dashboards around observed exploit behavior, not just speculation.
• Reuse the same pipeline the next time the Cloud Files Mini Filter (or any similar kernel-adjacent stack) shows up in Patch Tuesday.

Penligent’s goal in this space is simple: turn CVEs like CVE-2025-55680 into concrete, evidence-backed answers to “are we actually at risk, and where?”—without expecting every engineer to reverse-engineer kernel drivers and hand-craft PoCs from scratch.

• Cyber Security News
• Cyber Security News
• American Hospital Association
• American Hospital Association