Yellow Key: The BitLocker Bypass Microsoft Didn't

There's a particular kind of security researcher who operates at the ragged edge of what the industry calls "responsible disclosure." They find something serious, report it through the official channels, get told it doesn't qualify, and then—after enough of those interactions—they stop playing by the rules everyone else agreed to. Nightmare Eclipse appears to be that kind of researcher. And right now, that matters.

Nightmare Eclipse—a handle attached to an anime avatar, if you're picturing it—has publicly dropped at least six zero-day vulnerabilities in Microsoft products. Not reported privately. Not sat on for a CVE. Dropped them. GitHub removed their repositories. Then GitLab removed them too. As the Low Level channel's breakdown of the situation noted, the repos are, at least for now, simply gone. That's how fast the platforms moved to contain this.

The grievance at the center of this is not obscure. Bug bounty disputes between researchers and large vendors are as old as bug bounty programs themselves. Microsoft's Security Response Center has maintained for years that escalating from administrator to kernel—getting from admin to full system access—is not a meaningful security boundary and therefore not a compensable finding. A lot of researchers find this maddening. MSRC's logic is that if you're already an admin, you've already lost. The researcher's counter is that the line between "admin" and "system" is exactly the kind of thing exploit chains are built on, and dismissing it as a non-boundary is convenient for Microsoft's payout numbers more than it is for user security.

Whether Nightmare Eclipse had a legitimate grievance with MSRC before going full public-drop mode is a question the bug bounty community has been arguing about for years in different variations. The answer probably depends on which specific findings got rejected and how. What's not in dispute is the escalation: in April, Nightmare Eclipse posted, "I was not bluffing Microsoft and I'm doing it again," followed by a link to a repo that no longer exists. The sign-off—"huge thanks to MSRC leadership for making this possible"—is the kind of thing you only write when you've stopped caring about the relationship.

The vulnerability that's getting the most attention right now is called Yellow Key, and it targets BitLocker—the disk encryption technology baked into Windows that's supposed to make your data unreadable if your laptop gets stolen, handed to an airport customs agent, or picked up by anyone who isn't supposed to have it.

Here's how BitLocker normally works: your disk is encrypted, and the key that unlocks it is sealed inside a Trusted Platform Module (TPM)—a dedicated chip that cryptographically measures the state of your system at boot. If you pull the hard drive and stick it in a different machine, the TPM key doesn't travel with it, so the data stays locked. The TPM will only hand over the decryption key if it confirms you're booting into the same, expected environment you were using before. It's elegant, and for most threat models, it's been solid.

Yellow Key breaks it—but not by attacking the cryptography. The exploit lives in Windows' recovery environment, and specifically in a feature called Transactional NTFS (TxF). The Windows recovery environment supports replaying NTFS filesystem transactions as a way to undo partial or corrupted changes—if a program install went sideways and left your filesystem in a broken state, recovery mode can roll it back. The problem is that in Windows 11, the recovery environment automatically runs a binary called autochk that processes these transactions. And crucially, it will process transactions from an external volume—a USB stick—without much skepticism about where they came from or what they're telling it to do.

Yellow Key exploits this by crafting a USB stick with a malicious NTFS transaction log. When the target machine boots into recovery mode with the USB inserted, autochk replays the transaction—which deletes winpeshl.ini, the file that tells the recovery environment which application to launch. With that file gone, the environment falls back to a default: a command shell. And because the machine has already completed its normal boot sequence, the TPM has already handed the decryption key to the OS. The BitLocker-protected partition is now accessible from that shell.

As Low Level explains it: "Because the TPM has already given the key up to the OS, the OS is now able to use that key to decrypt your Bit Locker partition on demand."

This distinction—that the bug is in the recovery environment, not in BitLocker or the TPM itself—matters more than it might seem. The cryptographic implementation isn't broken. The TPM did its job. What failed was the assumption that anything the recovery environment touches on boot is trustworthy. Windows 10 didn't have this exposure because it didn't run the automatic TxF binary in recovery mode. Windows 11 turned that feature on, and that's the difference.

The immediate mitigation Low Level walks through is registry-level: there's a boot exec flag in the Windows Recovery hive (HKLM\System\CurrentControlSet\Control\Session Manager) that references the autochk binary. Remove the entry, and the TxF transactions don't get replayed automatically in recovery mode. The other mitigation—and the one Microsoft would probably prefer you use—is enabling a TPM PIN. If your TPM requires a physical PIN before releasing the decryption key, an attacker can't get through the boot sequence without knowing it, and Yellow Key as currently documented can't work.

The catch is what Nightmare Eclipse said in a blog post thirteen days before Low Level's video went up: "TPM plus PIN does not help. The issue is still exploitable regardless. I asked myself this question. Can it still work in a TPM pin environment? Yes, it does. I'm just not publishing the PoC."

That's the part that should make anyone paying attention uncomfortable. If there's a separate vulnerability—something that bypasses PIN-mode TPM and gets to the encryption key without the PIN—that's a fundamentally different class of problem. It would imply a break somewhere in the chain between the TPM's sealed key storage and the OS, which is not supposed to be possible without the PIN measurement passing. Low Level is candid about not understanding the mechanism: "How this could work, I really don't understand because again, for the TPM to release a sealed key, if it's in a PIN mode, you have to give it the PIN." That's not a gap in Low Level's knowledge; that's a gap in what's been disclosed. Nightmare Eclipse is sitting on it.

The structural problem here isn't really Nightmare Eclipse. It's the incentive architecture that produced this situation. Bug bounty programs exist to route vulnerability research through controlled channels—give researchers a legitimate economic reason to come to the vendor first. When those programs set arbitrary scope limits, reject findings through definitional games, or simply lowball payouts on high-severity bugs, they erode the trust that makes the whole system work. Researchers with real capability and real findings start doing the math. Some of them decide the only leverage they have is going public.

That calculus is genuinely dangerous. Full public disclosure of an unpatched zero-day puts every vulnerable user at risk, not just the vendor that failed the researcher. The ethics here aren't clean, even when the frustration is legitimate. At the same time, vendors who treat bug bounty scope definitions as a cost-reduction strategy—rather than as a serious commitment to paying fair value for security work—shouldn't be surprised when researchers stop treating the private channel as their only option.

Microsoft has not publicly patched Yellow Key. Nightmare Eclipse has implied there's a deeper variant that TPM PIN doesn't stop. The repos where the technical details lived have been scrubbed from two major platforms.

The code, presumably, is still out there.

By Dev Kapoor, Open Source & Developer Communities Correspondent, Buzzrag