YellowKey vs GreatXML: What the Difference Actually Is Between the Two BitLocker Bypasses — A Plain-English Comparison
- Patrick Duggan
- 1 hour ago
- 3 min read
People keep asking which is which. Two BitLocker bypasses, released weeks apart, by the same researcher, hitting the same part of Windows — and the names do nothing to tell them apart.
Here is the short answer, then the detail.
YellowKey is patched. GreatXML was not. They arrive through the same door. And GreatXML fires when somebody runs a Microsoft Defender Offline Scan — a defensive action is the trigger.
The one-line definitions
YellowKey (CVE-2026-45585) abuses the FsTx Auto Recovery Utility, autofstx.exe, together with Transactional NTFS replay, to delete winpeshl.ini and hijack the shell that the Windows Recovery Environment launches. Microsoft shipped a mitigation on 21 May 2026 and the broader fix in the June 2026 Patch Tuesday.
GreatXML (CVE-2026-50507) injects configuration through unattend.xml — the answer file Windows setup honours — and reaches BitLocker on machines where a Defender Offline Scan has been used. The researcher called it an accidental find that took about four hours. It was published unpatched, on his own server, after Microsoft banned him.
What they have in common, which is the more important half
Both reach BitLocker through the Windows Recovery Environment. Both are evil-maid problems: they assume someone can get at the machine, or boot it into recovery, and they defeat full-disk encryption from there.
That shared property matters more than either individual bug, because it means the mitigation people reach for first — patch it — addresses the instance and not the condition. Two independent bypasses through WinRE in a matter of weeks is not a coincidence about one function. It says the recovery environment is a standing trust boundary that full-disk encryption quietly depends on, and that boundary keeps turning out to be softer than the encryption in front of it.
Why "which one do I care about" has different answers
If you are patching: YellowKey has a fix, so it is an inventory-and-verify job. GreatXML was published without one, so for a period the only lever was configuration, not updates.
If you are hunting: the triggers are different, and this is where people get it wrong. YellowKey is reached through the recovery path. GreatXML is reached because somebody ran Defender Offline Scan. If your detection logic assumes malicious action precedes compromise, GreatXML inverts that — the security team's own remediation step is the on-switch.
If you are configuring: this is where both point the same way. TPM-only unlock is the configuration that keeps paying for these. A TPM-plus-PIN or passphrase configuration changes the shape of the evil-maid attack substantially, and it does so without waiting for anyone's patch cycle. That is the durable answer, and it was the durable answer before either of these had a name.
The disclosure story, stated flat
The researcher goes by Chaotic Eclipse, also seen as Nightmare-Eclipse and MSNightmare. Microsoft patched YellowKey and banned him. He published the next bypass on infrastructure he controls.
We are not going to editorialise about who was right. We will note the operational consequence, because it is the part that affects defenders: when a researcher stops using the vendor's channel, the vendor's timeline stops being the disclosure timeline. Whatever you think of the ban, the practical effect is that the next finding arrives without a patch, at a moment nobody scheduled, and your exposure window is set by someone with no obligation to you.
That is a supply-side change in how vulnerability information reaches you, and it is worth planning around independently of any opinion about the parties.
The short version
Same door. Different keys. One locked, one that was not. And the thing worth fixing is the door — the recovery environment as a trust boundary, and TPM-only as the configuration that leaves it load-bearing.
If you want the full write-up of the second one, including the Defender Offline Scan trigger and the three-bypass sequence, we covered it when it landed: Microsoft Patched YellowKey and Banned the Researcher. He Dropped His Second BitLocker Bypass on His Own Server.
Was this useful, or did we miss something? Rate this post below — we read every one, and the low scores are the ones that change what we build.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=yellowkey-vs-greatxml-what-the-difference-actually-is-between-the-two-bitlocker-bypasses-a-plain
Comments