MiniPlasma PoC Questions KB5089549 Fix for CVE-2020-17103 on Win11

Microsoft’s May 12, 2026 Windows 11 security update KB5089549 is now under scrutiny after a public proof-of-concept called MiniPlasma claimed to revive CVE-2020-17103, a Windows Cloud Files Mini Filter Driver privilege-escalation flaw first addressed in December 2020. The uncomfortable part is not merely that another local privilege escalation exists; Windows has plenty of those. It is that the alleged bug lives in a component meant to make cloud-backed storage feel invisible, and the public exploit reportedly works on fully patched production systems. If confirmed by Microsoft, MiniPlasma would be a reminder that a “fixed” CVE is sometimes less a closed chapter than a regression test waiting to be written.

Security dashboard graphic showing Windows vulnerability CVE-2020-17103 with privilege escalation and patch status.MiniPlasma Turns a Patched Bug Into a Patch-Trust Problem​

The claim at the center of MiniPlasma is simple and damaging: a vulnerability Microsoft treated as resolved in 2020 may still be reachable in current Windows builds. The proof-of-concept targets cldflt.sys, the Windows Cloud Files Mini Filter Driver, and specifically behavior around the HsmOsBlockPlaceholderAccess routine. The researcher behind the release, known as Nightmare-Eclipse or Chaotic Eclipse, says the technique can plant arbitrary registry keys in the .DEFAULT user hive and use that foothold to escalate to SYSTEM.
That is not the same as a remote wormable catastrophe. MiniPlasma is described as a local privilege escalation, which means an attacker first needs code running on the machine. But in modern Windows intrusions, that is often exactly how the second act begins: phishing, stolen credentials, malicious installers, browser escapes, vulnerable drivers, or commodity malware get the initial execution, and then a kernel-adjacent privilege escalation turns a user-level compromise into system-wide control.
The most serious allegation is not that Microsoft missed a bug once. It is that the original Google Project Zero issue, tracked as CVE-2020-17103, was marked fixed years ago, while public testing now suggests the old exploit path or a closely related one may still function. If the researcher’s account is accurate, one of three things happened: the 2020 fix was too narrow, a later change reintroduced the vulnerable behavior, or the new proof-of-concept exploits the same conceptual weakness through a path Microsoft did not close.
For administrators, those distinctions matter less in the short term than the practical result. A fully patched Windows 11 machine is supposed to have absorbed years of hardening against exactly this class of issue. When a public PoC says otherwise, the patch level itself stops being a complete answer.

The Cloud Files Driver Is an Unfashionable Place for a High-Impact Bug​

cldflt.sys is not a flashy attack surface in the way browsers, VPNs, and exposed servers are flashy. It is a kernel-mode file system minifilter that helps Windows handle cloud-backed placeholder files, most visibly through OneDrive Files On-Demand and other Cloud Files API providers. Its job is to make a file that is not fully present on disk behave, to the user and to applications, as if it belongs there.
That illusion requires deep participation in file I/O. Minifilter drivers sit in the Windows storage stack, observe or modify file operations, and mediate behavior before requests reach the file system or storage device. That is powerful by design, and power in kernel-adjacent code is exactly why small logic errors can become consequential.
Cloud sync also creates a strange security boundary. A placeholder file is local enough for Explorer, Office, search indexing, and shell extensions to interact with it, but remote enough that hydration, access policy, and metadata can involve provider-specific state. Windows has to arbitrate between user expectations, app compatibility, and kernel enforcement. Every extra state transition is a place where assumptions can go stale.
That is why MiniPlasma is more interesting than its tabloid framing as a “deadly Registry hack.” The registry write is the visible payload; the deeper issue is the relationship between cloud-file policy code and privileged system behavior. A local attacker who can bend that relationship may not need to break cryptography or defeat virtualization-based security. They need Windows to trust the wrong operation at the wrong moment.

A Registry Write Is Boring Until It Belongs to SYSTEM​

The reported exploit path involves placing arbitrary registry keys under the .DEFAULT hive. That detail sounds obscure because it is, but obscure does not mean harmless. The Windows registry remains a sprawling control plane for services, logon behavior, shell initialization, COM registration, security policy, and countless compatibility mechanisms accumulated over decades.
Privilege escalation often looks anticlimactic in the lab. A researcher does not need to drop a rootkit or disable every protection to prove the point. Spawning a SYSTEM-level shell is the canonical demonstration because SYSTEM is the practical crown jewel on a local Windows box. Once there, an attacker can tamper with security tooling, access data outside the original user’s reach, install persistent services, manipulate credentials, and pivot through an enterprise environment.
The MiniPlasma documentation reportedly adapts the behavior into a SYSTEM shell, making the risk easy to understand even for those who do not live in WinDbg. But the exploit is also described as race-condition dependent. That means reliability may vary by hardware, load, Windows build, timing, and configuration.
Race conditions are sometimes dismissed because they are not perfectly deterministic. That is a mistake. Attackers are patient, and local privilege escalation bugs can be retried. If a PoC succeeds one out of ten times on a researcher’s test machine, a real attacker can loop it, tune it, or combine it with environmental knowledge until the odds improve.

