There is a certain kind of vulnerability that feels less like a bug and more like someone quietly left a side door unlocked years ago. The newly published YellowKey exploit lands squarely in that category.
Security researcher Chaotic Eclipse, also known as Nightmare-Eclipse, claims that modern Windows systems protected with BitLocker can be opened from the Windows Recovery Environment using nothing more than a prepared USB stick and a reboot. According to the report published by Tom’s Hardware, the exploit works without requesting recovery keys and leaves behind almost no trace after execution.
That detail alone is enough to make security engineers deeply uncomfortable.
BitLocker has long occupied a trusted position in the Windows ecosystem. For many Windows 11 systems it is enabled automatically, quietly encrypting entire drives and relying on the Trusted Platform Module to release encryption keys during boot. The model is straightforward: steal the drive and the data stays protected because the cryptographic material remains tied to the original hardware.
YellowKey appears to bypass that assumption.
The attack flow described by Chaotic Eclipse is almost absurdly simple. An attacker copies a specially crafted “FsTx” directory into the “System Volume Information” folder on a USB stick, boots into the recovery environment, holds the Control key during restart, and is reportedly dropped directly into an elevated command prompt with unrestricted access to the encrypted drive.
No recovery key prompt. No BitLocker unlock sequence. No visible authentication step.
Even stranger, the exploit allegedly deletes its own files from the USB device after execution. That behavior immediately changes the tone of the discussion. Self-cleaning payloads are common in offensive security tooling because they reduce forensic evidence. When that behavior appears inside a mechanism capable of bypassing full-disk encryption, researchers start asking uncomfortable questions very quickly.
The exploit reportedly affects Windows 11 along with Windows Server 2022 and 2025, but not Windows 10. That distinction matters because BitLocker’s integration evolved significantly between Windows generations, especially around recovery workflows and pre-boot trust handling.
At a technical level, the attack appears tightly connected to the Windows Recovery Environment rather than directly breaking BitLocker cryptography itself. That is an important distinction. The encryption algorithms are almost certainly still intact. Instead, the exploit seems to abuse a trusted execution path capable of obtaining decrypted access to the drive once the platform enters a privileged recovery state.
In other words, this may be less “BitLocker is broken” and more “the trusted recovery chain can apparently be hijacked.”
That nuance matters enormously for defenders because it changes where mitigations may exist. If the weakness lives in recovery boot logic, Secure Boot policy, recovery partition validation, or privileged recovery tooling, then remediation becomes a firmware-and-platform integrity problem rather than a cryptographic one.
Chaotic Eclipse also claims that systems configured with Trusted Platform Module plus personal identification number authentication are still vulnerable through a separate unpublished variant. If true, that would further erode confidence in assumptions surrounding physical-device theft protection.
The timing adds another layer to the story.
This is not the researcher’s first public clash with Microsoft. Earlier exploits named BlueHammer and RedSun allegedly exposed privilege escalation flaws after disclosure attempts reportedly failed to gain traction internally. BlueHammer was later patched, while RedSun was allegedly fixed silently according to the researcher.
Now comes YellowKey alongside another exploit called GreenPlasma.
GreenPlasma reportedly targets the Windows object namespace and the CTFMon process to manipulate shared memory section objects. The description points toward a local privilege escalation technique that abuses object manager access controls to reach SYSTEM-level execution. If accurate, it would allow ordinary user processes to cross privilege boundaries by mapping crafted memory regions into locations writable by privileged processes.
That kind of attack is particularly dangerous in shared or server environments because it turns any low-privilege foothold into a possible full-system compromise.
The larger story here is not just about two exploits. It is about trust boundaries.
Modern operating systems are layered towers of trust assumptions: firmware trusts bootloaders, bootloaders trust kernels, kernels trust recovery tooling, and encryption systems trust the platform state around them. Attackers increasingly focus not on breaking encryption directly, but on finding hidden pathways around the systems responsible for unlocking it.
That strategy is often far more effective.
Breaking modern encryption mathematically is usually infeasible. Manipulating the trusted machinery surrounding it is often dramatically easier.
For enterprise administrators, the immediate problem is uncertainty. There is currently no official Microsoft response addressing YellowKey or GreenPlasma publicly. Without vendor confirmation, independent validation, or patches, organizations are left evaluating whether these demonstrations represent narrowly scoped edge cases, deeply buried implementation flaws, or something even worse.
And when a full-disk encryption bypass starts behaving like a self-erasing implant, speculation becomes inevitable.