CVE-2026-50656 (RoguePlanet): Dissecting the Defender Race Condition That Hands You a SYSTEM Shell

Your antivirus runs as SYSTEM. It parses hostile input for a living. It has to open, read, analyze, and remediate files that attackers control, using the highest privilege level the operating system offers. And when its remediation pipeline trusts a file path across two separate operations without holding an exclusive lock between them, a standard user can hijack that privileged write to replace a system binary and pop a SYSTEM shell. That is RoguePlanet. That is CVE-2026-50656. And as of this writing, it remains unpatched with a public proof-of-concept that works whether Defender’s real-time protection is on or off.

A quick correction before we go further: the CVE identifier floating around in some early discussions as “CVE-2026-45659” does not exist in any public record. The correct identifier, confirmed by Microsoft’s advisory, NVD, and every credible source, is CVE-2026-50656. Similarly, calling this the “fifth Chaotic Eclipse Defender zero-day” requires some creative counting. The researcher’s confirmed Defender-specific releases include BlueHammer (CVE-2026-33825), RedSun (CVE-2026-41091), UnDefend (CVE-2026-45498), and now RoguePlanet. The broader Nightmare Eclipse / Chaotic Eclipse series includes non-Defender targets like BitLocker (YellowKey) and CTFMON (GreenPlasma), so the ordinal depends on what you’re counting. I’ll skip the numbering game and focus on the mechanics.

The Attack Surface Nobody Thinks About

Every security vendor tells you to run their endpoint agent. That agent runs as SYSTEM or root. It registers kernel callbacks, intercepts every file I/O operation, and parses file formats designed to be adversarial. This is the fundamental tension at the heart of endpoint security: the component meant to protect you must, by design, accept and process attacker-controlled input at the highest privilege level available.

CWE-59 (Improper Link Resolution Before File Access) has been a recurring theme in security product vulnerabilities for years. The pattern is always the same: a privileged process evaluates a path at time T1, then re-accesses that path at time T2, and the attacker swaps what the path points to in between. When the privileged process is your antivirus engine running as SYSTEM, the consequence is local privilege escalation.

RoguePlanet is the latest in a series of disclosures that exploit exactly this class of bug in Microsoft Defender. BlueHammer (CVE-2026-33825) targeted a similar remediation-path trust issue. RedSun (CVE-2026-41091) exploited a different phase of the scan pipeline. UnDefend (CVE-2026-45498) attacked Defender’s ability to protect itself. Each time, the root cause is structurally identical: a TOCTOU gap in a SYSTEM-privileged file operation, weaponized through NTFS filesystem primitives (junctions, reparse points, oplocks) that any standard user can create.

Microsoft’s own CVSS 4.0 score for RoguePlanet is 7.8 with low attack complexity. NVD independently scores it 7.0 with high attack complexity. The divergence likely reflects NVD weighting the race condition aspect more heavily, while Microsoft’s score reflects the practical reality that the race is made deterministic through oplock abuse. Microsoft’s Exploitability Index marks it as “Exploitation More Likely,” which is their way of saying: someone will use this in the wild. Given the public PoC, “will” may already be past tense.

Microsoft Defender Internals: The Scan Dispatch Model

To understand where the race lives, you need to understand how Defender’s components interact. The architecture splits across kernel mode and user mode, with an RPC bridge between them.

Kernel-Mode Components

WdFilter.sys is the main event. It registers as a filesystem minifilter driver at a high altitude in the FSFilter Anti-Virus group. Every file I/O operation on the system passes through WdFilter’s pre-operation and post-operation callbacks. When WdFilter sees a file create, write, or rename that matches its interest criteria, it signals the user-mode engine for a scan. It also registers process-creation notification routines (PsSetCreateProcessNotifyRoutineEx) and image-load notification routines (PsSetLoadImageNotifyRoutine).

WdNisDrv.sys handles network inspection via the Windows Filtering Platform. It’s not directly involved in the RoguePlanet chain, but it’s worth knowing it exists because it’s another kernel-mode attack surface in the same product.

User-Mode Components

