YellowKey and the BitLocker Zero-Days: What Just Got Disclosed

A cluster of Windows BitLocker bypass vulnerabilities just surfaced, headlined by YellowKey — a zero-day that turns USB sticks into master keys for BitLocker-protected systems. But this isn't a single-bug story. It's a coordinated disclosure of four separate attack primitives from researcher "Nightmare-Eclipse," plus related work that paints a troubling picture of Windows' pre-boot security model.

What just dropped

On May 16, 2026, details emerged about a cluster of Windows security vulnerabilities that collectively undermine BitLocker disk encryption. The disclosure centers on YellowKey, an unpatched BitLocker bypass that works by exploiting Windows Recovery Environment (WinRE) initialization through crafted Transactional NTFS (TxF) transaction logs.

Unlike traditional BitLocker attacks that target TPM or pre-boot authentication, YellowKey operates during WinRE startup — after BitLocker's initial protection but before the operating system has fully initialized its security boundaries. The attack requires physical access; once executed, it provides unrestricted access to BitLocker-protected volumes regardless of TPM+PIN configuration.

The researcher, known as "Nightmare-Eclipse," published proof-of-concept code on GitHub alongside claims that the vulnerability might be intentional — a "backdoor" built into Windows itself. This allegation stems from the observation that the vulnerable component exists in both normal Windows installations and WinRE images, but only the WinRE version exhibits the exploitable behavior.

The cluster: Four vulnerabilities, two patches

The YellowKey disclosure is part of a broader campaign that revealed four distinct vulnerabilities affecting Windows security infrastructure:

YellowKey targets BitLocker protection via Windows Recovery Environment manipulation. The attack vectors through specially crafted FsTx transaction logs placed on USB drives or EFI system partitions. When WinRE initializes, these transaction logs trigger modifications to winpeshl.ini, the configuration file that controls which programs run during recovery environment startup. This manipulation can spawn an unrestricted command shell, bypassing BitLocker protection entirely.

The attack surface is specifically Transactional NTFS (TxF) during WinRE initialization — not the BitLocker pre-boot environment itself. This is a critical distinction: YellowKey doesn't crack encryption or subvert the TPM. Instead, it leverages a window during recovery environment boot where transaction logs can influence system initialization before security policies are fully enforced.

GreenPlasma represents a different attack class entirely: Windows CTFMON arbitrary section creation leading to privilege escalation. This vulnerability allows unprivileged users to create arbitrary memory section objects in SYSTEM-writable directories, potentially enabling manipulation of privileged services or drivers. The researcher published an incomplete proof-of-concept, suggesting the full exploit remains under development.

BlueHammer is the sole vulnerability in this cluster that received official recognition and patching. Assigned CVE-2026-33825, it was patched by Microsoft in April 2026. The vulnerability affects Microsoft Defender Antimalware Platform versions before 4.18.26030.3011 and involves "insufficient granularity of access control" that allows authorized attackers to elevate privileges locally. CISA added BlueHammer to the Known Exploited Vulnerabilities catalog on April 22, 2026, indicating active exploitation in the wild.

RedSun allegedly targets Microsoft Defender through a different vector than BlueHammer. The researcher claims this vulnerability was "silently" patched without public advisory, though verification of this claim requires access to non-public Defender platform updates.

How YellowKey works: Transaction logs as attack vectors

YellowKey's attack mechanism centers on Windows' Transactional NTFS (TxF) subsystem, which provides atomic file operations through transaction logs. During WinRE initialization, the system processes any FsTx transaction logs present on accessible volumes — including USB drives formatted with Windows-compatible filesystems.

The attack payload consists of crafted transaction log files placed in the specific directory structure \System Volume Information\FsTx\<GUID>\. The transaction logs reference two critical files:

• \??\C:\Windows\win.ini on the main Windows installation
• \??\X:\Windows\System32\winpeshl.ini in the WinRE environment

The winpeshl.ini file is particularly significant because it controls which programs execute when the Windows PE (Preinstallation Environment) boots. By manipulating this file through transaction log replay during WinRE initialization, an attacker can inject arbitrary commands into the recovery environment's startup sequence.

The attack runs by booting the target into Windows Recovery Environment with the crafted USB inserted; WinRE's initialization picks up the transaction logs, replays them, and the modified winpeshl.ini is invoked as part of the standard recovery startup sequence — yielding a privileged shell with the BitLocker-protected volume already mounted. The full keystroke / boot-menu recipe is in the YellowKey repository for researchers who want to reproduce it on test hardware; we're not paraphrasing it here.

