Microsoft BitLocker – YellowKey zero-day exploit

otterley an hour ago | parent | next [-]

Here's the primary source: https://deadeclipse666.blogspot.com/2026/05/two-more-public-...

Other links:

https://github.com/Nightmare-Eclipse/YellowKey

https://github.com/Nightmare-Eclipse/GreenPlasma

AnonC an hour ago | parent | prev | next [-]

The BitLocker exploit seems simple and very dangerous. Companies and individuals have been relying on BitLocker to protect information if the device is lost. Despite promises, Microsoft doesn’t seem to be serious about security.

What will it take for more companies to truly understand their risks with Windows and being locked into Microsoft’s platforms?

▲

ranger_danger an hour ago | parent [-]

How does a bug equate to "not serious about security"?

▲

navigate8310 an hour ago | parent | next [-]

There's no way this is not a backdoor

▲

forestry 36 minutes ago | parent | prev | next [-]

The blog author calls it that but given there’s no root cause yet it’s foolish to jump to conclusions.

▲

Our_Benefactors an hour ago | parent | prev [-]

Read the article. It’s pretty clear that this is a backdoor, and calling it a bug would be so generous as to be misleading.

	▲	forestry 33 minutes ago \| parent [-]
		*in your opinion.

▲

Nition 10 minutes ago | parent | prev | next [-]

This looking so blatantly like an intentional backdoor just makes me wonder even more about TrueCrypt's sudden recommendation in 2014 that everyone switch to BitLocker. This particular backdoor didn't exist then (it's only Win11 apparently) but this sure makes it seem more plausible that another one might have.

Though if TrueCrypt was killed to try and get people to switch to encryption that could be backdoored, then why allow its successor VeraCrypt to exist? Unless... but surely not when it's open source.

▲

ungreased0675 2 hours ago | parent | prev | next [-]

Remarkable. Does MS take a huge reputational hit for having a backdoor, or are they so essential to most places this won’t matter?

▲

peroids an hour ago | parent | next [-]

I’m assuming the EU speeds up the uncoupling cause of some of this.

▲

charcircuit 20 minutes ago | parent | prev | next [-]

It's not an actual backdoor. An attacker found a way to exploit Windows after booting it up in this recovery mode. The security of files on the device depends on it being impossible for Windows to be pwned by an attacker on any surface exposed before the user is unlocked.

This is why operating systems like GrapheneOS disable the USB port on the initial boot to limit the attack surface that an attacker has.

▲

ranger_danger an hour ago | parent | prev [-]

As far as I can tell, there's no concrete evidence that it is actually an intentional "backdoor."

▲

skeptic_ai 20 minutes ago | parent [-]

lol it’s an obvious backdoor. No way a security system would ever allow this blatant workaround to bypass all encryption. Backdoor is the only answer

	▲	majorchord 8 minutes ago \| parent [-]
		> lol it's an obvious backdoor in your opinion

▲

pajko an hour ago | parent | prev | next [-]

Earlier thread: https://news.ycombinator.com/item?id=48114997

▲

bombcar an hour ago | parent | prev | next [-]

How is this even possible, backdoor or no? Isn't the whole point of this type of encryption that even a compromised machine can't decrypt without the passphrase? If this works it means that the key is stored unencrypted somewhere?

	▲	majorchord 35 minutes ago \| parent \| next [-]
		Most setups only have the key stored in the TPM, so all you need to get it back is a signed/trusted bootloader. Ideally you'd want that key to be further protected with a password or some other mechanism because it's not impossible to extract TPM keys.
	▲	andrecarini 41 minutes ago \| parent \| prev [-]
		Presumably the key is stored in the TPM

▲

ranger_danger an hour ago | parent | prev [-]

For those who use password (not PIN) based pre-boot authentication with BitLocker... do we know if that setup is safe?

I can't imagine there would be a way to bypass that if a password is required, unless it was a situation where like, there was originally some secret secondary key made that needs no password... or the password was never tied to the key in the first place.

▲

andrecarini 39 minutes ago | parent [-]

The exploit developer themselves say [1] TPM+PIN is vulnerable, though no public PoC.

[1]: https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...

▲

forestry 35 minutes ago | parent [-]

I’m skeptical of that claim. The key material presumably is inaccessible even to the OS without the passcode.

	▲	ranger_danger 21 minutes ago \| parent [-]
		> presumably That's the thing, we don't actually know how involved the PIN is in relation to the key... it might be completely separate (and hence bypassable). Similarly I also wonder if password-based pre-boot auth is affected.