What YellowKey and GreenPlasma zero-day exploits reveal about trusting native Windows security

When Patch Tuesday is not enough

On May 13, 2026, one day after Microsoft’s May Patch Tuesday, a security researcher known as Chaotic Eclipse (also identified as Nightmare-Eclipse on GitHub) released proof-of-concept exploit code for two unpatched Windows vulnerabilities. The researcher, who had previously attempted disclosure through Microsoft’s Security Response Center, timed the release to follow the patch cycle, leaving organizations without an official fix until at least the next scheduled patch cycle.

The two exploits, YellowKey and GreenPlasma, target BitLocker’s recovery environment and Windows privilege escalation respectively. Neither had a patch. Neither had a CVE.

This is not the researcher’s first disclosure. Earlier in 2026, the same actor published BlueHammer, RedSun, and UnDefend: a series of privilege escalation flaws and a denial-of-service bug. BlueHammer was eventually patched after threat actors began actively exploiting it. The others attracted forks and community attention before fixes existed.

The surrounding story of a disputed disclosure, public warnings tied to future Patch Tuesdays, and escalating tension with Microsoft has dominated the coverage. For defenders, it is useful context and not much more.  

The operational question is simpler: what actually changes your exposure when no patch exists yet?

What are YellowKey and GreenPlasma?

YellowKey: A BitLocker bypass through WinRE

BitLocker is Windows’ full-volume encryption feature. The assumption is that a stolen laptop stays unreadable without the recovery key. YellowKey challenges that.  

The attack places a specially crafted “FsTx” folder on a USB drive or EFI partition, boots a BitLocker-protected Windows 11 machine into the Windows Recovery Environment (WinRE), and triggers vulnerable recovery behavior that results in unrestricted shell access to the encrypted volume. No recovery key. No credentials.  

Security researcher Will Dormann independently reproduced the exploit shortly after release, confirming the behavior and flagging the cross-volume file manipulation as a potential separate vulnerability.

The behavior is specific to WinRE. Claims that it represents a deliberate “backdoor” remain unverified.

The critical constraint is physical access. A remote attacker cannot exploit YellowKey at scale. That shapes how organizations should prioritize their response and focus mitigations.

YellowKey affects Windows 11 and Windows Server 2022 and 2025. Windows 10 is not affected.

GreenPlasma: Privilege escalation via CTFMON

GreenPlasma targets CTFMON (ctfmon.exe), a trusted Windows process that runs as SYSTEM in every interactive session to handle text input. The exploit manipulates registry settings and object manager permissions to plant an arbitrary memory section object in a directory normally writable only by SYSTEM, then tricks CTFMON into interacting with it. Because CTFMON is trusted, the interaction is treated as legitimate. The result is a path to SYSTEM-level privileges from an unprivileged account.

The published proof-of-concept is intentionally incomplete. In its current form, it still triggers a UAC consent prompt under default configurations. That does not make GreenPlasma low priority.

Privilege escalation is rarely the initial intrusion vector. Its value comes after an attacker already has a foothold. From there, elevated privileges make credential theft, lateral movement, security tooling interference, and ransomware deployment significantly easier.

GreenPlasma affects Windows 11 and Windows Server 2022 and 2026.

The bigger problem: Trusted components keep becoming the attack surface

YellowKey and GreenPlasma are the latest examples of a pattern security teams have been dealing with for years: Trusted, native, signed Windows functionality becoming part of the attack surface. WinRE was built to repair broken systems. CTFMON was built to support text input. Neither was designed as a security boundary.

The pattern appears repeatedly across modern attack techniques: LOLBin attacks abusing built-in Windows utilities like certutil.exe, mshta.exe, and wscript.exe, signed driver abuse used to disable security tooling, and supply chain compromises weaponizing legitimate distribution channels. The attack succeeds not despite the component being trusted, but because of it.

Security models built around “is this signed and Microsoft-native?” will keep producing blind spots when the answer is yes and the component is still being weaponized. The more useful question is: “What is this component allowed to do, and what can it touch?”

Chaotic Eclipse is one researcher with a specific grievance. The trust problem is not.

Why traditional security struggles against zero-days

Signature-based detection cannot exist before a threat is known. EDR requires observable malicious behavior before alerts trigger. Patching is reactive by nature. Zero-days expose the ceiling of that model: No detection rule exists at disclosure, and by the time vendors push signatures and organizations deploy them, the window has been open for days or weeks. With BlueHammer, exploitation started before Microsoft’s patch was available.

