1. Executive summary

GreatXML is a public proof-of-concept, released on 10 June 2026 by the researcher Nightmare Eclipse / Chaotic Eclipse / MSNightmare, claiming a BitLocker bypass. The technique abuses the Windows Recovery Environment (WinRE), the state left behind by Microsoft Defender’s Offline Scan feature, and the legitimate processing of unattended setup answer files (unattend.xml). The claimed outcome is a command shell with unrestricted access to the BitLocker-protected volume, while BitLocker continues to report the volume as protected.

The threat model relies on physical access. Because BitLocker is a data-at-rest protection control, the relevant scenario is that of lost, stolen, or unattended endpoints, not a remote compromise.

The reliability of the technique is debated. A third-party researcher (Will Dormann) judged the write-up flawed, with the shell appearing only on the next offline scan, which ties the trigger to the offline-scan boot path rather than to a plain WinRE startup.

2. Attack chain (defender level)

The claimed chain, as described by public analyses, can be summarised as follows:

1. The machine is in a recovery state related to a Defender Offline Scan (state retained after a scan has been initiated at least once).
2. The attacker writes an unattend.xml file and a Recovery directory to the root of the recovery partition.
3. The machine is rebooted into WinRE (Shift + Restart, Advanced Startup, recovery media, or automatic boot after failure).
4. The setup or recovery logic processes the attacker-controlled unattend content.
5. A command shell opens with access to the encrypted volume.

The critical point is not the existence of unattend.xml, which is a supported Windows deployment mechanism. The problem is contextual: a deployment mechanism is honoured inside a recovery or offline-scan path that also has access to the operating system volume. The recovery environment then becomes the weak side of the encryption boundary.

3. Technical primitives involved

WinRE (Windows Recovery Environment). A Windows PE-based recovery environment, present by default on Windows 10, Windows 11, and Windows Server 2016 and later. It runs outside the normal user session, before endpoint controls and enterprise telemetry are fully active, and it holds the authority required to repair a system. Microsoft documentation sets out, as a security promise, that encrypted files should not be accessible in recovery without the key: it is this promise that the technique challenges.

unattend.xml. An unattended setup answer file, designed to automate the configuration and deployment of Windows. It can carry command-execution logic. According to the public defensive analysis of the PoC, the file bundled in the repository is not an enterprise hardening artefact: it writes then launches a script, starts conhost.exe, and relies on PowerShell setup-script logic. This characterisation serves as a detection indicator. The exact payload is deliberately not reproduced here.

Defender Offline Scan state. The offline scan reconfigures the boot path to start the machine into a scan mode within the recovery environment. It is this reconfiguration that, according to the claim, places the recovery partition into an exploitable state. The third-party reproduction test locates the effective trigger at the time of the following offline scan.

4. Pre-conditions and scope

• Claimed pre-condition: a Defender Offline Scan initiated at least once on the machine.
• Alternative path, described as speculative by the author himself: without a prior offline scan, the attacker would need to log in and initiate one, or find a way to boot WinRE into the offline-scan state. This path must not be presented as a confirmed remote or no-login exploitation.
• The technique is reported to have been demonstrated on Windows 11 24H2 (build 10.0.26100.x).
• The bypass is said to target in particular BitLocker configurations using TPM-only, which impose no secret at startup.

5. Confirmed / claimed / unverified

Item	Status
Public GreatXML repository (README, unattend.xml, screenshots, Recovery/WindowsRE directory)	Confirmed
A shell with unrestricted access to the volume after copying the files and booting WinRE	Author’s claim
WinRE as a default PE recovery environment, and unattend as a legitimate deployment mechanism	Confirmed (Microsoft documentation)
Affected versions, hardware repeatability, no-login triggering	Unverified
Recognition of the issue as a vulnerability by Microsoft	Unconfirmed
CVE assignment and patch	None as of the drafting date

6. Detection and hunting