MsMpEng.exe is the main antimalware service host. It runs as NT AUTHORITY\SYSTEM with Protected Process Light (PPL) protection, meaning even administrators cannot inject into it or attach a debugger without first elevating to PPL-WinSystem (tools like PPLControl exist for research purposes). This is where scan dispatch threads live.

mpengine.dll is the engine itself: roughly 19 MB of scanners, emulators, signature loaders, and I/O abstraction APIs. When a scan request arrives, mpengine’s internal thread pool picks it up, parses the target file through its format-specific unpacking and emulation modules, evaluates signatures from the VDM file, and if a threat is found, executes the configured remediation action.

The internal mpengine!SysIO* APIs are the I/O abstraction layer that mpengine uses for all file operations. A mid-May 2026 Defender engine update changed these APIs in ways that broke junction-based techniques from earlier exploits. The researcher had to rewrite RoguePlanet’s approach in response. This is worth noting because it illustrates the whack-a-mole dynamic: Microsoft hardens one I/O path, the researcher finds another.

MpClient.dll is the component that makes RoguePlanet possible from a trigger perspective. It implements RPC client stubs for communicating with the MsMpEng service. Its exported functions include MpManagerOpen, MpScanStart, MpScanResult, MpThreatOpen, MpThreatEnumerate, MpCleanOpen, MpCleanStart, and MpHandleClose. These are undocumented, but they’re exported by name from a DLL that any process can load. The PoC loads MpClient.dll directly, resolves these functions, and uses them to programmatically instruct Defender to scan a file, confirm the detection, and initiate remediation. The scan doesn’t execute in the calling process. MpClient sends an RPC request, and the exported rsignal function initiates the actual scan within MsMpEng.exe‘s copy of mpengine.dll.

This is the key architectural detail: a standard user can load MpClient.dll and tell SYSTEM-privileged MsMpEng.exe to perform a file remediation operation. The remediation is the privileged file write. The attacker controls what file gets written where.

TOCTOU Anatomy: Where the Race Window Lives

CWE-59 from first principles: a process resolves a filesystem path to identify a resource, then later re-accesses that same path to operate on the resource. If an attacker can change what the path points to between those two moments, the process operates on a different resource than the one it validated.

In Defender’s remediation pipeline, the sequence is:

1. MpScanStart evaluates the target file at a given path, determines it contains malware (in this case, EICAR).
2. MpScanResult confirms the detection to the caller.
3. MpCleanStart initiates remediation, which involves multiple privileged file operations: creating a VSS snapshot for rollback capability, opening the file again by path, and performing the configured cleanup action (quarantine, remove, or restore a clean version).

The gap between steps 2 and 3, and within step 3 itself, is the race window. Defender does not hold an exclusive handle on the target file across the entire scan-to-remediation pipeline. It evaluates the path, releases its grip, then re-opens the path for remediation. During that interval, the attacker substitutes the target.

But “interval” makes it sound like a microsecond gamble. It isn’t. The remediation pipeline’s own behavior creates a predictable timing signal: VSS snapshot creation. When Defender begins remediation, it deterministically creates a Volume Shadow Copy. The exploit watches for this event by polling NtQueryDirectoryObject on the \Device\ namespace, looking for new HarddiskVolumeShadowCopy* entries. When the VSS device appears, the exploit knows exactly where Defender is in its pipeline, without guessing.

Making the Race Deterministic: Oplocks, VSS Timing, and I/O Pressure

A race condition you can only win 1% of the time is a crash bug. A race condition you can win 100% of the time is an exploit. RoguePlanet bridges that gap with three mechanisms working in concert.

Opportunistic Locks (Oplocks)

Windows NTFS supports opportunistic locks: a mechanism originally designed for SMB file-sharing optimization that lets a process request notification before another process accesses a file. When you hold an oplock on a file and another process opens that file, the filesystem pauses the second process’s I/O operation and notifies the oplock holder. The holder can then perform whatever work it needs (flush caches, in the legitimate use case) before acknowledging the break, at which point the paused process resumes.

