Windows MiniPlasma SYSTEM Privilege Escalation: No Patch, Public PoC

On May 17, 2026, a security researcher who goes by Chaotic Eclipse (also known as Nightmare Eclipse) published a working proof-of-concept exploit on GitHub for a Windows privilege-escalation flaw they dubbed MiniPlasma. The exploit takes any standard user account on a fully patched Windows 11 Pro endpoint and produces a command prompt running as NT AUTHORITY\SYSTEM. The underlying CVE, CVE-2020-17103, was originally reported to Microsoft by Google Project Zero researcher James Forshaw in September 2020. Microsoft assigned the CVE and reported a fix in December 2020.

The researcher's claim — and it is the part of this story worth reading carefully — is that the December 2020 patch did not fully resolve the underlying issue, and that the same exploitation path still works on a current build of Windows 11. As of this writing Microsoft has not publicly responded to the re-disclosure. BleepingComputer reported on the publication.

This post is the operational read for a small business. What MiniPlasma actually does, why local privilege escalation matters more in 2026 than the same bug would have in 2020, and the controls that actually reduce the impact while we wait for a real patch.

What MiniPlasma actually does, in plain English

Windows has a kernel driver called the Cloud Filter Driver, cldflt.sys. It is what makes OneDrive Files On-Demand work: a placeholder file appears in your file system, you double-click it, the driver intercepts the access, OneDrive fetches the real content, and the file "hydrates" in place. The driver also handles the opposite case — aborting a hydration that is in progress — through an undocumented internal API named CfAbortHydration.

According to the researcher, the abort-hydration path can be coaxed into creating registry keys inside the .DEFAULT user hive without performing the access checks a normal registry write would require. The .DEFAULT hive is the registry template that Windows uses for the SYSTEM context, so a write into it lands in a location that influences code that runs as SYSTEM. From there the exploit chains into a payload that produces a SYSTEM shell. The pre-requisite is that the attacker is already running code on the box as a normal user. The bug does not let anyone remote into your machine.

In plain English: there is a back door in a Windows driver that lets a regular user write into a registry area that should only be writable by SYSTEM. Writing the right thing there gives the user SYSTEM. The patch Microsoft shipped in 2020 closed one path to this back door, but the researcher reports that the back door itself is still there.

Why local privilege escalation matters more in 2026 than in 2020

The instinct on a privilege escalation bug is to dismiss it as "second stage" — the attacker has to already be on the box, so what's the big deal. That framing made sense in 2020. It is much weaker in 2026, for three reasons.

The first-stage foothold is cheap now. The economics of credential theft, OAuth grants, drive-by browser exploits, and phishing have collapsed in the attacker's favor. The AI attack speed post covers this in detail. A working initial-access foothold on a target Windows 11 endpoint is an inexpensive commodity in 2026.

SYSTEM unlocks the rest of the chain. Most well-configured endpoints frustrate attackers at the user level. The EDR is running as SYSTEM and the attacker can't disable it. Credentials in LSASS are protected by Credential Guard and require SYSTEM to read. Persistence in the most reliable locations requires SYSTEM. Once SYSTEM is achievable on demand, every one of those frustrations disappears. The endpoint goes from "compromised user" to "fully owned."

Ransomware affiliates buy this stuff first. The brokered-credential pipeline this blog has been describing all month is also the brokered-exploit pipeline. A public, reliable user-to-SYSTEM primitive on a fully patched Windows 11 is the kind of capability that affiliates wire into their tooling within days. The post-foothold time-to-encrypt for a typical ransomware operator drops measurably once they don't have to engineer their own SYSTEM step.

The honest read is that this is one of the higher-impact unpatched-Windows-bugs of the year for SMBs, even though it is "only" privilege escalation. The pairing with the rest of the 2026 threat landscape is what makes it sharp.

The controls that actually reduce impact without a patch

Microsoft has not published a fix. They may or may not respond quickly. In the meantime, defense is layered. Three controls move the needle the most.

1. EDR that watches for the abuse pattern

