Zero-Day Exploit Against Windows BitLocker

It’s nasty, but it requires physical access to the computer:

The exploit, named YellowKey, was published earlier this week by a researcher who goes by the alias Nightmare-Eclipse. It reliably bypasses default Windows 11 deployments of BitLocker, the full-volume encryption protection Microsoft provides to make disk contents off-limits to anyone without the decryption key, which is stored in a secured piece of hardware known as a trusted platform module (TPM). BitLocker is a mandatory protection for many organizations, including those that contract with governments.

Slashdot thread. And here’s Nightmare-Eclipse’s GitHub account.

Tags: BitLocker, exploits, Windows, zero-day

Posted on May 18, 2026 at 7:08 AM • 13 Comments

Comments

mw • May 18, 2026 7:32 AM

If someone thinks his data is safe even when not uploading the bitlocker key to Microsoft, it isn’t. Do NOT use bitlocker if your data should be private in all circumstances. IMHO use Veracrypt or, if running GNU/Linux, Zulucrypt.

Clive Robinson • May 18, 2026 8:52 AM

@ mw, ALL,

With regards,

“Do NOT use bitlocker if your data should be private in all circumstances. IMHO use Veracrypt or, if running GNU/Linux, Zulucrypt.”

Hmm, I would look on things a bit differently for,

“Private in all circumstances”

I’ve no reason to think that Veracrypt/Zulucrypt are not secure but… I’ve good reason to think their popularity will have made them targets for the various “XX-Eyes” and other SigInt and Level III entities.

So on probability I would look on them as more like the “lock on the shed rather than a lock on a vault door”. That is,

“There to keep honest people honest, and maybe slow down the dishonest”.

For many years I’ve told people to,

“Use different encryption on all layers of the Bag of Bits”

So the file, the file metadata, filesystem and communications paths get their own separate confidentiality security,

“From the keyboard all the way down the stack, and back up to the App, up and down from the screen and mouse and down the stack from the app to the rust on the platter and the same in reverse.”

This is not a new idea, it’s in essence how TENPEST/EmSec design for “segregation” is supposed to work. That is each interface is encrypted and uses different algorithms and keys that are never stored as “plaintext” with user plaintext only available in the UI.

It’s this last bit Microsoft got wrong either deliberately or due too ignorance, and why this vulnerability is there.

Microsoft were responsible for the “Trusted Platform Module”(TPM) being on every commercial / consumer PC, and the fact that the keys inside the TPM were stored in “plaintext”.

It’s this Plaintext “Keying Material”(KeyMat) storage/use that is the reason this vulnerability is there.

Apple on the iPhone at least tried originally to stop this attack route by encrypting all KeyMat behind a “something you know” authentication factor such as a password/phrase unique to the user they had to enter. Hence the US FBI and DoJ going to court against Apple and “bailing out” before a presidence unfavorable to them was set.

Microsoft have never ever been interested in “end user security” and there is sufficient evidence against them to call into question the old saw of,

“Never attribute to malice what can be attributed to incompetence / ignorance / stupidity.”

It might not originally have been “Malice a fore thought” but at some point Microsoft decided user privacy was only payed a “lip service”.

P.S. For those that want a slightly deeper explanation I gave one to ‘@broken goddess” just a few days back on this blog,

https://www.schneier.com/blog/archives/2026/05/friday-squid-blogging-bigfin-squid.html/#comment-454487

If and when we get more in depth information I’ll give it the hairy eyeball and comment 😉

Rontea • May 18, 2026 9:51 AM

BitLocker’s TPM-only mode has long been a convenience feature, not a robust defense against physical attackers. YellowKey demonstrates exactly why relying solely on hardware-backed keys without a pre-boot PIN is risky: if an attacker can get the system to load a recovery environment—or, in this case, a manipulated transactional NTFS state—they can bypass protections entirely.

Vesselin Bontchev • May 18, 2026 11:14 AM

“Exploit”? I’d reserve that to (ab)using a vulnerability. This is not a vulnerability; it is clearly a backdoor.

Vesselin Bontchev • May 18, 2026 11:23 AM

For example, this is an exploit of a BitLocker vulnerability.

Clive Robinson • May 18, 2026 1:08 PM

@ Vesselin Bontchev, Weather,

I recognise some of “the style”, if I’m not mistaken it’s the work of “Zammis Clark” who has an interesting background,

https://www.ign.com/articles/2019/03/29/security-researcher-arrested-for-hacking-into-microsoft-and-nintendo

As they say “it’s a small world” 😉

And as another case of synchronicity I posted to @Weather earlier today about the failings of malloc() I’d abused in many ways in the past,

https://www.schneier.com/blog/archives/2026/05/friday-squid-blogging-bigfin-squid.html/#comment-454505

People tend to forget that what gets written to RAM stays there even beyond a “power up reset cycle” and sometimes beyond a not so short “brown out power cycle”.

It’s just one way “secrets never stay secret”.

cls • May 19, 2026 12:08 AM

For many years I’ve told people to,

There it is again. Nothing new, don’t need to read the rest.

iAPX • May 19, 2026 6:33 AM

but it requires physical access to the computer

That’s the point for BitLocker, FileVault and others : it is meant to protect against physical access attacks.
Main scenario being a stolen computer, usually a laptop, containing either a company’s IP and/or PII.

That is exactly why all storages (internal and external) should be strongly encrypted by default.

BitLocker doesn’t protect correctly against this type of attack it was designed for and advertised for. This is shameful.
And I agree that it looks like a backdoor…

Anonymous observer • May 19, 2026 6:38 AM

Nothing new, don’t need to read the rest.

There it bleats again just a sheeple at the gate wanting to get in, but with nothing of worth…

Not really anonymous • May 19, 2026 10:40 AM

It may be that corporations use it primarily to avoid the costs of notifications if a laptop with user data is lost or stolen. They can plausibly claim the data can’t be recovered, even though without a PIN, bitlocker doesn’t protect against attacks with people that posess the hardware and have tools to access memory. So unless someone actually recovers the data and makes it known that they have it, it can save corporations a lot of money.

bork • May 19, 2026 1:34 PM

New Windows ‘MiniPlasma’ Zero-Day Exploit Gives SYSTEM Access, PoC Released

https://it.slashdot.org/story/26/05/18/1946245/new-windows-miniplasma-zero-day-exploit-gives-system-access-poc-released

A researcher known as Chaotic Eclipse has released a proof-of-concept exploit for a new Windows zero-day dubbed MiniPlasma, which BleepingComputer confirmed can grant SYSTEM privileges on fully patched Windows 11 systems. The researcher claims the bug is effectively a still-exploitable version of a 2020 flaw Microsoft said it had fixed.

Celos • May 20, 2026 4:57 PM

Disk encryption is primary only helpful if the disk or the (non-running) system gets physically stolen. Hence this is a big deal as it kills the primary use of BitLocker.

Is it just me or does it look moore and more like Microsoft is not keeping up with the threat landscape?

anonymouse random • May 22, 2026 5:22 PM

Using Bitlocker without a PIN was always insecure, since it permits a physically-present attacker to boot the system without credentials, which unlocks the Bitlocker volume. During boot, the system is then potentially vulnerable to issues like those described in the main post. It is also potentially vulnerable to DMA attacks, though memory encryption (e.g., Intel TME) can reduce this exposure.

If you use Bitlocker, use a PIN. And make it a good one, not 4 digits.

Schneier on Security

Zero-Day Exploit Against Windows BitLocker

Comments

Leave a comment Cancel reply