RoguePlanet abuses this by placing an oplock on an alternate data stream (ADS) of the staged file, using the syntax :WDFOO. The ADS path goes through a VSS snapshot path (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\...\wermgr.exe:WDFOO), which gives the exploit a stable read-side handle even while the primary data stream is being manipulated. When Defender’s remediation thread reaches this file path, the oplock fires. Defender’s thread is now paused inside FsRtlOplockFsctrl in the kernel, waiting for the oplock break acknowledgment. The exploit has converted a microsecond TOCTOU window into a window it controls completely: Defender doesn’t resume until the exploit says so.

VSS as a Synchronization Primitive

The VSS snapshot creation during remediation serves double duty for the attacker. First, it’s a timing signal: the NtQueryDirectoryObject polling loop on \Device\ detects the new HarddiskVolumeShadowCopy* device and knows remediation has begun. Second, the VSS path provides a stable reference to the staged file that survives the directory junction manipulations happening on the live filesystem. The exploit constructs its ADS oplock path through the VSS volume, ensuring the handle remains valid even as the live path gets redirected.

I/O Pressure Threads

On machines with more than three logical cores, the exploit spawns one generator thread producing random data via the system cryptographic RNG and one worker thread per core continuously writing that data to unique temp files. These threads are held dormant on a Windows event object until the oplock-placement phase, then signaled to begin. Their purpose is to create sustained I/O and CPU scheduler pressure, making thread scheduling behavior predictable rather than dependent on whatever else the system happens to be doing. This is a reliability optimization: on a quiet system, the OS scheduler might context-switch at inconvenient times. Under controlled I/O load, the timing becomes reproducible.

// Pseudocode: I/O pressure thread pattern
DWORD WINAPI IoPressureWorker(LPVOID ctx) {
    PressureCtx *p = (PressureCtx *)ctx;
    BYTE buf[4096];

    // Wait for signal to begin pressure
    WaitForSingleObject(p->hStartEvent, INFINITE);

    while (!p->bStop) {
        // Write random data to unique temp file in tight loop
        BCryptGenRandom(NULL, buf, sizeof(buf), 
                        BCRYPT_USE_SYSTEM_PREFERRED_RNG);
        HANDLE hFile = CreateFileW(p->wszTempPath, GENERIC_WRITE,
                                   0, NULL, CREATE_ALWAYS, 
                                   FILE_FLAG_DELETE_ON_CLOSE, NULL);
        if (hFile != INVALID_HANDLE_VALUE) {
            WriteFile(hFile, buf, sizeof(buf), NULL, NULL);
            CloseHandle(hFile);
        }
    }
    return 0;
}

In WinDbg, attached to MsMpEng.exe, you can observe the oplock-induced pause directly:

~* k

One of the scan dispatch threads will show a call stack bottoming out in FsRtlOplockFsctrl or FltCheckOplock, meaning it’s suspended waiting for the oplock break acknowledgment. That thread stays frozen until the exploit completes its junction swaps and releases the oplock.

The Full Exploitation Chain

The following walkthrough describes the mechanism of the public PoC at a conceptual level. The binary is self-referential: an IsRunningAsLocalSystem check at entry determines whether it’s running as the unprivileged orchestrator or the SYSTEM-privilege payload. One binary, two roles.

Phase 1: Staging the Lure

The exploit extracts an embedded ISO image from its own .data section and mounts it using OpenVirtualDisk / AttachVirtualDisk with the ATTACH_VIRTUAL_DISK_FLAG_NO_DRIVE_LETTER flag. This creates a read-only virtual disk without assigning it a drive letter, making it invisible to casual observation. The ISO contains a fake wermgr.exe that’s actually a ZIP archive containing the EICAR test string, which Defender will reliably detect as malicious.

The exploit copies this fake wermgr.exe into a controlled directory structure: %TEMP%\RP_<UUID>\System32\wermgr.exe. It then creates an alternate data stream named :WDFOO on this file. Finally, it creates a named pipe at \\.\pipe\RoguePlanet and issues a blocking ConnectNamedPipe call that will wait for the SYSTEM-privilege instance to call back.

A critical note on server SKUs: the public PoC does not work on Windows Server because standard users cannot mount ISO images via AttachVirtualDisk. The vulnerability exists in the engine on Server, but the PoC’s specific delivery mechanism requires a client OS. This is a PoC limitation, not a vulnerability limitation.

