Microsoft wrote unattend.xml so that OEM factories could automate Windows setup. GreatXML claims an attacker can copy one to the recovery partition and come back with a shell on a BitLocker-protected volume. The file did exactly what it was designed to do — just in the wrong hands, at the wrong time, inside the one environment that BitLocker trusts to leave the keys alone.

This is not yet a Microsoft-confirmed CVE. Treat it as a public, technically plausible PoC claim with incomplete external validation.

Update, June 11, 2026: The timing is notable. Microsoft’s June 2026 Patch Tuesday cycle is reported to include fixes for three publicly disclosed zero-days, including a BitLocker security feature bypass. NVD’s CVE-2026-45585 record identifies YellowKey by name and says Microsoft issued mitigation guidance until a security update became available. GreatXML appeared immediately after that patch window, which makes it look less like a random one-off and more like the next move in the same recovery-environment research sequence. That is timing analysis, not proof of coordination or motive.

TL;DR

  • GreatXML is a public GitHub repository from MSNightmare that describes a BitLocker-bypass path involving WinRE and unattend.xml.
  • The README claims that if Defender Offline Scan was initiated on the machine at any point, copying unattend.xml and a Recovery directory to the recovery partition can lead to an unrestricted shell against the BitLocker volume after rebooting into WinRE.
  • Microsoft documentation confirms the relevant building blocks: WinRE is a separate recovery environment, Defender Offline Scan boots the computer into an offline scan mode, and unattend files are a legitimate Windows deployment mechanism.
  • The release timing matters: GreatXML followed the June 2026 patch cycle that addressed a publicly disclosed BitLocker bypass, but there is no public Microsoft advisory for GreatXML itself.
  • What is not confirmed: affected versions, repeatability across hardware, whether the offline-scan state can be forced without login, and whether Microsoft considers GreatXML a vulnerability.
  • Defenders should harden BitLocker with TPM+PIN where the threat model includes physical access, monitor recovery partition changes, and treat unexpected WinRE boots as security events.

What Was Published

The MSNightmare/GreatXML repository describes itself as a “GreatXML bitlocker bypass vulnerability.” The README gives a short reproduction path: if Defender Offline Scan was previously initiated on the victim machine, the attacker copies unattend.xml and a Recovery directory to the root of the recovery partition, then reboots into WinRE using Shift+Restart. The repository claims this results in a shell with unrestricted access to the BitLocker-protected volume.

The repository also says that if Defender Offline Scan was never initiated, an attacker would need to log in and initiate it, or find another way to boot WinRE in the offline-scan state. That second path is explicitly speculative in the README. Do not turn it into a confirmed remote or no-login exploitation claim.

The included unattend.xml is not a normal enterprise hardening artifact. The raw file contains command execution behavior that writes and launches a PE command script, starts conhost.exe, and uses PowerShell setup-script logic. That makes the repository useful as a lead for defenders, but it also reinforces why the article should stay precise: this is a PoC claim, not a vendor advisory.

The release also lands at an awkward moment for Microsoft. YellowKey, the previous WinRE/BitLocker bypass in this sequence, was assigned CVE-2026-45585. NVD’s record says Microsoft issued the CVE to provide mitigation guidance until a security update became available, and later Patch Tuesday reporting says Microsoft’s June 2026 update addressed a BitLocker security feature bypass among three publicly disclosed zero-days. GreatXML appearing right after that patch cycle is therefore operationally relevant: defenders should assume the research focus has shifted, not ended.

Why WinRE Keeps Showing Up

Microsoft describes Windows Recovery Environment as a Windows PE-based recovery environment used to repair systems that cannot boot normally. It is present by default on modern Windows client and server installations, and it can be started from the login screen with Shift+Restart, from Advanced Startup, from recovery media, or automatically after boot failures.

That is exactly why WinRE is security-sensitive. It exists outside the normal user session, before endpoint controls and enterprise telemetry look the way they do inside Windows. It also needs enough authority to repair a broken operating system. Any trust mistake in that environment can become a disk-encryption problem, not just a recovery-feature bug.

Microsoft’s own WinRE documentation says encrypted files should not be accessible in recovery unless the user has the key. That is the security promise GreatXML is implicitly challenging.

The Attack Shape

At a high level, the claimed chain is:

  1. A machine has entered or retained a Defender Offline Scan-related recovery state.
  2. The attacker can write unattend.xml and a Recovery directory to the recovery partition.
  3. The machine is rebooted into WinRE.
  4. Windows setup or recovery logic processes the attacker-controlled unattend content.
  5. A command shell appears with access to the BitLocker-protected volume.

The interesting part is not that unattend.xml exists. Microsoft documents unattend answer files as a supported way to automate Windows configuration and deployment. The interesting part is context: if a deployment mechanism is honored inside a recovery/offline-scan path that also gets access to an encrypted OS volume, the recovery environment becomes the weak side of the encryption boundary.

This is the same class of concern as YellowKey, even if the mechanics differ. YellowKey focused attention on WinRE and BitLocker through a different recovery-environment path. GreatXML points at Defender Offline Scan state and unattended setup behavior. The common theme is more important than the branding: BitLocker can be undermined when pre-OS recovery logic is too trusting.

What Is Confirmed, Claimed, and Unverified