KB5089549 Was Supposed to Be the Good News​

The timing is what makes this story sting. KB5089549 is the May 2026 cumulative security update for Windows 11 versions 24H2 and 25H2, bringing systems to OS builds 26100.8457 and 26200.8457. It landed as a normal Patch Tuesday release, the kind administrators are trained to deploy because cumulative updates are the baseline defense against known exploitation.
Now the same update is being discussed not for the vulnerabilities it fixed, but for one it allegedly did not. That does not mean KB5089549 caused MiniPlasma. The more precise concern is that systems updated through KB5089549 may still expose the vulnerable behavior. This is an important distinction, because uninstalling a security update is usually the wrong reflex when the complaint is “this patch did not fix an unrelated or revived bug.”
There is another complication: KB5089549 has already had its own operational noise, including reports of installation failures tied to systems with low EFI System Partition space. For IT teams, that creates an ugly collision of priorities. The patch may be necessary, the installation may be fragile on some machines, and the public security conversation now says “fully patched” may not mean fully protected.
This is the Patch Tuesday paradox in its most Windows-shaped form. Microsoft asks enterprises to trust a monthly train that updates the world’s most widely deployed desktop operating system under immense compatibility pressure. When the train works, nobody cheers. When a public exploit arrives days later, every prior pain point becomes part of the same trust ledger.

Microsoft’s Silence Leaves Administrators Managing a Shadow Advisory​

As of the current public reporting cycle, Microsoft had not yet issued a fresh advisory treating MiniPlasma as a newly assigned vulnerability. That may change quickly. The company could determine that the PoC works only under narrow conditions, that Insider builds already contain a fix, that the behavior maps to an already serviced issue, or that a new CVE and out-of-band mitigation are warranted.
In the meantime, administrators are left with the worst kind of security information: credible enough to matter, incomplete enough to be hard to operationalize. A public GitHub exploit changes the threat model even before a vendor advisory appears. Defenders cannot wait for perfect clarity when offensive teams and opportunistic actors can read the same repository.
The reported test by researcher Will Dormann is especially notable because it cuts through some of the usual ambiguity around proof-of-concept releases. Dormann reportedly confirmed successful SYSTEM privilege escalation, while also noting that the exploit did not work on the latest Windows 11 Insider Preview Canary build. That combination points in two directions at once: production systems may be exposed, but Microsoft may already have code in the pipeline that changes the vulnerable behavior.
That does not prove a fix is imminent, nor does it prove Microsoft knowingly carried a patch. Insider builds differ from stable releases for many reasons, and security-relevant changes are not always publicly documented before release. Still, when a PoC fails on Canary but succeeds on stable, the natural question is whether Patch Tuesday is lagging behind a fix already present in development builds.

The Six-Year Gap Is the Real Vulnerability​

The most damaging reading of MiniPlasma is not that one driver has one bug. It is that the Windows servicing process may not have preserved the security invariant Microsoft intended to establish in 2020. Security fixes are not just code changes; they are promises that the same class of mistake will not silently return.
That is where regression testing becomes the unglamorous hero of platform security. When a vulnerability is fixed, the vendor should ideally capture the exploit condition in a test that fails if the bug reappears. In kernel and file-system code, that can be difficult, brittle, and expensive. But without it, a vulnerability can become institutional folklore: remembered by the researcher, marked closed in the database, and forgotten by the product.
Microsoft is hardly alone here. Every large software vendor fights the same entropy. Code is refactored, components are modernized, security checks are moved, compatibility fixes are layered on top of hardening, and assumptions made by one team are invalidated by another team years later. The difference is that Windows sits at the center of consumer PCs, enterprise fleets, public-sector networks, and critical workflows, so a regression in a kernel driver is never just a private embarrassment.
The Cloud Files driver also lives in a part of Windows that Microsoft has every incentive to keep expanding. Cloud-first storage is now a default assumption across Microsoft 365, Windows backup, enterprise sync, and AI-era file indexing. The more Windows treats cloud state as a native part of the local file system, the more security attention these plumbing components deserve.

The Researcher Drama Is a Distraction, but Not an Irrelevance​

MiniPlasma did not arrive in a vacuum. Nightmare-Eclipse has been associated with a string of recent Windows-related proof-of-concept releases, including names such as GreenPlasma, YellowKey, BlueHammer, and RedSun in public reporting. Some of that history involves allegations about Microsoft’s vulnerability handling, disputed severity, and frustration with disclosure outcomes.
It is tempting to turn that into a personality story. That would be convenient for Microsoft and satisfying for the internet, but it would miss the operational point. Once exploit code is public, defenders have to judge the technical claim, not the author’s temperament. A messy disclosure can still describe a real bug.
At the same time, disclosure style affects risk. Publishing source code and compiled binaries compresses the time between research and weaponization. Security teams that might have had weeks to prepare under coordinated disclosure may have hours before scanners, red teams, malware authors, and low-skill operators begin experimenting.
That does not mean every public PoC becomes a mass-exploitation event. Many do not. But Windows local privilege escalations are useful building blocks, and useful building blocks tend to find their way into toolchains. The more reliable MiniPlasma proves across supported builds, the more likely it becomes part of the background noise defenders must account for.