Phase 2: Triggering the Scan

The exploit loads MpClient.dll from Defender’s platform directory under C:\ProgramData\Microsoft\Windows Defender\Platform\ and dynamically resolves the undocumented RPC client functions. It calls MpManagerOpen to get an engine handle, MpScanStart targeting the staged EICAR file, then MpScanResult to confirm Defender identified it as malicious. Then it calls MpCleanOpen and MpCleanStart to initiate remediation.

This is why real-time protection state doesn’t matter. The PoC doesn’t wait for WdFilter’s minifilter callbacks to trigger a scan passively. It actively instructs the engine to scan and remediate via the RPC client interface. Whether real-time protection is enabled or disabled, MpClient.dll‘s RPC stubs still reach MsMpEng.exe, and the engine still performs the requested scan and remediation. The protection toggle gates automatic scanning of new files, not the programmatic scan API.

Phase 3: VSS Synchronization

A dedicated thread polls NtQueryDirectoryObject on \Device\, watching for new HarddiskVolumeShadowCopy* entries. When Defender’s remediation creates its rollback snapshot, the exploit detects the new device and constructs the VSS-relative path to the staged file’s ADS: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopyN\...\RP_<UUID>\System32\wermgr.exe:WDFOO.

Phase 4: The Deterministic Pause

The exploit opens a handle to the ADS through the VSS path and requests an exclusive opportunistic lock. It then signals the I/O pressure threads to begin, and calls WaitForSingleObject on the oplock break event. When Defender’s remediation thread reaches the file, the oplock fires: the kernel pauses Defender and notifies the exploit. The race window is now open and stays open as long as the exploit needs.

Phase 5: The Three-Stage Junction Swap

With Defender paused, the exploit performs three junction redirections using NtSetInformationFile with FileRenameInformationEx (operating on kernel handles, not Win32 paths):

Swap 1: Convert the %TEMP%\RP_<UUID>\System32\ directory into an NTFS junction (IO_REPARSE_TAG_MOUNT_POINT) targeting the mounted ISO device. When Defender resumes and re-reads the path, it sees the ISO’s read-only content.

Swap 2: Monitor for Defender’s creation of a remediation temp file (a 24-character filename pattern under C:\Windows) via ReadDirectoryChangesW. Rename the staged directories to retarget the junction from the ISO to a new temp directory, then write a fresh EICAR archive through the redirected path.

Swap 3: Retarget the parent directory junction to C:\Windows. Defender’s privileged rename/restore operation now resolves to C:\Windows\System32\wermgr.exe. The exploit writes its own executable bytes into the captured temp filename. The result: MsMpEng.exe, running as SYSTEM, has written the attacker’s binary to C:\Windows\System32\wermgr.exe.

The exploit releases the oplock. Defender resumes and completes its remediation operation, unaware that it just planted the attacker’s payload in System32.

Phase 6: SYSTEM Execution

The exploit connects to the Task Scheduler via COM (ITaskService) and triggers the \Microsoft\Windows\Windows Error Reporting\QueueReporting scheduled task. This task is accessible to standard users via the Task Scheduler COM interface and executes C:\Windows\System32\wermgr.exe as NT AUTHORITY\SYSTEM.

The replaced wermgr.exe is the exploit’s own binary. It detects IsRunningAsLocalSystem == TRUE, spawns cmd.exe with the SYSTEM token, and calls back through \\.\pipe\RoguePlanet. The orchestrator receives the connection, duplicates the SYSTEM token, and launches conhost.exe with full SYSTEM privileges.

C:\> whoami
nt authority\system

Lab Reproduction Guidance

Set up a fully updated Windows 11 Pro VM (Hyper-V or VMware) with Defender enabled and real-time protection on. Create a standard, non-admin user account. Install Sysmon v15+ with a configuration that captures Event IDs 1, 11, 17, 18, and 23. Run Process Monitor filtered on MsMpEng.exe with path filters for wermgr and RP_.

For WinDbg attachment to MsMpEng.exe, you need to bypass PPL. The InfoGuard PPLControl methodology allows elevating a debugger process to PPL-WinSystem, after which you can attach to the protected process. In a kernel debugger session:

