Once again, security researcher Chaotic Eclipse has released a proof-of-concept exploit for a new Windows privilege escalation zero-day called MiniPlasma, which can grant attackers SYSTEM privileges on fully patched systems.
The flaw affects “cldflt.sys,” the Windows Cloud Files Mini Filter Driver, specifically within the “HsmOsBlockPlaceholderAccess” routine. Google Project Zero researcher James Forshaw originally reported the vulnerability to Microsoft in September 2020.
“After re-investigating the technique used in GreenPlasma (specifically SetPolicyVal), it turns out cldflt!HsmOsBlockPlaceholderAccess is still vulnerable to the exact same issue that was reported to Microsoft 6 years ago. I’m not taking full credit for this, James Forshaw from google project zero found the vulnerability and reported it to Microsoft and was supposedly fixed as CVE-2020-17103.” Chaotic Eclipse wrote.
“However, a research who’s a friend of mine pointed out that the routine might still have a vulnerability, which is something I considered but brushed off because I thought it was impossible for Microsoft to just not patch this or rollback the patch.”
Chaotic Eclipse investigated further and found that the exact same vulnerability is still present in fully patched systems running the latest May 2026 updates. The original proof-of-concept code published by Forshaw worked without modification. The researcher then weaponized it to spawn a SYSTEM shell and published it as MiniPlasma, noting that reliability may vary due to the exploit’s race-condition nature, but that it worked consistently across their test environments.
“After investigating, it turns out the exact same issue that was reported to Microsoft by Google project zero is actually still present, unpatched. I’m unsure if Microsoft just never patched the issue or the patch was silently rolled back at some point for unknown reasons. The original PoC by Google worked without any changes.” Chaotic Eclipse added. “To highlight this issue, I weaponized the original PoC to spawn a SYSTEM shell. It seems to work reliably in my machines but success rate may vary since it’s a race condition. I believe all Windows versions are affected by this vulnerability.”
Will Dormann, a popular cybersecurity researcher, independently confirmed the result: MiniPlasma opens a cmd.exe prompt with SYSTEM privileges on Windows 11 running the latest patches. He noted it does not work on the Insider Preview Canary build, which suggests Microsoft may be addressing it there, but that provides little comfort to the hundreds of millions of users running production Windows 11 builds.
“New from Nightmare-Eclipse, we have MiniPlasma [github.com]” Dormann wrote. “Works reliably to get a SYSTEM cmd.exe prompt on Win11 (including 26H1) with May’s updates. Is reportedly a failure to properly fix CVE-2020-17103 [msrc.microsoft.com]. I’ll note that it does not seem to work on the latest Insider Preview Canary Windows 11.”
Mysteriously, a patch reportedly confirmed in 2020 appears to have disappeared. The issue goes beyond delayed updates and raises broader concerns about the reliability and completeness of Windows patch management, leaving organizations questioning whether fully patched systems are truly secure.
But now, let’s focus on Chaotic Eclipse.
There is a GitHub profile called Nightmare-Eclipse. Behind it, a researcher who goes by Chaotic Eclipse. In the span of a few weeks, this individual has published working exploit code for five separate Windows vulnerabilities, some previously unknown, some believed to have been patched years ago but apparently still very much alive. The disclosures triggered a wave of zero-days that put Microsoft under pressure, raised concerns about the reliability of its patches, and revived the long-running debate over whether publishing exploit code promotes transparency or creates greater security risks.
To understand the significance of what Chaotic Eclipse has published, it helps to lay out the full picture of what has been disclosed so far.
The first two flaws in the Defender series, BlueHammer, RedSun, and UnDefend, appeared in April. BlueHammer and RedSun let attackers escalate privileges locally in Microsoft Defender. UnDefend instead triggers a denial-of-service, blocking security definition updates and weakening protection. Microsoft addressed BlueHammer as CVE-2026-33825, but RedSun and UnDefend remained unpatched. Within days of the public release, Huntress researchers observed real-world exploitation of all three. Attackers began using BlueHammer on April 10, then moved to the proof-of-concept code for RedSun and UnDefend on April 16, following the publicly available exploit code with a precision that left little doubt about where the attack playbook had come from.
Then came YellowKey and GreenPlasma, two more Windows zero-days disclosed by the same researcher and reported by Security Affairs. YellowKey is a BitLocker bypass issue that affects Windows 11 and Windows Server 2022/2025 systems. The flaw allows attackers with physical access to bypass BitLocker protections and gain unrestricted shell access to encrypted volumes through the Windows Recovery Environment (WinRE). The attack is triggered by placing specially crafted files inside a specific directory on a USB drive or directly in the EFI partition. What makes this flaw particularly unsettling is not just its functionality but also the researcher’s commentary on its origins: the vulnerable component exists exclusively within the WinRE image, not in standard Windows installations, and an identical component appears in normal installations but without the triggering functionality.
Chaotic Eclipse drew an uncomfortable conclusion from this: “Now why would I say this is a backdoor ? The component that is responsible for this bug is not present anywhere (even in the internet) except inside WinRE image and what makes it raise suspicions is the fact that the exact same component is also present with the exact same name in a normal windows installation but without the functionalities that trigger the bitlocker bypass issue. Why ? I just can’t come up with an explanation beside the fact that this was intentional. Also for whatever reason, only windows 11 (+Server 2022/2025) are affect, windows 10 is not.“
It is a claim that Microsoft has not publicly addressed. Whether it reflects a genuine design anomaly, an architectural oversight that looks suspicious from the outside, or something else entirely, is not known. What is known is that the flaw works, that it affects Windows 11 and Server 2022/2025, and that Windows 10 is not affected, a distinction that itself raises questions without obvious answers.
The second flaw in that pair, GreenPlasma, targets the Windows Collaborative Translation Framework — the CTFMON subsystem, and enables privilege escalation on Windows 11 and Windows Server 2022/2026 by creating arbitrary memory section objects inside directories writable by SYSTEM. The researcher withheld the full exploit chain but noted that someone with the right skills could complete the escalation from the published material. A partial disclosure that is effectively complete for a skilled attacker is a category that sits uncomfortably between responsible and irresponsible release.
Who Is Chaotic Eclipse?
Tracing a precise profile of the researcher is difficult. They operate under a pseudonym, maintain a GitHub repository under the handle Nightmare-Eclipse, and communicate through a blog and occasional social media posts. The documentation accompanying each release, while not exhaustive, reflects genuine understanding of the underlying mechanisms.
The motivations behind Chaotic Eclipse are not fully clear, but public comments point to frustration with Microsoft’s patching process, a concern shared by many in the security community. By publishing working exploit code instead of following standard coordinated disclosure timelines, the researcher seems to be pushing for faster action and greater accountability. This view is reinforced by the fact that some flaws were quickly patched after public exposure, while others remained unaddressed.
There is also a more serious concern raised in the disclosures, including the possibility that one issue may reflect intentional design rather than a simple vulnerability. Whether or not that is accurate, it shows a more confrontational approach to disclosure than traditional reporting channels.
Overall, this reflects a long-standing divide in security research: some researchers work within vendor programs and disclosure frameworks, while others publish findings directly. The latter approach can pressure companies into fixing issues faster, but it also risks exposing users to active attacks before patches are ready.
The MiniPlasma situation really shows how divided the vulnerability disclosure debate still is, because both sides actually have a point.
Chaotic Eclipse’s argument is based on something concrete: Microsoft originally fixed CVE-2020-17103 back in 2020, yet parts of that fix now seem to be missing in newer Windows builds. Without a public disclosure and a working proof of concept, it’s fair to ask whether the issue would have been noticed at all. We’ve already seen something similar with BlueHammer. Once exploit details became public, Microsoft reacted quickly and pushed out fixes, which suggests that public attention can sometimes force action faster than private reporting alone.
At the same time, the risks of releasing exploit code are very real. Researchers at Huntress have repeatedly pointed out that attackers move fast once proof-of-concept code is available. In some cases, weaponization happens within days. That creates a difficult tradeoff: public research helps defenders and increases pressure on vendors, but it also gives threat actors a shortcut. Even if MiniPlasma is not trivial to exploit consistently, the fact that Windows runs on billions of devices means that any reliable exploit immediately becomes high risk.
That tension is exactly why responsible disclosure became standard practice in cybersecurity. Typically, researchers report vulnerabilities privately, vendors get time to investigate and release a fix, and technical details are published afterward. The process is not perfect, and sometimes vendors move too slowly, but the goal is to reduce unnecessary exposure while still ensuring accountability. Chaotic Eclipse’s approach speeds that timeline up considerably. That can lead to faster patching, but it also reduces the time defenders have before attackers begin experimenting with the same information.
What makes the MiniPlasma story more concerning, though, is not just the disclosure debate itself. The bigger issue is the possibility that a vulnerability fixed years ago may have quietly reappeared. If a patch released in 2020 can effectively disappear because of regressions, refactoring, or build changes, then it challenges a basic assumption many organizations rely on: that once something is patched, it stays fixed.
That matters because modern enterprise security depends heavily on patch management. Microsoft ships hundreds of fixes every year, and security teams generally trust that updates permanently close known holes. If old vulnerabilities can unintentionally return over time, then patching alone is no longer enough. Teams may also need ways to continuously verify that protections are still present after later updates and feature changes.
The fact that related issues have reportedly appeared multiple times in the same component only adds to that concern. From a defender’s perspective, MiniPlasma is less about one exploit and more about what it says regarding software maintenance at scale. It highlights the gap between how patching is supposed to work in theory and how difficult it can be to guarantee in practice across years of development and constant code changes.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, MiniPlasma)
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。