Fully Patched Is Still the Right Baseline, Just Not the Finish Line​

The wrong lesson from MiniPlasma would be to distrust patches altogether. KB5089549 still contains security fixes, and withholding cumulative updates because one alleged issue remains unresolved would usually make a fleet less secure, not more secure. Patch management is not a purity test; it is risk reduction under uncertainty.
The better lesson is that “fully patched” should be treated as a baseline condition, not a state of grace. A system can be current and still vulnerable to a zero-day, an incomplete fix, a driver bug, a misconfiguration, or a local escalation chained after initial access. That is why privilege boundaries, application control, least privilege, EDR telemetry, script restrictions, and credential protections still matter.
For home users, the immediate advice is mostly boring and therefore correct. Keep Windows updated, do not run unknown binaries, be skeptical of “fix” tools and exploit demos circulating on social media, and avoid using an administrator account as a daily driver where possible. MiniPlasma does not appear to be a drive-by remote compromise that leaps onto a machine simply because OneDrive exists.
For enterprise IT, the response should be more structured. Inventory Windows 11 24H2 and 25H2 exposure, watch for Microsoft advisories, monitor endpoint telemetry for suspicious child processes or privilege transitions, and treat public MiniPlasma artifacts as detection opportunities. If Microsoft ships an out-of-band update or folds a fix into the next cumulative release, test quickly but do not let routine compatibility validation become a month-long delay.

The Canary Clue Makes This a Race Against the Calendar​

The reported failure of MiniPlasma on the latest Windows 11 Insider Preview Canary build is the most intriguing technical breadcrumb. Canary is not a promise of what ships next month, but it often contains low-level changes before they reach stable channels. If the vulnerable path is already gone there, Microsoft may have a fix staged, intentionally or incidentally.
That creates a strange race. Attackers can test the public PoC on stable systems today, while defenders wait for Microsoft to confirm scope and remediation. Microsoft, meanwhile, has to decide whether the issue is severe enough for accelerated servicing or whether it can ride the normal Patch Tuesday cadence.
For consumers, that distinction is invisible. For enterprises, it is everything. An out-of-band patch can disrupt change windows and emergency CAB processes, but waiting until June could leave a public LPE available for weeks. The calculus depends on exploit reliability, affected builds, telemetry, and whether Microsoft sees active exploitation.
If there is a silver lining, it is that local privilege escalation bugs are often easier to contain than remote code execution flaws. They require something else to go wrong first. But the modern attack chain is built from exactly those “something else” moments, and defenders should assume public LPEs are additive risk rather than isolated curiosities.

MiniPlasma’s Lesson Is Written in the Driver Stack​

The concrete implications are narrower than the panic headline and broader than a single CVE entry. MiniPlasma is a Windows local privilege escalation claim, but it also touches cloud storage integration, regression discipline, Patch Tuesday trust, and the uncomfortable lag between public exploit code and official vendor guidance.
  • KB5089549 should still be treated as an important Windows 11 security update, not as something to uninstall merely because MiniPlasma is being discussed.
  • MiniPlasma reportedly targets cldflt.sys, the Cloud Files Mini Filter Driver that supports Windows cloud-placeholder behavior used by services such as OneDrive Files On-Demand.
  • The public proof-of-concept is described as a local privilege escalation, meaning attackers generally need prior code execution before they can use it to seek SYSTEM privileges.
  • The relationship to CVE-2020-17103 matters because that vulnerability was treated as fixed in 2020, raising the possibility of an incomplete patch, a regression, or a related unfixed variant.
  • Reports that the exploit fails on the latest Windows 11 Insider Preview Canary build suggest a fix may already exist in development code, but stable-channel users should wait for explicit Microsoft guidance.
  • Administrators should monitor for vendor advisories, test forthcoming fixes quickly, and treat public MiniPlasma indicators as detection material rather than internet drama.
MiniPlasma may ultimately become a short-lived zero-day with a quiet fix, or it may become another case study in how Windows’ deepest compatibility layers keep creating security debt long after the original bug report is closed. Either way, the lesson for Microsoft is sharper than the lesson for users: cloud-era Windows depends on kernel plumbing that most people never see, and every invisible convenience needs a visible security guarantee.

References​

  1. Primary source: Neowin
    Published: Mon, 18 May 2026 07:08:00 GMT
  2. Related coverage: bleepingcomputer.com
  3. Related coverage: thehackernews.com
  4. Related coverage: windowsforum.com
  5. Related coverage: aha.org
  6. Related coverage: anavem.com
 

Back
Top