Critically, this attack works regardless of BitLocker configuration. TPM-only, TPM+PIN, and even TPM+PIN+USB key configurations are all vulnerable because the attack occurs after BitLocker has unlocked the system volume but before Windows has established its full security boundary.

On-disk evidence: Deconstructing the FsTx artifacts

The YellowKey GitHub repository ships with concrete FsTx transaction-log artifacts — actual .blf and container files that the attack replays at WinRE boot. Reading these files isn't just academic: they're the smoking gun for what the exploit actually does.

The directory shape

ls -la repo/FsTx/95F62703B343F111A92A005056975458/FsTxLogs/:

-rw-r--r-- 1 root root    65536  FsTxKtmLog.blf
-rw-r--r-- 1 root root   524288  FsTxKtmLogContainer00000000000000000001
-rw-r--r-- 1 root root   524288  FsTxKtmLogContainer00000000000000000002
-rw-r--r-- 1 root root    65536  FsTxLog.blf
-rw-r--r-- 1 root root 10485760  FsTxLogContainer00000000000000000001
-rw-r--r-- 1 root root 10485760  FsTxLogContainer00000000000000000002

Six files: two 64-KB Base Log Files (.blf) — the standard Microsoft Common Log File System (CLFS) header format — and four containers that hold the actual transaction records. KTM stands for Kernel Transaction Manager, the kernel-mode component that processes these logs. A sibling FsTxTemp/ directory holds a single 0-byte file named 98F62703B343F111A92A005056975458 — note the GUID differs from the parent by one byte (95 → 98). That single byte isn't accidental; it's how the BLF subsystem distinguishes a live transaction directory from its scratch space.

The BLF header

hexdump -C on FsTxKtmLog.blf, first 64 bytes:

00000000: 1500 0100 0200 0200 0000 0000 4b82 4cc6  ............K.L.
00000010: 0100 0000 0000 0000 0000 0000 ffff ffff  ................
00000020: 0000 0000 ffff ffff 7000 0000 0000 0000  ........p.......
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................

That signature 15 00 01 00 02 00 02 00 ... 4b 82 4c c6 is the standard CLFS BLF magic header — Windows' Common Log File System uses this format for any persistent transaction log, including the BitLocker volume-state metadata, the NTFS USN journal, and pretty much every system-level rollback log. Same format here, attacker-crafted contents.

Embedded paths — strings -el on the containers

\??\C:\Windows\win.ini
\??\X:\Windows\System32\winpeshl.ini

That's the entire payload. Two Unicode-encoded paths, embedded in FsTxLogContainer00000000000000000001. The \??\ prefix is the NT object manager's namespace — kernel code reads paths in this form. C: is the main Windows install; X: is the WinPE ramdisk that WinRE mounts. The transaction is a cross-volume operation: replay a file change that affects both drives atomically.

The BLF headers themselves contain self-referential paths so the CLFS runtime knows where to find its own containers:

\??\C:\System Volume Information\FsTx\95F62703B343F111A92A005056975458\FsTxLogs\FsTxKtmLog.blf
%BLF%\FsTxKtmLogContainer00000000000000000001
%BLF%\FsTxKtmLogContainer00000000000000000002

%BLF% is a relative-path token CLFS expands at runtime. The literal C:\System Volume Information\FsTx\<GUID>\ path is the canonical location Windows scans for active transactions during boot — including WinRE boot. Drop these files in that location on a USB, boot the target machine into WinRE, and the kernel will replay your transaction.

What this evidence rules out

What we can say from looking at the bytes:

• No executable payload. Strings analysis turns up zero shellcode, zero embedded PE binaries. The attack is pure data manipulation, not code injection.
• No exploitation of a memory bug. No suspicious lengths, no overflow primitives, no ROP gadgetry. The CLFS parser isn't being tricked; it's doing exactly what it's designed to do.
• The attack target is a config file, not the kernel. The transaction modifies winpeshl.ini, which controls which program runs as WinRE's shell. Replace the launched program with cmd.exe and you get an unrestricted shell with the BitLocker volume already mounted.

That last point is the elegant part — and the reason this is "intentional backdoor"-shaped. The vulnerability isn't a crash, it's a permission. WinRE allows cross-volume transactional file replay during initialization, which is by design. The attacker just exploits that permission to change a config file at exactly the moment Windows is about to consult it.

Related prior art: CVE-2025-48804

Pulling the NVD record for CVE-2025-48804 — a July-2025 BitLocker Boot Manager downgrade vulnerability — turned up wording worth quoting: "Acceptance of extraneous untrusted data with trusted data in Windows BitLocker allows an unauthorized attacker to bypass a security feature with a physical attack." CVSS 6.8, attack vector PHYSICAL, CWE-349 (Acceptance of Extraneous Untrusted Data With Trusted Data). Affected Windows from 10240 (Windows 10 1507) all the way through current Server builds.