StatementStatus
A public GreatXML repository exists with README.md, unattend.xml, screenshots, and a Recovery/WindowsRE directory.Confirmed from GitHub.
The README claims a shell with unrestricted access to the BitLocker volume after copying files to the recovery partition and rebooting into WinRE.Confirmed as the author’s claim.
Microsoft documents WinRE as a Windows PE-based recovery environment available by default on Windows 10, Windows 11, and Windows Server 2016 and later.Confirmed from Microsoft documentation.
Microsoft documents Start-MpWDOScan as starting Windows Defender Offline Scan and causing the computer to start in Windows Defender Offline.Confirmed from Microsoft documentation.
Microsoft documents unattend answer files as a supported deployment automation mechanism.Confirmed from Microsoft documentation.
GreatXML has a CVE, MSRC advisory, or official Microsoft mitigation.Not found as of June 11, 2026.
YellowKey was assigned CVE-2026-45585 and Microsoft issued mitigation guidance before a security update became available.Confirmed from NVD/MSRC-referenced CVE data.
Microsoft’s June 2026 Patch Tuesday addressed a publicly disclosed BitLocker security feature bypass.Reported publicly; treat as YellowKey-related unless Microsoft names the issue differently in the update guide.
The attack works across all Windows 10/11 or Windows Server versions.Unverified.
The offline-scan state can be forced without logging in.Unverified; the repository author presents this as a belief, not a demonstrated step.

That distinction matters. The practical response can begin before a CVE exists, but the wording should not outrun the evidence.

Detection Ideas

There is no stable IoC list yet. Start with recovery-state and filesystem behavior.

Recovery Partition Writes

Monitor for unexpected writes to the recovery partition, especially files or directories matching:

\unattend.xml
\Recovery\
\Recovery\WindowsRE\

On managed endpoints, recovery partition content should be boring. A user-land process writing setup automation files there should be rare enough to investigate, especially if it happens near a Defender Offline Scan event or before a reboot into recovery.

Defender Offline Scan Activity

Microsoft documents Start-MpWDOScan as the PowerShell command that starts a Windows Defender Offline Scan and causes the computer to start in Windows Defender Offline. Treat unexpected offline scans as more than antivirus noise.

Useful hunting questions:

  • Who initiated the offline scan?
  • Was it started from an admin PowerShell session, Windows Security UI, remote management tooling, or something else?
  • Did recovery partition files change before or after the scan?
  • Did the device reboot into WinRE shortly afterward?

WinRE Boots

WinRE entry is normal during support operations, failed boots, recovery workflows, and major repair activity. It is not normal as an untracked event on high-value endpoints.

Correlate:

  • recovery partition writes
  • Defender Offline Scan initiation
  • Shift+Restart or Advanced Startup usage where telemetry is available
  • BitLocker recovery events
  • boot sequence anomalies
  • local admin or physical-access support tickets

For incident response, preserve endpoint timeline data before cleanup. The interesting evidence may be the order of operations, not just the final file state.

Hardening Steps

Use TPM+PIN for High-Risk Devices

Microsoft’s BitLocker countermeasures documentation is clear about the trade-off: TPM-only is convenient, while TPM with PIN adds preboot authentication. For executives, administrators, journalists, incident responders, developers with production credentials, and traveling staff, TPM-only should not be treated as the final answer.

TPM+PIN does not make recovery-environment bugs irrelevant, but it materially changes the physical-access threat model because the encrypted volume should not unlock without the additional factor.

Audit WinRE and Recovery Partition State

Run periodic checks for:

  • whether WinRE is enabled
  • where winre.wim is stored
  • whether recovery partition contents changed unexpectedly
  • whether unattend.xml exists outside approved deployment workflows
  • whether recovery customization exists under paths that should be vendor- or IT-managed only

Administrators can start with:

Terminal window
reagentc /info
manage-bde -protectors -get C:

Restrict Physical and Pre-Boot Paths

Physical controls still matter. Use UEFI passwords where operationally acceptable, enforce Secure Boot, restrict external boot where possible, and treat repair handoffs as a security process rather than a logistics step.

For sensitive fleets, document who is allowed to boot devices into recovery, who may initiate Defender Offline Scan, and how those actions are logged.

Do Not Rely on Reputation-Based Trust

WinRE, Defender Offline Scan, and unattended setup are legitimate Microsoft mechanisms. That is why this class of bug is uncomfortable. The detection model cannot be “Microsoft component equals safe.” It has to be “Microsoft component doing unusual pre-OS work against protected storage equals investigate.”

The Bigger Pattern

GreatXML should not be read as an isolated curiosity. It belongs in the same conversation as YellowKey and RoguePlanet: Windows security boundaries increasingly fail at the interfaces between trusted maintenance components, recovery states, and filesystem behavior.

Attackers like these spaces because they are operationally messy. Recovery environments need broad power. Antivirus offline scans need to run before malware can defend itself. Deployment automation needs to execute scripts. BitLocker needs to unlock only when the boot path is trusted. When those assumptions overlap badly, the result is a security boundary that defenders cannot see clearly enough.

Until Microsoft or independent researchers publish deeper validation, GreatXML is best described carefully: a public BitLocker-bypass PoC claim involving WinRE, Defender Offline Scan state, and unattend processing. That is enough to justify hardening and hunting. It is not enough to claim universal exploitation.

Three tools in quick succession — YellowKey, RoguePlanet, GreatXML — all striking the same seam: the maintenance layer Microsoft built to keep Windows alive when Windows itself cannot be trusted. The recovery environment was not designed to be an attack surface. At this point, it is one.

Sources