Microsoft Patched YellowKey and Banned the Researcher. He Dropped His Second BitLocker Bypass on His Own Server — and Running a Defender Scan Is the Trigger. GreatXML.
- Patrick Duggan
- 5 minutes ago
- 5 min read
We have been following a researcher who calls himself Chaotic Eclipse — also tracked as Nightmare-Eclipse — for two months, and the story keeps escalating in a direction Microsoft clearly did not anticipate. We wrote about his Defender vulnerabilities in April. We wrote on June 5 that Microsoft responded to his disclosures by banning him from its own GitHub and referring him to its crimes unit. We wrote on June 11 that within hours of Microsoft quietly patching his GreenPlasma bug, he dropped a working exploit. And yesterday we wrote about YellowKey, the BitLocker bypass — CVE-2026-45585 — that Microsoft credited to him and patched in the June Patch Tuesday. We thought yesterday's post closed his June chapter. It did not. He has now released a second BitLocker bypass, this one unpatched, and he did not put it on GitHub, because he cannot. He put it on his own server.
What GreatXML Is — And What It Isn't
GreatXML is a newly-released BitLocker bypass that Chaotic Eclipse published this week. We want to be precise about its status before anything else, because precision is the whole product: this is a public proof-of-concept claim, technically plausible and consistent with the recovery-environment weaknesses we already know are real, but it is not yet a Microsoft-confirmed CVE with an assigned identifier and an official advisory. Treat it as a credible claim from a researcher whose track record this quarter is "keeps being right about Microsoft's own products," not as a vendor-acknowledged vulnerability. With that caveat load-bearing, here is the mechanism, because the mechanism is why it matters. An attacker with physical access places an unattend.xml file and a crafted Recovery directory in the root of the machine's recovery partition, then reboots into the Windows Recovery Environment — WinRE — using Shift plus Restart. On a vulnerable machine, a shell spawns automatically with unrestricted access to the BitLocker-protected volume. No password, no recovery key, no decryption challenge. The encryption that is supposed to make a stolen laptop worthless is simply off.
The Trigger Is Running Microsoft's Own Malware Scanner
Here is the detail that turns GreatXML from "another evil-maid bug" into something with a genuinely dark sense of humor. The precondition for the machine being vulnerable, per the researcher, is that the victim at some point initiated a Microsoft Defender Offline Scan. A Defender Offline Scan is the thing Microsoft tells you to run when you suspect deep infection — it reboots the machine into a trusted recovery environment to scan from outside the running OS, precisely so malware cannot hide. That reboot-into-WinRE behavior is what leaves the door GreatXML walks through. So the sequence of events Microsoft is offering its customers is: we think you might be infected, so run our offline scanner, which makes you vulnerable to a full-disk-encryption bypass that the researcher we banned just published. Running the security feature is the vulnerability. The researcher described finding it as "an accidental discovery" that "took a total of 4 hours." Four hours, by accident, against the encryption millions of organizations treat as their last line for data at rest.
Three Bypasses In Eight Days, And The Recovery Partition Is The Common Door
Step back from the individual bugs and the pattern is the story. In the span of about eight days, the Windows BitLocker bypass count went to three. CVE-2026-50507 and YellowKey/CVE-2026-45585 both shipped as acknowledged bypasses in the June 9 Patch Tuesday — two separate flaws, same class, same release. GreatXML makes three, and two of the three came from the same hand. The common thread running through them is not a single line of vulnerable code; it is the Windows Recovery Environment itself. WinRE is a trusted, pre-boot context that can touch the encrypted volume because it has to be able to repair it — and a trusted context that can reach your data is exactly the thing an attacker wants to reach. The recovery partition is the door nobody guards, because defenders think about BitLocker as the thing that protects data at rest and stop thinking once the checkbox is green. The researchers are demonstrating, one bypass at a time, that the recovery path around BitLocker is softer than BitLocker itself. When three bypasses land in eight days against the same subsystem, that subsystem is not having a bad week. It is structurally under-defended, and the people poking at it have noticed.
The Persecution Backfired In Public, Again
We have made this argument before and GreatXML is the cleanest proof of it yet, so we will make it once more. Microsoft spent six weeks trying to criminalize Chaotic Eclipse — banning him from GitHub, referring him to its crimes unit — and the result is not silence. The result is that his disclosures moved off Microsoft's platform and onto infrastructure Microsoft does not control. GreatXML was not published to a GitHub repo Microsoft can take down with a terms-of-service complaint. It was published to the researcher's own server, on his own domain, beyond Microsoft's reach. That is the entirely predictable consequence of treating disclosure as a crime: you do not stop the disclosure, you just lose your visibility into it and your leverage over it. A researcher hosting his own findings on his own infrastructure, immediately after you patched his last bug and while your customers are still exposed to his newest one, is a worse outcome for everyone — including Microsoft — than the coordinated disclosure relationship that was on offer before the bans started. We said on June 5 that scorched earth is what you get when the process breaks down on both ends. GreatXML is the scorched earth.
What A Defender Does
Treat the BitLocker recovery path as the attack surface it has now demonstrably become. First, apply the June Patch Tuesday updates that fix CVE-2026-50507 and CVE-2026-45585 if you have not — those two are confirmed and patched, and there is no reason to still be exposed to them. Second, for GreatXML specifically, until there is a confirmed CVE and a patch, reduce the precondition and the physical-access path: the bug keys on WinRE reachability and on the recovery partition being writable by someone with physical access, so enable pre-boot authentication — TPM plus a PIN — so the volume does not unseal its key to anyone who simply boots the machine, lock the boot order and disable booting from external media in firmware behind a firmware password, and treat the recovery partition as sensitive rather than as plumbing. Third, fix the policy reflex: if your incident playbook auto-classifies a lost encrypted laptop as a non-event, that assumption is now wrong three times over in eight days, and the caveat is that "encrypted" only holds if the device is patched against the bypasses and physically controlled. And watch the researcher's own server, not just GitHub and the CVE feeds, because that is where the next one will land — we will be watching it, and we will say so when it does, because the disclosures did not stop. They just moved.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.