.process /r /p <MsMpEng EPROCESS address>
!handle 0 3 <MsMpEng PID>
bp ntdll!NtFsControlFile

The instructive exercise is observing both a failed and successful race. In a failed race, ~* k in WinDbg will show Defender’s scan dispatch thread returning from the file access before the exploit completes its junction swap. The remediation operates on the original file, and the exploit achieves nothing. In a successful race, you’ll see the thread paused in FsRtlOplockFsctrl, the junction swaps completing while it’s frozen, and the remediation writing to the redirected path.

Process Monitor gives the clearest visual of the junction swap: filter on MsMpEng.exe operations on paths containing System32\wermgr, and you’ll see the path resolution change between the scan and remediation phases.

Detection That Doesn’t Rely on the Broken Detector

This section matters more than the exploitation mechanics. Microsoft Defender’s signature engine does detect the compiled PoC as Exploit:Win32/DfndrRugPlnt.BB, but the researcher explicitly noted that small source modifications bypass this detection entirely. You cannot rely on the product that’s being exploited to detect its own exploitation. Detection must come from telemetry sources orthogonal to Defender.

Highest-Fidelity Behavioral Signals

Supporting Hunting Signals

Sigma Rule: MsMpEng Spawning Shell Process

title: RoguePlanet - Shell Process Spawned by MsMpEng.exe
id: 8f3a2d17-e5c4-4b91-a6d8-9c7e0f4b2a15
status: experimental
description: >
  Detects cmd.exe, powershell.exe, or conhost.exe spawned with
  MsMpEng.exe as parent process, indicating successful exploitation
  of CVE-2026-50656 (RoguePlanet) or similar Defender LPE.
references:
  - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50656
author: GenXCyber
date: 2026/07/03
tags:
  - attack.privilege_escalation
  - attack.t1068
  - attack.t1574.010
  - cve.2026.50656
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    ParentImage|endswith: '\MsMpEng.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\conhost.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
  condition: selection
falsepositives:
  - None known; MsMpEng.exe should never spawn interactive shells
level: critical

KQL for MDE / Sentinel

// Detect wermgr.exe replacement
DeviceFileEvents
| where FileName =~ "wermgr.exe"
| where FolderPath has @"\Windows\System32"
| where ActionType in ("FileCreated", "FileModified")
| where InitiatingProcessFileName !in ("TrustedInstaller.exe", "TiWorker.exe")
| project Timestamp, DeviceName, InitiatingProcessFileName, 
          InitiatingProcessAccountName, SHA256

// Detect QueueReporting task triggered by non-SYSTEM
DeviceProcessEvents
| where ProcessCommandLine has "QueueReporting"
| where InitiatingProcessAccountSid !startswith "S-1-5-18"
| project Timestamp, DeviceName, AccountName, ProcessCommandLine

Key ETW Providers for Out-of-Band Monitoring

Ensure these are forwarded to a SIEM that is not Defender-dependent. If your detection pipeline runs through Microsoft Defender for Endpoint exclusively, you have a single point of failure for exactly this class of vulnerability. Layer Sysmon, a standalone ETW consumer, or a third-party EDR alongside MDE.

MITRE ATT&CK Mapping

The Structural Absurdity

Let’s be direct about what’s happening here. Microsoft Defender’s threat model requires it to parse files submitted by potentially hostile local users, using the highest privilege the OS offers, through a codebase (mpengine.dll) that’s roughly 19 MB of complex parsing logic. The remediation pipeline must perform privileged file operations on paths influenced by the same users it’s protecting against. PPL protects MsMpEng.exe from injection and debugging by administrators, but it does nothing to prevent CWE-59. PPL stops you from attaching to the process; it doesn’t stop the process from following a junction you placed in its path.

The mid-May mpengine!SysIO* API changes that broke earlier junction-based techniques are evidence of incremental hardening, but they’re also evidence of the whack-a-mole problem. Each patch addresses one specific I/O path. The underlying architecture, where a SYSTEM-privileged process performs file operations on user-influenced paths without atomic check-and-use semantics, remains intact. The researcher adapts and finds the next gap.