The cldflt.sys exploitation pattern is detectable. The exploit needs to trigger registry writes into the .DEFAULT hive via a kernel driver interaction; a tuned EDR sees that as anomalous and can either alert or contain. The major endpoint products with credible coverage:

• Microsoft Defender for Endpoint, included with Microsoft 365 Business Premium. Confirm the Tamper Protection setting is enabled (so the SYSTEM-level attacker can't simply disable Defender after promotion) and that EDR in block mode is on. The Defender team typically ships a detection signature within hours of a public PoC like this one.
• SentinelOne, CrowdStrike, Huntress, Sophos Intercept X. All have credible kernel-driver-abuse telemetry. Confirm the policies on your endpoints include kernel anomaly detection, behavioral analytics, and tamper protection.

If your "EDR" today is consumer-grade antivirus or a legacy signature engine, this is the inflection point. The AI attack speed post covers the broader case for moving to a real EDR plus 24/7 MDR coverage.

2. Microsoft Defender Attack Surface Reduction (ASR) rules

ASR rules block the categories of behavior the attacker needs at the user level before they can chain into MiniPlasma. The high-value rules for this scenario are:

• Block credential stealing from the LSASS subsystem. Stops a SYSTEM-promoted process from dumping local credentials, which is the most common immediate next step.
• Block Office applications from creating child processes. Stops the macro-to-shell pivot that is still a top first-stage method.
• Block Win32 API calls from Office macros. Same theme, different surface.
• Block executable content from email and webmail clients. Stops the most common phishing-to-foothold step.
• Block JavaScript or VBScript from launching downloaded executable content. Stops the browser-to-shell pivot.

Enable these in audit mode first, watch for a week, then move to block mode. The legitimate-but-quirky line-of-business applications you discover during the audit window are the ones to handle individually with allowlist exceptions.

For Microsoft 365 Business Premium customers, the ASR rules are configurable from Intune or from the Defender portal. The PowerShell version, run on each endpoint:

Set-MpPreference -AttackSurfaceReductionRules_Ids `
  9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2,d4f940ab-401b-4efc-aadc-ad5f3c50688a `
  -AttackSurfaceReductionRules_Actions Enabled, Enabled

(Those two IDs are the credential-theft and Office-child-process rules respectively. The full ID list is on Microsoft Learn.)

3. Real least-privilege baselines

The third control is the slowest to put in place and the highest-impact in the long run. A SYSTEM-level promotion on a workstation is bad. A SYSTEM-level promotion on a server that hosts domain-joined services, or on an endpoint where a domain admin is also logged in, is catastrophic. The mitigations:

• No standing local administrator accounts on workstations. Use LAPS or Intune-managed local admin rotation so that even a fully owned endpoint does not give the attacker a portable local admin credential.
• Domain administrators do not log in to workstations interactively. Ever. If your IT team's daily account is also Domain Admin, separate them this week. The identity hardening post covers the pattern.
• Tier the environment. Workstations are tier 2. Servers are tier 1. Domain controllers and identity infrastructure are tier 0. An attacker who lands SYSTEM on a tier-2 box should not be able to cross tier boundaries without doing more work and tripping more alerts.
• Microsoft 365 Business Premium ships Microsoft Intune, which lets you push these baselines without rebuilding endpoints from scratch.

What we are not recommending

A few things have been floated in community discussion that we are not recommending for SMB environments:

• Disabling cldflt.sys. The driver makes OneDrive Files On-Demand work. Turning it off breaks OneDrive in non-obvious ways and produces a wave of support tickets for users who can no longer access their files. The cure is worse than the disease at this severity level.
• Blocking the researcher's GitHub repository at the firewall. The PoC is already out, mirrored, and forked. Blocking the original URL does not reduce risk; it produces theater. Focus on detection and ASR rules.
• Waiting for a third-party hot patch. Some third parties (notably 0patch) have built businesses around micropatches for unpatched bugs. They are reasonable for environments that already use them. For SMBs that do not, signing up for a new vendor relationship in the middle of a fire drill rarely goes well. Pick the layered controls above and wait for Microsoft.

Where this fits with the rest of the cluster

This post pairs with several others published this month:

• The YellowKey & GreenPlasma post: same Windows-bypass theme, different bug class. The naming convention (Plasma, Mythos, Daybreak, etc.) is becoming an informal vocabulary in the security community for researcher-named Windows primitives.
• The AI attack speed post: the exact mechanism by which "second-stage only" bugs have become much more dangerous in 2026.
• The ransomware-how-it-gets-in post: MiniPlasma is the kind of primitive that gets bolted into ransomware affiliate tooling within days.
• The identity hardening post: tiered admin model and no-standing-local-admin guidance.
• The patch-cadence shift post: the broader argument for why operations-grade vulnerability management is now a daily function, not a quarterly one.

The honest read is the same as the rest of the month. Internet-exposed Microsoft platforms and now even local Windows endpoints require operations-grade vulnerability management to run safely in 2026. If you do not have someone whose job is to read a researcher's GitHub disclosure in the morning, decide whether it matters for your environment, and translate it into a punch list by lunch, that is the seat to fill.

FAQs about Windows MiniPlasma and CVE-2020-17103

What is MiniPlasma and why does the CVE date say 2020?

MiniPlasma is the name a researcher (Chaotic Eclipse, also known as Nightmare Eclipse) gave to a working exploit they published on May 17, 2026, for CVE-2020-17103. The 2020 part of the CVE identifier reflects when the bug was originally reported to Microsoft by Google Project Zero researcher James Forshaw. Microsoft assigned the CVE and reported a fix in December 2020. The researcher's claim is that the December 2020 patch did not fully address the underlying issue, and that the same exploitation path still works on a fully patched May 2026 build of Windows 11 Pro.

How serious is this for a small business?

MiniPlasma is local privilege escalation, not remote code execution. An attacker needs to already be running code as a normal user on the machine before they can use this exploit. That sounds reassuring, but in 2026 the initial user-level foothold is the cheap part of an attack chain. Phishing, browser exploits, and OAuth grants all give the attacker that level of access routinely. What MiniPlasma adds is a reliable way to go from user to SYSTEM on a fully patched Windows 11 endpoint with no Microsoft patch available, which is exactly the step that previously stopped a lot of intrusions on well-configured endpoints.

Is there a patch?

Not as of May 18, 2026. Microsoft has not publicly acknowledged the re-disclosure or committed to a new fix date. Until they do, defense is layered controls, not a patch.

What controls reduce the impact without a patch?

Three things move the needle the most. First, EDR that watches for unusual child processes of system processes and unusual interactions with cldflt.sys (the Cloud Filter driver). Microsoft Defender for Endpoint, SentinelOne, and CrowdStrike all have detections in this area; tune them. Second, application control or Attack Surface Reduction rules that block the categories of binary the exploit drops or stages. Microsoft Defender ASR rules covering credential stealing, Office child processes, and scripting hosts cover the typical pre-exploit step. Third, true least-privilege baselines for users on workstations, so that even a SYSTEM-level promotion does not cleanly unlock domain credentials or other tenants.

Should we just disable the Cloud Filter driver?

Probably not. The Cloud Filter driver is what makes OneDrive Files On-Demand and similar cloud-sync features work. Disabling it breaks OneDrive in non-obvious ways and produces a stream of support tickets. The maturity move is to keep the driver, layer EDR detections in front of the abused codepath, and wait for the proper patch from Microsoft.

How did this slip past Microsoft's 2020 fix?

That is the open question. The researcher's claim is that Microsoft's December 2020 patch addressed one specific reproduction path but did not fix the underlying access-check gap in the CfAbortHydration codepath. Microsoft has not publicly responded to the re-disclosure as of this writing. Either the original fix was scoped narrowly and the researcher found a sibling path, or the fix was incomplete. We will update this post if Microsoft confirms one way or the other.

Prefer to talk first? Email sales@ghosxt.com or call (831) 204-0501.