The shared family between CVE-2025-48804 and YellowKey is: Microsoft's BitLocker code has multiple places where data structures cross a trust boundary at boot time without being fully revalidated. CVE-2025-48804 fixed one such surface in the Boot Manager; YellowKey shows the same bug-class is alive and well in the WinRE TxF pathway.

Inside the patch: Where binary diffing hits the index gap

Analyzing patched vulnerabilities typically involves comparing pre- and post-patch binaries to understand exactly what changed. For BlueHammer (CVE-2026-33825), this analysis should focus on Microsoft Defender Antimalware Platform binaries, which were updated to version 4.18.26030.3011 in April 2026.

Winbindex — m417z's queryable index of Microsoft binaries — actually does track MsMpEng.exe. Pulling its JSON for the file lists 94 indexed versions. So far so good.

The catch: every 2026-dated KB in that index points at the same August-2025 binary.

$ winbindex MsMpEng.exe --build 11-24H2
  11-24H2  KB5074109   v4.18.25080.5   released=2026-01-13
  11-24H2  KB5077744   v4.18.25080.5   released=2026-01-17
  11-24H2  KB5078127   v4.18.25080.5   released=2026-01-24
  11-24H2  KB5074105   v4.18.25080.5   released=2026-01-29
  ...

Same hash, different KBs. The latest distinct binary in the index is v4.18.25080.5, signed 2025-08-23. There is no April-2026 entry. There is no v4.18.26030.xxxx entry.

That's not because winbindex is missing data — it's because Microsoft Defender's platform binaries don't ship through Windows Update. Definition / signature updates do, and those are what those 2026-dated KBs carry. The actual MsMpEng.exe engine binary updates through a separate cloud channel — "Microsoft Defender Antimalware Platform Update," delivered out-of-band via the Defender service itself, with KB numbers that aren't part of the regular Windows Update catalog.

