CVE-2025-21204 is a local privilege escalation flaw in the Windows Update Stack. By abusing directory junctions or symbolic links, attackers can hijack trusted paths accessed by SYSTEM-level processes like `MoUsoCoreWorker.exe` and execute arbitrary code with elevated privileges. A patch is available as of April 2025.

Every month, defenders scan through dozens of newly published CVEs—many of them obscure, low-impact, or impractical to weaponize. CVE management has become a checkbox exercise driven more by compliance than threat modeling in many organizations.

Security teams are often flooded with CVEs to triage, patch, or defer, each demanding time, context, and risk analysis. But for red teamers and adversaries, the goal isn’t to track CVEs—it’s to find the one CVE that changes everything.

The CVE-2025-21204 is precisely that kind of vulnerability. It doesn’t require a zero-day exploit or complex memory corruption chain. It doesn’t need a phishing campaign or a dropped malware loader. All it takes is: A misused filesystem trust, a writable folder, and a SYSTEM process doing what it was built to do.

This CVE is a masterclass in path abuse, trusted location redirection, and privilege escalation using native components — everything a red team loves and a blue team fears.

In red teaming, not all CVEs need to be flashy RCEs or kernel-level exploits. Sometimes, the most devastating results come from quiet privilege escalation vulnerabilities hiding in plain sight — those that blend into normal OS behavior and abuse trust rather than memory.

It doesn’t require sophisticated exploitation techniques, crash processes, or trigger EDR signatures. Instead, it leverages a design flaw—the assumption that specific file paths are always safe. This “low-level” CVE allows a non-admin user to escalate to SYSTEM by simply redirecting a trusted folder. There is no code injection, no exploit development, just a junction and timing.

Red teams love this kind of CVE because it:

• Bypasses most EDR heuristics (no exploit payloads or injection)

• Blends in with legitimate update behavior

• Is reliable in simulations and real environments

• Can be chained with initial access vectors (like phishing, misconfigured LAPS, or token theft) to establish full SYSTEM control

In short, low CVSS ≠ , low impact, and CVE-2025-21204 are reminders that a “simple” vulnerability, when used creatively, can compromise the whole box.

Windows Update Stack Privilege Escalation Vulnerability

CVE Details 

• CVE ID: CVE-2025-21204

• Published: April 2025 Patch Tuesday

• CVSS Score: 7.8 (High)

• Impact: Privilege Escalation

• Attack Vector: Local

• Exploitability: Low complexity, no user interaction

• Affected Component: Windows Update Stack (MoUsoCoreWorker.exe, UsoClient.exe)

• Patched Version: Available via Windows Update in April 2025 cumulative updates

 What’s in the box?

The vulnerability exists in the Windows Update Stack, which is responsible for checking, downloading, and installing updates via processes like:

• MoUsoCoreWorker.exe

• UsoClient.exe

These processes run as SYSTEM and access the path:

C:\ProgramData\Microsoft\UpdateStack\Tasks

Under vulnerable conditions, they may trust and execute files from this location without validating their origin, integrity, or ACLs.

What is the Potential?

If an attacker without admin rights can control the contents of this directory (directly or indirectly), they can:

• Drop a script, DLL, or binary in the path

• Wait for or trigger an update scan

• The SYSTEM process may load or execute the attacker’s file, giving them SYSTEM privileges

This is a classic trusted path abuse scenario, commonly seen in privilege escalation chains. Microsoft addressed this vulnerability by:

• Validating ownership and ACLs of files in the UpdateStack\Tasks path

• Ensuring SYSTEM processes only trust files owned by SYSTEM or trusted installers

• Possibly hardening or removing external file-based task definitions in the update stack.

It smells like IIS…

The New “inetpub” folder After the April 2025 Update

With the release of the April 2025 cumulative update (KB5055523) for Windows 10 and higher, there is a new folder at the root of the system drive: C:\inetpub. Traditionally associated with IIS. This folder’s unexpected appearance raised questions, especially on systems where IIS is not installed or enabled.

Initially undocumented in the official release notes, the empty and seemingly inactive inetpub folder led to user speculation about whether it was a leftover artifact from development or a bug. Microsoft has since clarified that the folder is intentional and part of a critical security improvement.

The change addresses CVE-2025-21204, a vulnerability that allowed local attackers to exploit symbolic link (symlink) attacks via Windows Update, potentially granting unauthorized access to protected system files or directories. As part of the fix, the system pre-creates certain directories — including C:\inetpub — to harden the update process and mitigate such attacks.

Key points to know:

• Presence is intentional: The folder does not indicate that IIS has been installed or activated. Its creation is part of a universal patch, independent of any web server configurations.

• Do not delete: Although the folder is empty and can technically be removed, doing so is not recommended. Its absence could compromise the integrity of the security fix applied.

