Windows BitLocker Zero-Day Lets Attackers Access Protected Drives With Physical Access

A newly disclosed Windows zero-day named YellowKey can bypass default BitLocker protections on some Windows systems when an attacker has physical access to the device.

The public proof-of-concept targets the Windows Recovery Environment, known as WinRE, and can expose the contents of BitLocker-protected drives on affected Windows 11 and Windows Server systems.

The researcher who released YellowKey also published a second Windows zero-day named GreenPlasma. That flaw targets the Windows CTFMON component and could become a local privilege escalation path if fully weaponized.

What happened

The exploits were released by a researcher known as Chaotic Eclipse or Nightmare-Eclipse after a dispute over Microsoft’s vulnerability handling.

YellowKey is the more urgent issue because it affects the security promise many organizations rely on when laptops are lost, stolen, or left unattended. BitLocker should protect local drive contents when an attacker cannot log in.

The public YellowKey exploit changes that risk model for systems using default TPM-only BitLocker protection. Independent researchers have confirmed that the public exploit works on recent Windows 11 builds in that scenario.

Issue	Type	Main risk	Public PoC status
YellowKey	BitLocker bypass	Access to protected drive contents with physical access	Released and independently reproduced
GreenPlasma	Local privilege escalation	Possible SYSTEM-level access after further weaponization	Released but incomplete

How YellowKey affects BitLocker

YellowKey abuses behavior inside WinRE, the recovery environment Windows uses for repair and recovery tasks.

The public exploit involves placing specially crafted FsTx files on removable media or in a local boot-related partition, then triggering recovery behavior on a BitLocker-protected machine.

When successful, the attack opens a command shell while the protected volume is accessible. That gives the attacker access to data that BitLocker would normally protect from offline viewing.

Physical access is required

YellowKey is not a remote internet exploit. The attacker needs physical access to the target computer, or enough access to modify the device’s boot or recovery environment.

This makes the risk most serious for laptops, executive workstations, shared devices, field systems, and servers in locations where physical access controls are weak.

The current public exploit also needs the original device. It does not work the same way against a drive removed from the machine, because TPM-only BitLocker depends on keys stored by the device’s TPM.

• Lost or stolen Windows 11 laptops face higher risk if they use TPM-only BitLocker.
• Devices without a BitLocker startup PIN face greater exposure.
• Attackers need physical access or boot-level access.
• Windows Server 2022 and Windows Server 2025 are also listed in public reporting.
• Windows 10 does not appear to be affected by the public YellowKey PoC.

TPM-only BitLocker is the weak point

TPM-only BitLocker offers a smooth user experience because the drive unlocks automatically when the trusted boot state passes validation.

That convenience also creates a security trade-off. Microsoft’s own BitLocker guidance says TPM-only mode requires no user interaction and is less secure than options that add another authentication factor.

Researchers say the public YellowKey exploit takes advantage of this automatic unlock behavior. Systems using TPM plus a startup PIN have stronger protection, though the researcher has claimed a separate TPM+PIN path exists.

BitLocker mode	User action at boot	YellowKey exposure based on public reporting
TPM-only	No PIN or startup key required	Public PoC has been reproduced
TPM with PIN	User enters a startup PIN	Public PoC does not include a confirmed TPM+PIN bypass
TPM with startup key	Startup key is required	Less exposed than TPM-only, but still needs vendor guidance
TPM with startup key and PIN	Startup key and PIN are required	Strongest of the listed options

GreenPlasma targets Windows CTFMON

GreenPlasma is a separate local privilege escalation issue. It targets Windows CTFMON, which is tied to text input and language services.

The public code can let an unprivileged user create arbitrary memory section objects inside directory objects writable by SYSTEM. That matters because some privileged Windows services or drivers may trust paths that normal users should not control.

The current GreenPlasma release does not provide a complete SYSTEM shell. However, the public details could help skilled attackers develop a fuller privilege escalation chain.

Microsoft is still investigating

Microsoft has not issued public CVE identifiers or patches for YellowKey and GreenPlasma at the time of writing.

The company told security publications that it is aware of the claims and is investigating their validity and impact across Microsoft platforms and services.

Microsoft also said it supports coordinated vulnerability disclosure, which gives vendors time to investigate and patch issues before public release.

Why defenders should act before a patch

Public exploit code changes the risk. Even when a flaw needs physical access, attackers can test the method, improve it, and combine it with other techniques.

YellowKey also matters because disk encryption often serves as the final protection when a device leaves corporate control. If a stolen laptop can expose drive contents, the incident can become a data breach rather than only a lost asset.

GreenPlasma raises a different concern. If attackers already have low-level access, a working privilege escalation could help them disable defenses, install malware, or persist on the system.

What security teams should do now

Organizations should first identify Windows 11, Windows Server 2022, and Windows Server 2025 systems that rely on TPM-only BitLocker.

High-risk devices should move to BitLocker preboot authentication where operationally possible. A startup PIN adds a second factor before the system drive unlocks.

Security teams should also tighten firmware settings, restrict boot from external devices, protect UEFI settings with an administrator password, and monitor for unexpected recovery environment changes.

1. Inventory devices that use TPM-only BitLocker.
2. Prioritize laptops, executive devices, shared machines, and field systems.
3. Enable BitLocker startup PINs for high-risk devices where possible.
4. Set strong BIOS or UEFI administrator passwords.
5. Disable boot from external media unless business workflows require it.
6. Restrict physical access to servers and sensitive workstations.
7. Monitor for unexpected FsTx folder creation in System Volume Information.
8. Review use of WinRE and recovery media in managed environments.
9. Watch for GreenPlasma-related detections and suspicious CTFMON activity.
10. Apply Microsoft patches when official fixes become available.

Should organizations disable WinRE?

Disabling WinRE may reduce one attack path, but it also affects recovery options. Organizations should not make that change broadly without a tested recovery plan.

For high-security systems, administrators can evaluate whether WinRE should remain enabled, whether recovery access should be restricted, and whether alternative recovery workflows already exist.

Any change to WinRE should go through normal change control. A rushed configuration change can leave users unable to recover from boot failures, update problems, or system corruption.

Detection and hunting guidance

Defenders should treat YellowKey as a physical-access and recovery-environment risk, not as a normal malware infection path.

Useful signals include unexpected recovery boots, unusual changes to EFI partitions, removable media activity around sensitive devices, and FsTx folder creation in protected system locations.

For GreenPlasma, teams should watch endpoint detections tied to suspicious discovery commands, unusual CTFMON behavior, and attempts to create unexpected memory section objects.

Area	What to monitor
BitLocker	Devices using TPM-only protection on high-risk endpoints
WinRE	Unexpected recovery boots or recovery configuration changes
Filesystem	FsTx folders in System Volume Information
Firmware	External boot attempts and UEFI configuration changes
CTFMON	Suspicious section object creation or unusual child process behavior

The larger BitLocker lesson

YellowKey highlights a long-standing security trade-off in default disk encryption. TPM-only BitLocker protects against many casual offline attacks, but it does not provide the same protection as preboot authentication.

Organizations that handle sensitive data should treat startup PINs, firmware protections, and physical security as part of the same control set.

Until Microsoft ships a fix, the safest approach is to reduce reliance on TPM-only BitLocker for high-value devices, harden boot settings, and watch for signs of recovery-environment abuse.

FAQ