What this means for patch diffing: if a vulnerability is fixed in the Defender platform engine (like BlueHammer's claimed v4.18.26030.3011 fix), there is no public binary index that exposes the pre and post versions. You'd need a Defender install on a representative Windows host, captured at two points in time, and pulled out of C:\ProgramData\Microsoft\Windows Defender\Platform\<version>\ — a different research workflow than the standard MSU-extraction dance.

For an external researcher who only has access to public indices, the BlueHammer patch is functionally opaque. This isn't a flaw in winbindex; it's a structural fact about how Microsoft delivers anti-malware engine updates. Worth knowing before you spend an hour looking for a binary that was never going to be there.

For RedSun, which was allegedly "silently" patched, the situation is even more complex. Silent patches — security fixes deployed without public advisories — are inherently difficult to analyze because there's no official acknowledgment of what was fixed or when. Without specific KB numbers or version information, identifying the relevant binary changes becomes a process of forensic reconstruction rather than straightforward comparison.

This analysis gap represents a broader challenge in contemporary vulnerability research: as software updates become more automated and cloud-distributed, the traditional model of downloading patches and analyzing differences becomes increasingly difficult to execute.

What's still zero-day: The unpatched cluster

While BlueHammer received official patching, two vulnerabilities in the Nightmare-Eclipse disclosure remain unaddressed as of May 2026, with a third (RedSun) sitting in an ambiguous "silently-patched" status that can't be verified from outside Microsoft:

YellowKey represents the most significant ongoing threat. The BitLocker bypass affects Windows 11 and Server 2022/2025 — critically, not Windows 10, which suggests the vulnerable component was introduced in newer Windows versions. The researcher's claim that this might be an intentional "backdoor" stems from architectural differences between Windows installations and WinRE images: the component responsible for the vulnerability exists in both environments but only exhibits exploitable behavior in WinRE.

Microsoft has not issued a CVE assignment for YellowKey, nor has the company provided a timeline for fixes. The researcher expressed dissatisfaction with Microsoft's vulnerability disclosure process, which may have influenced the decision to publish proof-of-concept code publicly.

GreenPlasma remains in an incomplete state, with the researcher publishing only partial proof-of-concept code. The CTFMON (Collaborative Translation Framework Monitor) vulnerability allows creation of arbitrary memory section objects, but the full exploit chain appears undisclosed. This suggests the researcher may be holding back the complete attack while waiting for Microsoft's response.

RedSun sits in the most ambiguous category. The researcher claims the underlying Defender bug was fixed silently — patched without a public advisory, CVE, or KB notation. Verifying this from outside Microsoft is hard: silent fixes by definition don't surface in public binary indices or release notes. The status remains "claimed-patched, externally unverified" until either Microsoft acknowledges it or a researcher binary-diffs a specific Defender platform update and shows what changed.

The combination of public proof-of-concept code for YellowKey and CISA's active-exploitation flagging of BlueHammer creates a concerning threat landscape. Organizations running affected Windows versions face immediate risk from attackers who can combine physical access with the YellowKey bypass technique, while the BlueHammer Defender escalation provides a parallel path to local privilege gain on already-compromised endpoints.

What this tells us about the bug class

The Nightmare-Eclipse disclosure cluster reveals several troubling patterns about Windows security architecture:

Pre-boot security boundaries are increasingly complex. YellowKey demonstrates that the transition from BitLocker protection to full Windows initialization creates exploitable windows. As Microsoft adds more recovery and initialization features to Windows, these transition periods become larger attack surfaces.

Transaction log systems present underexplored attack vectors. Transactional NTFS has been largely deprecated in favor of newer technologies, but it remains functional and processes transaction logs during system initialization. The YellowKey attack suggests that deprecated but still-functional subsystems can harbor significant security vulnerabilities.

Out-of-band updates create analysis gaps. The inability to analyze BlueHammer and RedSun patches highlights how modern update distribution mechanisms can obscure security research. When critical security fixes are distributed through opaque channels, it becomes difficult for defenders to understand threat landscapes and assess their own exposure.

Physical access attacks are evolving beyond traditional boot modification. Rather than modifying boot sectors or exploiting firmware vulnerabilities, YellowKey leverages legitimate Windows subsystems to achieve its goals. This approach may be more difficult to detect and prevent through traditional security measures.

Component reuse between Windows and WinRE creates unexpected attack surfaces. The fact that YellowKey affects WinRE but not normal Windows installations suggests that shared components can behave differently in different environments, creating inconsistent security boundaries.

Who's affected today

The YellowKey BitLocker bypass affects:

• Windows 11 all versions
• Windows Server 2022
• Windows Server 2025
• Notably NOT Windows 10, suggesting the vulnerability was introduced in newer Windows versions

Organizations most at risk include:

• Enterprise environments where BitLocker is deployed for compliance requirements but physical access to devices is possible
• Remote workers using BitLocker-protected laptops that could be stolen or compromised
• Government and defense contractors who rely on BitLocker for sensitive data protection
• Healthcare organizations using BitLocker to comply with HIPAA requirements

The attack requires physical access to the target machine and a USB drive or ability to modify the EFI system partition. However, the attack works regardless of BitLocker configuration — TPM-only, TPM+PIN, and TPM+USB key setups are all vulnerable.

For BlueHammer (CVE-2026-33825), any system running Microsoft Defender Antimalware Platform versions before 4.18.26030.3011 remains vulnerable. CISA's inclusion of this vulnerability in the Known Exploited Vulnerabilities catalog indicates active exploitation, making patching urgent for all affected organizations.

RedSun's "silently-patched" framing means organizations have no clean way to verify their Defender deployments are current with respect to it — the absence of a KB number or version pin makes external assessment effectively impossible. If you trust Microsoft's update cadence, you're probably covered; if you don't, there's no public artifact to audit against.

Mitigation strategies

Until patches are available for YellowKey, organizations should implement defense-in-depth strategies:

Physical security controls become paramount since YellowKey requires physical access. Ensure devices are stored securely when unattended, implement device tracking, and consider additional physical security measures for high-value targets.

Boot security hardening can help limit attack vectors. Disable unnecessary boot devices, enable Secure Boot where possible, and consider implementing additional boot-time authentication mechanisms beyond BitLocker.

Endpoint detection and response (EDR) solutions may detect the unusual process spawning that occurs during YellowKey exploitation, though detection capabilities will vary by vendor and configuration.

Network segmentation can limit the impact of compromised devices. Even if an attacker bypasses BitLocker, network-level controls can prevent lateral movement and data exfiltration.

For BlueHammer, immediate patching is essential. Organizations should prioritize updating Microsoft Defender Antimalware Platform to version 4.18.26030.3011 or later through their standard update mechanisms.

References

• YellowKey GitHub Repository
• The Hacker News: Windows Zero-Days Expose BitLocker
• CVE-2026-33825 — Microsoft Defender Antimalware Platform privilege escalation (BlueHammer)
• CVE-2025-48804 — BitLocker Boot Manager downgrade (prior art, same bug class)
• CISA Known Exploited Vulnerabilities Catalog
• Windows CLFS Base Log File format documentation
• Winbindex — m417z's Microsoft binary index
• Ghidriff — clearbluejar's CLI binary-diff for Ghidra