• No action required: The folder has no performance or functional impact on the system. IT administrators and end users do not need to take any additional steps if it’s present.

• Have you deleted it? If you’ve already removed it, Microsoft recommends reinstalling the April 2025 cumulative update to ensure full protection. Alternatively, the folder will be restored with the next cumulative update.

In short, C:\inetpub is now a quiet but essential part of Windows’ broader security posture — not a cause for concern, but a symbol of enhanced protection against evolving threats.

Attack Breakdown

CVE-2025-21204 is a local privilege escalation bug in the Windows Update Stack. It occurs when SYSTEM-level update processes trust and execute scripts from locations that can be redirected or hijacked using NTFS junctions — without verifying ownership or integrity.

The Exploit Flow — PowerShell-Only SYSTEM Privilege Escalation

I crafted a PowerShell script that does the following:

• Creates a payload (updatehelper.ps1) inside C:\inetpub\wwwroot that adds a new local admin (redteam).

• Deletes C:\ProgramData\Microsoft\UpdateStack\Tasks (if it exists) and replaces it with a junction pointing to inetpub.

• Monitors for update processes like UsoClient.exe, MoUsoCoreWorker.exe, or TiWorker.exe.

• When detected, it deploys the junction, redirecting the Update Stack’s trusted code execution to the attacker’s payload.

When the SYSTEM-level process runs the hijacked script, privilege escalation is achieved without triggering AMSI, Defender, or WDAC.

This exploit isn’t just about CVE-2025-21204. It’s about what happens when trusted processes don’t validate file origins and how filesystem trust boundaries can be subverted with native tools.

This PowerShell-based PoC:

• Demonstrates the core logic of CVE-2025-21204

• Uses only native Windows mechanisms (no compilation or tools)

• Abuses update stack trust boundaries to escalate privileges

• Mirrors the exact exploitation path Microsoft’s advisory warns against

The attack chain in this script assumes that the Windows Update process improperly follows directory junctions (also known as NTFS mount points or symlinks) and executes scripts or files from user-controlled paths without enforcing privilege boundaries or validating ownership.

The script exploits this behavior by planting a PowerShell payload inside a trusted but misconfigured directory (C:\inetpub\wwwroot) and replacing a legitimate update-related directory (C:\ProgramData\Microsoft\UpdateStack\Tasks) with a junction pointing to the payload location. It then waits for update processes (like UsoClient.exe or TiWorker.exe) to activate, effectively allowing an unprivileged attacker to execute code as NT AUTHORITY\SYSTEM.

CVE-2025-21204 Exploit Simulation

This script Exploit-CVE2025-UpdateStackLPE-NonAdmin demonstrates a local privilege escalation technique using CVE-2025-21204, which abuses the Windows Update Stack’s failure to validate trusted paths. It simulates a SYSTEM level DLL payload execution using a redirection trick involving a writable folder and NTFS junctions.

Exploit a logic flaw in the Windows Update Stack (CVE-2025-21204) that fails to properly validate or resolve symbolic links (junctions) before executing or accessing content. The goal is to trick a SYSTEM process into executing a payload from a user-controlled location.

Initial Conditions

• Attacker runs as a standard user (non-admin)

• Target system has not yet created the folder:
  C:\ProgramData\Microsoft\UpdateStack\Tasks

• Windows Update process is expected to run (triggered manually or scheduled)

Payload Preparation

• A fake .dll payload is written to: C:\Users\<User>\AppData\Roaming\Microsoft\UpdateStack\Tasks\UpdateStackAgent.dll

• A second file (cve2025-proof.log) in C:\Users\Public\ is used as a proof-of-execution marker

• The payload simply writes a timestamped message to the proof file

Logging the Result

• If the payload was triggered by a SYSTEM process:

  • The owner of the proof file will be SYSTEM

  • The script logs a “vulnerable” verdict

  • Forensic logs are written to:

    • evidence.txt — timestamp and file owner

    • simulation.log — setup info and paths

    • vulnerable.txt — true or false based on outcome

• If no execution occurred, a “failed” result is logged instead

CVE-2025-21204 Detections

DeviceProcessEvents
| where FileName =~ “cmd.exe”
| where ProcessCommandLine has_all(“mklink”, “/J”)
| where ProcessCommandLine has “Microsoft\\UpdateStack”
| where ProcessCommandLine has_any(“AppData”, “Users”)
| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessParentFileName, ProcessCommandLine, FileName

DeviceProcessEvents

| where ProcessCommandLine has “Microsoft\\UpdateStack”

| where ProcessCommandLine has_any(“AppData”, “Users”)

| project Timestamp, DeviceName, InitiatingProcessAccountName, InitiatingProcessParentFileName, ProcessCommandLine, FileName

 

Summary