YellowKey: Technical Analysis of a Potential BitLocker Recovery Attack

YellowKey: What Is Known So Far

On 12 May 2026, a security researcher operating under the GitHub account Nightmare-Eclipse published a repository named YellowKey. The repository describes a potential attack path against the BitLocker full-disk encryption protection in Windows 11, as well as in Windows Server 2022 and 2025. According to the repository, physical access to the device is required – either a prepared USB stick or direct access to the EFI partition is described as enabling access to the affected volume within the recovery context.

According to the README in the repository, the root cause lies in a component that is only active inside the Windows Recovery Environment (WinRE) and which reacts to a specific folder structure named FsTx inside the System Volume Information directory. The author explicitly describes this in the repository description as a “(potential) backdoor” and, in the acknowledgements, credits the Microsoft-internal teams MORSE, MSTIC and GHOST – an unusual note hinting at a conflict between the researcher and the vendor. This characterisation reflects solely the researcher's perspective; there is currently no credible evidence of an intentional backdoor.

The Attack Chain in Detail

The reproduction documented in the repository is surprisingly minimal. The attacker does not need exploit code in the classical sense, but merely a prepared directory structure and physical access. The decisive trick: the WinRE component apparently loads content from a path that would not be writable under normal Windows operation – but is perfectly writable on an external storage medium or the EFI partition.

A second variant requires no external media at all: if the target system's hard disk is removed, the attacker can copy the FsTx structure directly onto the EFI System Partition (ESP). The ESP is not encrypted by BitLocker by default – it contains the bootloader and is accessible with write permissions to any live system. Once the disk is reinstalled, the vulnerability can be exploited without any additional hardware.

USB stick (NTFS)
└── System Volume Information\
    └── FsTx\
        └── 95F62703B343F111A92A005056975458\
            └── [exploit-specific files]

EFI Partition (alternative)
└── \EFI\Microsoft\Boot\...
    └── analogous placement of the FsTx structure

Affected Systems and Prerequisites

The vulnerability is described as affecting only newer Windows versions. Based on current knowledge, Windows 10 does not appear to be affected, as the relevant WinRE component is shipped in a variant without the described functionality. The researcher interprets this distinction as an indication of deliberate introduction; independent verification has not been published.

Why This Finding Matters

BitLocker is widely treated, across many compliance frameworks, as a technically sufficient measure to protect data in the event of device loss (“data at rest”). A working bypass method undermines that assumption – with far-reaching consequences for how incidents such as the loss of a company laptop or a stolen field tablet are assessed.

Mitigations and Hardening

As long as no official patch is available from Microsoft, organisations should evaluate configuration and organisational measures. A key approach is hardening pre-boot authentication – this moves the attack point ahead of the recovery environment and significantly reduces the attack surface.

# List current protectors
Get-BitLockerVolume | Select-Object MountPoint, ProtectionStatus, KeyProtector

# Check whether TPM-only or TPM+PIN is active
manage-bde -protectors -get C:

# Check WinRE status
reagentc /info

# Temporarily disable WinRE (caution: impacts updates)
reagentc /disable

# PowerShell: scan all volumes for suspicious FsTx paths
Get-PSDrive -PSProvider FileSystem | ForEach-Object {
  $path = Join-Path $_.Root 'System Volume Information\FsTx'
  if (Test-Path $path) {
    Write-Warning "Suspicious structure found: $path"
    Get-ChildItem -Force $path | Format-List FullName, Length, CreationTime
  }
}

Context and Outlook

YellowKey is part of a dual disclosure – in the same timeframe, the same source published a local privilege escalation named GreenPlasma. Secondary sources report that the researcher previously disclosed exploits under the names BlueHammer and RedSun. The background appears to be a conflict with Microsoft over the handling of vulnerability reports – the disclosures therefore carry the character of a public escalation.

Two considerations emerge for those responsible in IT and security organisations: First, the threat model “an encrypted laptop is safe” should be re-examined in the light of this research. Second, pre-boot authentication and defense in depth remain important protection layers, even in a world with hardware-backed encryption. Organisations implementing NIS2 requirements may wish to explicitly evaluate BitLocker configurations against physical attack scenarios.