Introduction
One malicious XML file dropped into the right partition, one reboot into recovery mode — and BitLocker stops protecting anything. That is the attack scenario enabled by GreatXML, a zero-day exploit published on June 11, 2026 by security researcher Nightmare Eclipse. With no CVE assigned and no Microsoft patch on the horizon, IT teams relying on BitLocker as their primary endpoint protection layer need to reassess their exposure now.
A Vulnerability in the Pre-Boot Environment
GreatXML abuses an undocumented interaction between Windows Defender Offline Scan and the Windows Recovery Environment (WinRE). Defender Offline Scan is a built-in feature that analyses a system before it fully boots, running from a minimal environment — and it is widely enabled through Intune or SCCM security policies across enterprise Windows fleets.
That's precisely where the exploit condition lies. If the offline scan has been run at least once on a machine, an attacker with physical access can copy a malicious unattend.xml file to the root of the recovery partition. When the system is rebooted into Recovery mode — accessible via Shift + Restart — Windows loads that file without adequate validation. A command prompt opens with SYSTEM-level privileges, the decrypted volume fully accessible, and BitLocker rendered useless — without a single encryption key ever being compromised.
Seven Zero-Days in Ten Weeks Against the Same Components
GreatXML doesn't exist in isolation. It is part of a sustained public campaign that Nightmare Eclipse has been running since early April 2026, releasing seven zero-day exploits in ten weeks targeting Microsoft Defender and its components — including BlueHammer, RedSun, UnDefend, GreenPlasma, YellowKey, and, the day before GreatXML, RoguePlanet. RoguePlanet exploits a race condition in Defender's file-processing pipeline to achieve SYSTEM privileges on a fully patched machine, including systems running June 2026 updates.
The cadence is deliberate. The researcher, who reportedly launched this public disclosure campaign following a public falling-out with Microsoft's vulnerability disclosure programme, releases each exploit before a fix exists. Some of these zero-days have since received CVEs and official mitigations — YellowKey (CVE-2026-45585), which also targeted WinRE, is one example. GreatXML, released two weeks later, has received no official response.
What IT Teams Should Do Now
BitLocker remains a robust encryption mechanism, but GreatXML reinforces a structural reality that YellowKey had already exposed: WinRE and the recovery partition represent a distinct attack surface, one that is too often left outside the security team's monitoring perimeter. TPM-only configurations — the most common deployment mode in enterprise environments — are particularly exposed to unattended physical access scenarios.
With no patch available, the following measures meaningfully reduce risk:
- Restrict physical access to critical workstations and enforce BIOS/UEFI passwords to control Recovery boot options.
- Monitor recovery partition changes through your EDR solution, with alerts triggered by any unexpected modification to WinRE files.
- Switch from TPM-only to TPM + PIN mode: this does not eliminate the WinRE attack surface, but it substantially raises the bar for physical exploitation.
- Review the use of Defender Offline Scan in your Intune or SCCM policies — this feature is the prerequisite for GreatXML exploitation and can often be replaced by standard online scanning.
This attack does not break cryptography. It sidesteps encryption entirely by targeting the system layer surrounding it — a reminder that endpoint security is never reducible to a single line of defence.