• Recovery partition integrity: monitor the appearance or modification of unattend.xml at the root of the recovery volume, as well as changes to \Recovery\WindowsRE\ReAgent.xml and the Recovery directory outside a legitimate deployment context.
• WinRE state: reagentc /info to capture the image location, identifier, and status. Any unplanned change is a signal.
• Defender state: Get-MpComputerStatus to verify the operating mode and any trace of an initiated offline scan.
• BitLocker protectors: manage-bde -status to identify volumes on TPM-only versus TPM+PIN.
• Boot logs: transitions to WinRE or Advanced Startup outside maintenance windows, treated as security events.
• File indicators: presence of unattend.xml and ReAgent.xml on the recovery volume outside deployment, launching of conhost.exe or unexpected scripts from WinRE.
• Physical indicators: traces of physical access, external boot, or chassis tampering.

7. Remediation

Defensive measures independent of a vendor patch.

• Pre-boot authentication (priority): move from TPM-only to TPM+PIN. Since the key is not released without the PIN, the recovery path cannot reach an auto-unlocked volume. Per host: manage-bde -protectors -add C: -TPMAndPIN. Across the fleet: GPO or Intune policy “Require additional authentication at startup”. To be validated against your threat model.
• WinRE hardening: maintain the integrity and update level of the WinRE image (see the WinRE update sequence related to KB5025885), control the use of reagentc, and consider disabling WinRE on high-risk profiles, at the cost of recovery capability.
• Physical security: firmware or UEFI password, Secure Boot enabled, external boot disabled, tamper-evident seals and chassis locking.
• Offline scan control: restrict and log the triggering of Defender’s offline scan.
• Patch tracking: monitor for a CVE assignment and a Microsoft patch, this disclosure being part of the YellowKey sequence (CVE-2026-45585, fixed in the June 2026 Patch Tuesday).

8. PoC location and status

The proof-of-concept is published on a public GitHub repository under the MSNightmare identity and replicated across two independent Git forges. The three addresses appear in the body of the original post. They are not relayed in this note, for consistency with a responsible disclosure practice, and because replication across several forges makes any single takedown ineffective: the PoC must be considered as disseminated, regardless of the state of any individual page.

9. Series context

GreatXML is part of a series of uncoordinated disclosures by the same author, motivated according to his statements by a dispute with Microsoft’s reporting process. Associated disclosures: YellowKey (CVE-2026-45585), BlueHammer (CVE-2026-33825), RedSun (CVE-2026-41091), UnDefend (CVE-2026-45498), GreenPlasma, and RoguePlanet. The cadence and the proximity to the June 2026 Patch Tuesday suggest a continued focus on the recovery environment.

10. Sources

• Hive Security, GreatXML: When a Setup File Unlocks BitLocker, 11 June 2026 (defensive analysis, WinRE/unattend primitives): https://hivesecurity.gitlab.io/blog/greatxml-bitlocker-bypass-winre-defender-offline/
• The Register, Nightmare Eclipse drops claimed BitLocker bypass for Microsoft Windows, 11 June 2026 (third-party reproduction, W. Dormann): https://www.theregister.com/security/2026/06/11/nightmare-eclipse-drops-claimed-bitlocker-bypass-for-microsoft-windows/5254371
• SecurityWeek, GreatXML Zero-Day Exploit Bypasses BitLocker, 11 June 2026: https://www.securityweek.com/greatxml-zero-day-exploit-bypasses-bitlocker/
• The Hacker News, New GreatXML Exploit Bypasses Windows BitLocker via Recovery Partition XML Files, 11 June 2026: https://thehackernews.com/2026/06/new-greatxml-exploit-bypasses-windows.html
• GBHackers, GreatXML Zero-Day Enables BitLocker Bypass Through Windows Defender Offline Scan, 11 June 2026: https://gbhackers.com/greatxml-zero-day-enables-bitlocker-bypass/
• CybersecurityNews, GreatXML BitLocker Bypass 0-Day Exploited Via Windows Defender Offline Scan, 11 June 2026: https://cybersecuritynews.com/greatxml-bitlocker-bypass-0-day-exploited/
• IT-Connect, Microsoft fixes YellowKey, but GreatXML zero-day bypasses BitLocker, 11 June 2026: https://www.it-connect.tech/microsoft-fixes-yellowkey-but-greatxml-zero-day-bypasses-bitlocker/
• Original post (Blogger), published 10 June 2026, content state verified 12 June 2026: https://deadeclipse666.blogspot.com/2026/06/greatxml-bitlocker-that-seems-to-only.html