The structurally sound fix is architectural: scan and remediate inside an unprivileged sandbox, then broker the result to a minimal privileged component that validates the operation before executing it. Chromium’s multi-process model, where the renderer (parser of hostile input) runs at low integrity and can’t touch the filesystem directly, is the template. Defender partially does this with MsMpEngCP.exe (content process), but the remediation pipeline’s privileged file operations still run in the SYSTEM context of the main service.

Until the remediation pipeline itself is deprivileged, or until privileged file operations are performed with mandatory integrity checks that validate the target path hasn’t been redirected through a reparse point, this class of bug will keep appearing. The mpengine!SysIO* hardening is necessary but insufficient. What’s needed is something like FILE_OPEN_REPARSE_POINT_AWARE semantics enforced across the entire remediation code path, or a broker that resolves the final physical path and validates it against an allowlist before performing the write.

Mitigation Posture

As of early July 2026, no security update addresses CVE-2026-50656. The following mitigations reduce risk but do not eliminate the vulnerability:

Application allowlisting (AppLocker, WDAC): If wermgr.exe is constrained by a code integrity policy that requires Microsoft signatures, the replaced binary won’t execute even after the swap succeeds. This is the single most effective mitigation. ThreatLocker specifically validated that their allowlisting product blocks the execution phase.

Audit and alert on wermgr.exe replacement: Set a SACL on C:\Windows\System32\wermgr.exe for write/delete access by non-TrustedInstaller principals. Forward Security Event 4663 to your SIEM.

Disable the QueueReporting scheduled task: If your environment doesn’t rely on Windows Error Reporting’s scheduled queue processing, disabling this task removes the standard-user-accessible execution trigger. The vulnerability still exists, but the PoC’s specific privilege-escalation path is broken.

Reduce Defender’s remediation aggression: Configure Defender to quarantine rather than clean/restore. This doesn’t prevent the race, but it may alter the remediation code path enough to disrupt the specific junction swap sequence.

Layer detection: Deploy Sysmon, a standalone ETW consumer, or a second EDR product that provides process-creation and file-integrity telemetry independent of Defender. Your detection for a Defender bypass cannot rely solely on Defender.

Patch readiness: When the patch drops (likely as an engine update rather than a monthly cumulative update, given Microsoft’s history with mpengine fixes), validate it immediately. Confirm your Defender engine version is 1.1.2507.x or later (version number is speculative, but engine updates deploy via MpSigStub.exe and can be verified via Get-MpComputerStatus | Select AMEngineVersion).

Key Takeaways

• CVE-2026-50656 (RoguePlanet) is a TOCTOU race condition in Defender’s remediation pipeline, exploitable by standard users to achieve SYSTEM privilege escalation. It is unpatched with a public PoC as of July 2026.

• The race is made deterministic through NTFS opportunistic locks, VSS snapshot detection as a timing oracle, and I/O pressure threads. This is not a probabilistic exploit.

• Real-time protection state is irrelevant. The PoC actively invokes scan and remediation via MpClient.dll‘s RPC stubs rather than waiting for passive detection.

• Signature detection of the compiled PoC is trivially bypassed. The researcher confirmed that minor source modifications evade Exploit:Win32/DfndrRugPlnt.BB. Behavioral detection from non-Defender telemetry sources is mandatory.

• The highest-fidelity detection signal is MsMpEng.exe spawning a shell process (cmd.exe, conhost.exe). This should never happen in normal operation and warrants a critical-severity alert.

• Application allowlisting is the strongest available mitigation until a patch is released. A code integrity policy that enforces signature requirements on wermgr.exe blocks the execution phase regardless of whether the file replacement succeeds.

• The underlying architectural problem (SYSTEM-privileged file operations on user-influenced paths) will produce more CVEs until Microsoft either sandboxes the remediation pipeline or enforces reparse-point-aware path validation across all privileged I/O in the engine.

Your antivirus is the attack surface. Plan accordingly.

Related Tutorials

• Writing Your First Shellcode: x86 Reverse Shell from Scratch
• x86 and x64 Calling Conventions: cdecl, stdcall, fastcall, and System V
• System Calls and SSDT: How User Mode Reaches the Kernel
• Windows File System Internals (NTFS)

References

• MSRC