Tuesday, 12 May 2026 - "Here are the links, yes, two vulnerabilities this time [YellowKey] [GreenPlasma] [...] Next patch tuesday will have a big surprise for you Microsoft"
Wednesday, 13 May 2026 - "I can't wait when I will be allowed to disclose the full story, I think people will find my crashout very reasonable and it definitely won't be a good look for Microsoft."
Author's blog: https://deadeclipse666.blogspot.com/
First post in March 2026 is "[...] someone violated our agreement and left me homeless with nothing. They knew this will happen and they still stabbed me in the back anyways, this is their decision not mine."
I'm not sure what to make of it, is this someone essentially "leaking" things from the inside? Sure sounds like it, and others are able to reproduce the results.
The published exploit doesn’t affect Bitlocker with a PIN, without which Bitlocker isn’t secure anyway. The original author claims they have an exploit that also works with a PIN, but hasn’t provided any proof of that.
I have never seen a company where they require the pin for bitlocker.
If they put a backdoor into FDE it would make more sense to advise people to stop using windows at all and using Linux instead. If they put a backdoor in FDE you can be sure there is not just one backdoor in the operating system itself. You shouldn't trust proprietary software at all. You shouldn't even trust open source if it isn't properly audited.
>In a normal WinRE session, you have a X:\Windows\System32 directory that has a winpeshl.ini file in it
>However, with the YellowKey exploit, it looks like Transactional NTFS bits on a USB Drive are able to delete the winpeshl.ini file on ANOTHER DRIVE
Interesting. I dont know about this environment - some kind of naive file handle contructing/passing? But then, why require a key press during winre reboot?
I wonder how patachable this is. The thousands of winre thumb drives are certainly out of reach; maybe the bitlocker side update the access permissions? Would it require unenc/reenc?
Seems like lots more to follow
The part that isn't mentioned is that the win re is privileged because windows stores a decryption key in the TPM that allows win re to decrypt the disk even without the recovery key. That's why the attack requires win re in the first place, rather than booting into an ubuntu live cd or whatever. This also means you don't have to patch all the winRE thumbdrives out there because their secureboot signatures can simply be revoked, meaning they can't pass TPM validation anymore, therefore they won't be able to decrypt any disks.
WinRE runs internally, not from a thumb drive, which is why the bootloader will unseal the disk for it (just like if you have a systemd recovery set up on a Linux distribution). It doesn't have a separate key or anything, it's just allowed to use the "main" one, by design. Microsoft just need to patch the WinRE partition in a normal Windows Update to fix the NTFS transaction log driver; no Secure Boot revocation or TPM-related changes are necessary (which is good for them, because _that_ would be a disaster).
By and large this whole thing is orthogonal to BitLocker overall; boot-time unsealed BitLocker is vulnerable to any post-bootloader auth bypass by design, and this is a goofy post-bootloader auth bypass bug.
The researcher claims a way to bypass PIN too but hasn't revealed it.
This won't work because the TPM will only give you the keys if you're booting an "approved" OS, specifically the PCR states that the encryption keys are bound to.
>or if you have to buy a $5 microcontroller and solder it to certain pins on the main board to sniff the TPM keys.
That only works with dTPMs. fTPMs aren't vulnerable to this, and are far more popular than dTPMs.
https://deadeclipse666.blogspot.com/2026/05/were-doing-silen...
Also can recover data without my mainboard.
Maybe a hybrid (secureboot-TPM+phrase) slot for day to day to also prevent against evil maid attacks, and another slot with a backup passphrase would be acceptable.
It's not an either-or. You can combine TPM with passwords which makes it far more secure than password alone. A TPM can enforce password guessing limits, otherwise a password needs to be absurdly long to be secure against GPU bruteforcing attacks. It also prevents someone from swapping out the bootloader with a backdoored version that steals your passwords.
>Also can recover data without my mainboard.
You're supposed to keep a backup of the encryption key when using TPM, in case it fails.
No. I have already explained it here: https://news.ycombinator.com/item?id=48133491
But you can configure Linux LUKS in the exact same way.
This doesn't seem an attack on BitLocker so much as it is an attack on the secure boot chain.
The value of PIN-less unlock is if your threat model is limited to the disk being disposed of or removed from the machine or otherwise separated from the TPM.
Entering a PIN is inconvenient or impossible if more than one user regularly uses the device. Hence, control to validate access is transferred to a trusted OS component.
Securing Microsoft products is busy work while waiting to have it undercut by the next wave of MS’s insane tech debt and greed. And now backdoors!
You can enable ADP for E2E encrypted backups, but it's probable not going to help you much, because the people you are communicating with likely didn't.
This is not to defend Microsoft, more to say that all these companies were part of PRISM.
The author claims to be able to bypass TPM + PIN protection, but I seriously doubt it because that would require breaking or exploiting the TPM itself. Perhaps the author was referring to existing fTPM flaws but even then, brute-forcing the PIN would still be required because on BitLocker, the wrapped VMEK depends on the PIN, which brings me to the "backdoor" topic. As I have already mentioned, exploits have been found in AMD fTPMs in the past (https://arxiv.org/abs/2304.14717). This flaw is particularly severe on Linux/cryptenroll because the TPM returns the actual FVEK, unlike BitLocker, where the VMEK itself depends on the PIN. This cryptenroll flaw has been known for years and remains unfixed on cryptenroll (https://github.com/systemd/systemd/pull/27502). Yet, I see no one yelling and crying "backdoor", or accusing Lennart of being compromised. Cryptography, especially when combined with hardware security, is inherently not easy — and people make mistakes.
No one should have their data encrypted and kept from them without consent unless they do something. Microsoft does that now. They may not be requring a monetary ransom like others, but it is a ransom nevertheless.
I know this is controversial. Bitlocker helps protect one's property and information when used intentionally. And that being impacted is a shame.
I recently (last week) had to drive over to a parent's house and "fix" their (pre-online accounts) win 11 computer used for sewing because it had become a blue screen saying aka.ms was required. They did not know how it happened and are not very technical users so I imagine they were tricked by some click-through dialog. It is not something they would ever do intentionally. All that computer ever does is run sewing pattern/control software.
I do not want someone stealing my laptop on a train ride potentially being able to have all of that data.
With a proper real backup strategy, i have everything save. I do not need easy access to a hard drive from a broken computer.
But hey you do you :)
I suppose this makes some sense for home computers (burglars and police raids are rare) but for a laptop, you really don't want thieves getting all your details.
Ironically -- this probably was paranoid a few years ago, but now -- "ChatGPT, use this prepared prompt to extract all useful info from this hard drive"
Prevailing theory is they were pressured to put in a backdoor and couldn't disclose it, so they had to make a seemingly ridiculous statement (because who in their right mind would trust bitlocker) to call attention that "something is very wrong"
- The device isn't PIN-protected (doesn't ask for a Bitlocker password on startup)
- It runs a vulnerable version of Windows (apparently anything after 10 and before whatever version Microsoft will probably patch it in)
The way one would backdoor something like Bitlocker is to encrypt the disk encryption key with a (post-quantum) public key for which only the backdoor owner has the private key for, and then put it on a place on disk that is unused by the filesystem.
If it's a backdoor, that's a serious fraud against their customers.
If you really think this will be prosecuted as fraud, then you'll be shocked by how American courts handle these sorts of things.
At the point where you're able to mount the EFI partition and effectively modifying the bootloader, it's game over anyway - just run `manage-bde -unlock`, you already have to be root to mount the EFI partition.
What does this even mean? Nobody is using multiple encryption schemes on top of each other, are they?
If you want to encrypt some data that gets stored persistently somewhere on your machine, rather than invent an application-specific encryption scheme for that data alone, instead use a mainstream full-partition encryption mechanism, then store the data as plaintext within said partition.
source: trust me bro