Public proof-of-concept releases further compress the timeline. A PoC doesn’t need to be polished to be useful. It confirms the attack path and gives attackers a starting point. With YellowKey , the gap between “publicly disclosed” and “operationally usable” was shorter than most patch processes.

The Chaotic Eclipse disclosures also use timing strategically. Releasing immediately after Patch Tuesday maximizes the gap before the next fix cycle. When a threat actor is planning around the patch cycle, that schedule stops being a reliable planning horizon.

What security teams should do now

There is no patch for YellowKey or GreenPlasma as of this writing. The response to each vulnerability is different because the nature of each is different.

For YellowKey: Physical security and boot controls

YellowKey’s attack chain starts with physical access. That is where the response needs to start.

Most enterprise security programs are heavily optimized for remote compromise, like phishing, browser exploitation, and lateral movement, treating physical access as someone else’s problem. Recovery environments, removable media, and boot workflows don't fit neatly into a SOC dashboard, so they often get deprioritized. YellowKey is a reminder that they are still part of the attack surface. Sometimes access to the device itself is enough.

The first line of defense is preventing physical access to sensitive systems. Locked server rooms, cable locks on workstations, clean desk policies, and check-in/check-out procedures for field devices are not glamorous controls. But for an attack that requires hands on the machine, they are the most direct mitigation available.

The exposure is highest for field laptops, shared workstations, kiosk systems, and devices that regularly leave organizational control, but any system that can boot into an unauthorized recovery environment or accept arbitrary removable media carries some exposure.

• Restrict removable media. The attack depends on introducing attacker-controlled files via USB or EFI. Blocking unauthorized removable media stops the attack before the recovery workflow is reached.
• Lock boot order and enable firmware passwords. A locked boot sequence and BIOS or UEFI password make unauthorized WinRE boots significantly harder.
• Apply BitLocker PIN alongside TPM. The published exploit targets TPM-only configurations. A pre-boot PIN raises the bar. The researcher has suggested the vulnerability may extend to TPM+PIN configurations, so monitor Microsoft guidance closely.
• Monitor for unexpected WinRE usage. Most users have no reason to be in a recovery environment. Flag it.

BitLocker is not broken. Against the majority of theft scenarios, it remains an effective protection for data at rest. YellowKey is a reminder that the recovery environment is part of the trust chain too.

For GreenPlasma: Limiting what a foothold can become

GreenPlasma becomes useful after an attacker already has code execution. The defensive question is not how to patch something with no patch but how to reduce what a foothold is worth.

• Application Allowlisting addresses the earliest stage. GreenPlasma requires execution. A default-deny policy prevents unauthorized binaries, scripts, and payloads from running regardless of how they arrived or what trusted component they attempt to abuse. If the payload cannot run, the privilege escalation path never opens. It does not need to recognize the threat; it requires that execution be earned, not assumed.
• Ringfencing™ addresses what happens when execution is approved. GreenPlasma attempts to manipulate CTFMON into interacting with attacker-controlled memory. Ringfencing defines what trusted processes can interact with, spawn, or access, limiting the surface available for that manipulation. Approving a component to run is not the same as approving it to do anything. That distinction is exactly what GreenPlasma exploits.
• Least privilege addresses the payoff. GreenPlasma's value is the gap between an unprivileged account and SYSTEM. Removing unnecessary admin rights and enforcing privilege boundaries shrink that gap. If elevated access unlocks less, the escalation is worth less.

None of these patch GreenPlasma, but they reduce what an attacker can do with it after a foothold exists. That is the realistic goal during a zero-day window.

For both vulnerabilities

• Don't wait for detection. Signature and behavioral detections adapt eventually. They are weakest immediately after disclosure, when the technique is newest and attackers are most active.
• Patch immediately when fixes arrive. Microsoft is investigating both vulnerabilities. When fixes are released, prioritize them regardless of normal cadence.
• Stop treating native components as inherently safe. Security policies that exempt signed or Microsoft-native functionality from scrutiny will keep producing blind spots.

Prevention reduces the value of zero-days

YellowKey and GreenPlasma are not evidence that Windows security is collapsing. BitLocker still protects against many physical theft scenarios. Native Windows protections still matter. The lesson learned is that no single trusted component is a complete security boundary on its own.

Trusted components like recovery environments, native services, and privileged processes can all become useful to attackers under the right conditions. Defenses built entirely around trust assumptions will keep developing blind spots. Defenses built around limiting what components are allowed to do and where attackers can operate hold up better when the unexpected happens.

Zero-days are inevitable. What follows doesn’t have to be.