New 'GreatXML' Bypass Cracks Windows BitLocker Through the Recovery Partition

Full-disk encryption is supposed to be the last line of defense when a laptop is lost, stolen, or seized. If the disk is locked with BitLocker, the assumption is that an attacker with physical access still walks away with nothing readable. A newly released technique called GreatXML challenges that assumption in an uncomfortable way.

The bypass comes from a security researcher who goes by Chaotic Eclipse (also known as Nightmare-Eclipse and MSNightmare), and it landed just a day after the same researcher dropped an exploit targeting Microsoft Defender. According to their writeup, GreatXML was not the product of a long campaign. "This was an accidental discovery, it took a total of 4 hours to find this," they wrote. The hook that makes this one worth paying attention to is the trigger condition: "If you ever attempted to use Windows Defender Offline Scan, you're automatically vulnerable to a BitLocker bypass."

How the attack actually works

The mechanics are almost insultingly simple, which is part of why it matters. The exploit hinges on the Windows Recovery Environment (WinRE), the minimal recovery OS that Windows boots into for repairs, resets, and offline scans.

The steps Chaotic Eclipse describes are:

1. Copy an unattend.xml file to the root of the recovery partition.
2. Copy a recovery folder containing a second XML file at Recovery/WindowsRE/ReAgent.xml to the same partition.
3. Reboot into WinRE by holding Shift while clicking Restart in the Windows power menu.

If each step is followed correctly, the payoff is a shell with unrestricted access to the BitLocker-protected volume. No PIN, no recovery key, no TPM challenge that the attacker has to satisfy.

The unattend.xml file is the key abuse primitive here. Windows setup and recovery flows read these answer files to automate configuration, and they have historically been a soft spot because they can carry commands and credentials that the OS trusts during early boot. By planting a crafted answer file where WinRE will read it, the attacker steers the recovery environment into running with access it should never hand out on an encrypted machine.

The Defender Offline Scan connection

The detail that elevates GreatXML from a niche trick to a broad exposure is the link to Windows Defender Offline Scan. That feature reboots the machine into WinRE to hunt for malware that hides while the main OS is running, and in doing so it appears to leave the recovery partition in a state the exploit can take advantage of.

Chaotic Eclipse was candid about the edges of their own understanding. "I'm unsure if you can still trigger the bug without ever using the offline scan feature, because you can definitely," they said, before adding that an attacker who finds the feature unused has options: "If Defender offline scan was never initiated then you have to either login and initiate it yourself or figure out a way to boot into WinRE in offline scan state (I believe it should be very possible to do so without logging in) and follow steps above."

In plain terms: machines where a user or admin has ever kicked off an offline scan are the easy targets. Even machines that have not are likely reachable with a bit more setup.

A pattern, not a one-off

GreatXML did not arrive alone. It is the second BitLocker bypass from this researcher, following YellowKey, tracked as CVE-2026-45585, which Microsoft addressed in this week's Patch Tuesday release. A day before GreatXML, the same researcher published RoguePlanet, a zero-day in Microsoft Defender that allows local privilege escalation to SYSTEM, giving an attacker a path to run arbitrary code on the box.

That cadence, three offensive Windows security releases in quick succession touching Defender and BitLocker, points at a common theme. The recovery and security tooling baked into Windows operates with high privilege and runs in environments (early boot, recovery, offline scanning) where normal protections are relaxed by design. Those are exactly the seams attackers probe, because a flaw there sidesteps the controls that would otherwise stop them cold.

What this means in practice

It helps to be clear about the threat model. GreatXML is a physical-access, local attack. An attacker needs to get to the machine, write files to the recovery partition, and reboot it. This is not a remote, internet-wide problem, and it does not mean your encrypted drive is being read over the network. What it threatens is the specific protection BitLocker is supposed to provide: keeping a lost or stolen device's data out of reach.

For that reason, the people who should care most are those whose threat model includes device theft, evil-maid scenarios, border seizures, or shared and kiosk hardware. If your organization treats BitLocker as the control that lets you classify a lost laptop as a non-event, this technique pokes a hole in that reasoning.

Practical steps while details settle and patches land:

• Apply this week's Patch Tuesday updates now. YellowKey (CVE-2026-45585) is already fixed, and staying current is the fastest way to absorb whatever follow-up Microsoft ships for the GreatXML class of issue.
• Require a BitLocker pre-boot PIN or passphrase, not TPM-only unlock. TPM-only configurations release the key automatically during boot, which is precisely the kind of automation these recovery-path attacks lean on. A pre-boot secret forces the attacker to supply something they do not have.
• Lock down WinRE access. Administrators can disable or harden the recovery environment with reagentc /disable, and should treat the ability to boot into WinRE as a sensitive capability rather than a convenience.
• Protect the recovery partition. Monitor for unexpected writes of unattend.xml or ReAgent.xml to recovery partitions, and audit which machines have run Defender Offline Scan.
• Lean on physical controls. Secure boot order, firmware passwords, and physical security reduce an attacker's ability to reboot into a controlled state in the first place.

The broader takeaway for defenders is that answer files and recovery tooling deserve the same scrutiny as any other privileged code path. unattend.xml abuse has surfaced repeatedly across Windows deployment and recovery scenarios, and GreatXML is another reminder that a file format designed for automation becomes a liability the moment a high-privilege process reads it from an attacker-controlled location. BitLocker remains worth running, it raises the cost of an attack considerably, but pairing it with a pre-boot secret and hardened recovery options is what keeps it honest against techniques like this one.