June 12, 2026
GreatXML: Nightmare Eclipse’s Latest BitLocker Bypass Raises New Questions About Disk Encryption…
Microsoft’s June 10 Patch Tuesday is live. So is Nightmare Eclipse’s latest release. GreatXML is a new BitLocker bypass that abuses Windows…
Ali Mansoor
6 min read
Microsoft's June 10 Patch Tuesday is live. So is Nightmare Eclipse's latest release. GreatXML is a new BitLocker bypass that abuses Windows Recovery Environment and a malformed unattend.xml file to unlock a BitLocker-protected volume without credentials. No patch. No CVE. Just a GitHub repo, a working exploit, and a researcher who promised June — and delivered.
The promise kept
On May 29, 2026, Nightmare Eclipse published a PGP-signed blog post announcing Bitskrieg — a Secure Boot violation and BitLocker bypass co-discovered with JonasLyk, scheduled to drop "sometime in June ;)".
On June 10, 2026. Microsoft's June Patch Tuesday just dropped.
So did GreatXML.
The release is characteristically minimal — a GitHub repository under the MSNightmare account, a README with steps to reproduce, an unattend.xml file, a Recovery/WindowsRE directory, and two screenshots showing the result: an unrestricted shell with full access to a BitLocker-encrypted volume, running without any credentials.
No CVE assigned. No coordinated disclosure. No patch in today's Patch Tuesday.
Just working code, published today, on the day Microsoft thought was going to be their day.
What GreatXML actually does
The exploit abuses a combination of two things that shouldn't interact the way they do: Windows Recovery Environment (WinRE) and unattend.xml, the XML-based answer file that Windows Setup uses for unattended installations.
Here is the attack, step by step, exactly as Nightmare Eclipse documented it:
Scenario 1 — If Windows Defender offline scan was ever run on the target machine:
The machine is automatically vulnerable. No login required at any point.
- Copy
unattend.xmland theRecoverydirectory to the root of the recovery partition. - Reboot into WinRE using Shift + click on Restart.
- A shell with unrestricted access to the BitLocker volume spawns.
Scenario 2 — If Defender offline scan has never been run:
Either log in and initiate a Defender offline scan yourself, or find a way to boot into WinRE in offline scan state without logging in. Nightmare Eclipse notes: "I believe it should be very possible to do so without logging in."
The mechanism is the unattend.xml file. Windows Setup's answer file format allows specifying commands to run at various stages of the Windows lifecycle — including during recovery and repair operations. When WinRE processes the malicious unattend.xml placed on the recovery partition, it executes attacker-controlled content in a context that has access to the BitLocker volume before the volume's encryption is enforced.
The result, per the two screenshots in the repository: a command prompt running with unrestricted access to the full contents of a BitLocker-encrypted drive. The encryption that was supposed to protect the data on that drive is effectively circumvented.
Why the Defender offline scan precondition matters
The first scenario's precondition is worth examining: "if Defender offline scan was initiated in the victim machine at any point."
Defender offline scan is not an obscure feature. It's the scan Microsoft recommends running when a machine is suspected of having a rootkit or persistent threat that survives normal scans. IT administrators run it routinely on enterprise endpoints. Many endpoint security policies trigger it automatically under certain conditions.
In enterprise environments — the environments where BitLocker is most commonly deployed and most relied upon — Defender offline scan is a standard tool. The machines most likely to have had a Defender offline scan run are the machines most likely to be targeted by an attacker who has physical access: laptops, field devices, machines recovered from terminated employees.
The precondition that looks like a limitation is actually close to the definition of "enterprise endpoint."
The WinRE attack surface, again
This is not the first time Windows Recovery Environment has been the attack surface for a BitLocker bypass. In 2024, security researcher Synacktiv demonstrated a technique abusing WinRE's update mechanism to bypass BitLocker. Microsoft patched it. The underlying issue — that WinRE runs in a privileged context with access to the encrypted volume before BitLocker's pre-boot authentication is fully enforced — was supposed to have been addressed.
GreatXML suggests that either the 2024 fix didn't address the unattend.xml processing path, or a new path through the same attack surface has been found. Nightmare Eclipse hasn't published a detailed technical analysis, so the exact relationship between GreatXML and the 2024 WinRE fixes is not yet clear.
What is clear: WinRE plus attacker-controlled content on the recovery partition equals BitLocker bypass. The specific mechanism has changed. The outcome has not.
The Patch Tuesday collision
Today's Microsoft June 2026 Patch Tuesday patched 67 CVEs. Among them: critical Remote Code Execution flaws, the resolution of the CVE-2026–41089 Netlogon dispute (Microsoft updated the advisory to acknowledge exploitation, conceding what Belgium's CCB had claimed nine days ago), and a handful of Secure Boot and BitLocker-adjacent fixes.
None of them patch GreatXML. There is no CVE for GreatXML. There is no advisory. There is no patch.
Microsoft's June Patch Tuesday was supposed to be the day they got ahead of Nightmare Eclipse. Instead, it's the day Nightmare Eclipse dropped a new working BitLocker bypass on GitHub while Microsoft was publishing their monthly security update.
The timing is not accidental. Nightmare Eclipse has been consistent about one thing throughout this entire campaign: they understand narrative. Dropping on Patch Tuesday is a statement. Every security team in the world is looking at their patch list right now. Every one of them just got told there's a new BitLocker bypass that isn't on the list.
The campaign scorecard, updated
Seven exploits in ten weeks. Here is where the Nightmare Eclipse campaign stands as of June 10, 2026:
Seven exploits. Ten weeks. The GreatXML row is the only one with no patch in today's Patch Tuesday. Source: github.com/MSNightmare/GreatXML
And Bitskrieg — the Secure Boot violation co-discovered with JonasLyk — has not yet been released. The June winking emoji may have meant GreatXML. Or Bitskrieg may still be coming.
What the coalition looks like now
When I covered Bitskrieg two weeks ago, the Nightmare Eclipse comment section had just become a public defection event. ACD421 — one of the five researchers Microsoft officially credited with discovering BlueHammer — had publicly switched sides and offered full Azure account takeover bugs to Nightmare Eclipse.
GreatXML's repository shows two contributors beyond MSNightmare. The coalition that formed in the Blogspot comments is producing code together now. What started as an anonymous researcher on a free Blogspot has become a multi-contributor GitHub project dropping working exploits on Microsoft's most public security day of the month.
MSNightmare/GreatXML GitHub repository — https://github.com/MSNightmare/GreatXML (June 10, 2026)
Mastercodeon's NuGet RCE chain — described in the Bitskrieg comments as a zero-day MSRC dismissed as "intended functionality by design" — has not yet been published. ACD421's Azure account takeover bugs have not yet been published. The dead man's switch is allegedly still armed. Bitskrieg's full release may still be pending.
What the unattend.xml technique means for defenders
The practical defensive question is: how hard is it for an attacker to place files on the recovery partition?
Harder than writing to the main volume, but not out of reach. Options an attacker with brief physical access could use:
- Boot from external media — a USB with a live Linux environment can mount and write to the recovery partition of most Windows machines before BitLocker's pre-boot authentication kicks in, precisely because the recovery partition is typically not BitLocker-encrypted (it has to be readable by WinRE before keys are available).
- Abuse an existing WinRE session — if an attacker can get the machine into WinRE through any means (forcing a boot failure, using the Shift+Restart path with even brief physical access while the machine is unlocked), they can write to the recovery partition from there.
- Supply chain or insider threat — an attacker with access to the machine's image deployment pipeline can pre-stage the malicious
unattend.xmlbefore the device reaches the end user.
What to do right now
There is no patch for GreatXML today. Mitigations until a patch ships:
- Audit recovery partitions on all BitLocker-protected endpoints. If
unattend.xmlor unexpected directories appear in the recovery partition, treat the machine as compromised and rotate all credentials that were accessible on that device. - Restrict physical access to machines with sensitive BitLocker-protected data. This exploit requires physical access or the ability to write to the recovery partition through another vector. Physical security controls matter here.
- Disable WinRE where it is not operationally required. The command
reagentc /disabledisables WinRE. On endpoints where recovery functionality is managed centrally rather than locally, disabling WinRE removes the attack surface entirely. - Monitor for unexpected Shift+Restart events on managed endpoints. Most endpoint security platforms can log and alert on WinRE entry events. If a managed device enters WinRE unexpectedly, that's worth investigating.
- Check whether Defender offline scan has ever been run on your highest-value endpoints. Scenario 1 of GreatXML's steps to reproduce treats those machines as automatically vulnerable.
What's coming
GreatXML is either the June release Nightmare Eclipse promised, or it's one of two June releases — with Bitskrieg still pending. The dead man's switch is still described as armed. July 14 is still on the calendar. ACD421's Azure takeovers have not dropped yet.
The campaign that started with one anonymous blog post on April 7, 2026 has now produced seven working exploits, survived two platform bans, assembled a multi-contributor coalition, and delivered a new BitLocker bypass on the same day as Microsoft's June Patch Tuesday.
The next post in this series covers whatever drops before July 14. If Nightmare Eclipse's pattern holds, there won't be a long wait.
Follow if you want it in your feed when it happens.
Sources: MSNightmare/GreatXML GitHub repository (June 10, 2026), deadeclipse666.blogspot.com Bitskrieg announcement (May 29, 2026), Microsoft Security Response Center June 2026 Patch Tuesday advisories, CISA Known Exploited Vulnerabilities catalog, prior Nightmare Eclipse campaign coverage (BlueHammer, Bitskrieg, MiniPlasma).