On May 12, 2026, a researcher operating under the handles Chaotic Eclipse and Nightmare-Eclipse dropped a working proof-of-concept on GitHub for a Windows zero-day called YellowKey. In short, it lets anyone with brief physical access to a BitLocker-protected Windows 11, Windows Server 2022, or Windows Server 2025 machine pop a command prompt with full read access to the encrypted volume. No password. No recovery key. No TPM sniffing rig. A USB stick and a key combination during reboot.

The security press picked it up immediately. The hacking community ran with it. The forensic community, oddly, has barely shrugged. That is a mistake. If you have a seized BitLocker-protected laptop sitting in the evidence room that has so far been written off as cold evidence, this disclosure should be on your desk this week, not next quarter. As of writing, Microsoft has not shipped a patch, and the researcher is openly promising more disclosures around the next Patch Tuesday. The window of opportunity is wide open right now.

This article walks through what BitLocker actually protects, how YellowKey breaks that model, how forensic examiners can take advantage of the bug, and what the researcher’s additional claim about TPM+PIN configurations might really mean.

A Quick Refresher: BitLocker and Device Encryption

BitLocker is Microsoft’s full-volume encryption feature. It uses AES (XTS by default on modern installs) to encrypt the contents of the drive with a Full Volume Encryption Key, which is itself wrapped by a Volume Master Key (VMK). The VMK is what every protector ultimately unlocks: a password, a recovery key, a smart card, a USB key file, or the TPM (alone, or combined with a PIN, a startup key, or both).

What changes the forensic calculus on modern Windows is not the classic, manually configured BitLocker that admins enable on enterprise laptops. It is Device Encryption, the silent, automatic variant Microsoft enables on any reasonably modern hardware that meets the requirements, on any Windows edition including Home. The user does not have to ask for it. They do not have to know it exists. If the device shipped with Windows 11 and the user signed in with a Microsoft Account, the system drive is almost certainly encrypted.

The recovery key, in that scenario, is uploaded to the first admin-level Microsoft Account that signs in on that device. If the user knows nothing about encryption, they certainly know nothing about the recovery key. If they later switch to a local account, change their Microsoft Account, or simply have no idea which Outlook/Hotmail address was used during setup, the key is for practical purposes gone, from their perspective.

This silent rollout has been a long-standing thorn in the side of the data recovery community. Customers walk in with a laptop with a dead motherboard, no idea their drive was encrypted, and no recovery key. Recovery is impossible. YellowKey does not solve every variant of that problem, but for any case where the original encrypted drive can be returned to working hardware running an affected Windows version, the equation has fundamentally shifted.

How TPM Protection Was Supposed to Work

To appreciate what YellowKey actually breaks, it is worth recapping the trust model. For a deeper insight, our 2021 article Understanding BitLocker TPM Protection remains accurate on the fundamentals. The short version follows.

In the default TPM-only configuration (which is what Device Encryption uses out of the box), the Volume Master Key (VMK) is sealed inside the TPM against a set of Platform Configuration Registers (PCRs). During boot, each stage measures the next and extends those PCRs: firmware measures the bootloader, the bootloader measures the OS loader, and so on, building a chain of trust. If the chain matches the values present when BitLocker was provisioned, the TPM releases the VMK to the boot manager. If anything in the chain has been tampered with, the TPM refuses, and the user gets a Recovery Key prompt.

This is the part that matters for YellowKey: when the chain of trust passes, the VMK is released automatically, with no user interaction. The whole point of Device Encryption is that the legitimate owner never sees a prompt. The TPM hands over the key, Windows mounts the encrypted volume, and life goes on. The implicit assumption is that nothing inside the trusted boot chain itself can be subverted to expose the volume to an unauthorized party.

TPM+PIN, which we will come back to later, changes one thing: the TPM additionally requires a correct PIN to be entered before it will release the VMK. The chain of trust still matters, but the user must also authenticate. It is the standard recommendation for any device that handles sensitive data, and it is what most threat models assume defenders to be using when they take BitLocker seriously.

The YellowKey Exploit

What It Is

YellowKey is a bug in the Windows Recovery Environment (WinRE) that allows an attacker to drop into an unrestricted command prompt with the BitLocker-protected system volume already unlocked and accessible. The flaw lives in a component present only inside the WinRE image; the researcher notes that the same component, by name, also exists in a normal Windows installation, but without the specific functionality that triggers the bypass. That asymmetry is what makes the discovery feel less like an accident and more like something that was put there on purpose. Whether that framing is correct is something we will speculate on at the end.

The affected platforms are Windows 11 and Windows Server 2022/2025. Windows 10 is currently unaffected. Multiple independent researchers, including Will Dormann (Tharros Labs) and Kevin Beaumont, have publicly confirmed that the published PoC works as advertised against the default TPM-only configuration.

How It Works, Without the Gory Bits

The exploit abuses a code path inside WinRE that scans attached storage for NTFS transaction log data under a specific folder, System Volume Information\FsTx, and replays whatever it finds. The interesting part, flagged by Will Dormann, is that the replay can modify content on a different volume than the one the logs came from. By preparing the right log content, an attacker can use a USB stick (or, alternatively, files written directly to the device’s EFI System Partition) to make WinRE rewrite parts of its own recovery image during early boot.

The net effect of the documented PoC is that winpeshl.ini inside the WinRE image is removed. winpeshl.ini is what normally tells WinRE to launch the recovery UI; without it, WinRE falls back to spawning cmd.exe directly. A specific key sequence held during boot triggers the path. The shell that lands on screen has access to the BitLocker-protected system volume because, by the time WinRE is entered through the legitimate recovery path, the TPM has already released the VMK to the boot chain in the normal way. Nothing about the chain of trust has been violated from the TPM’s point of view. The recovery environment is supposed to have legitimate access to the volume for repair tasks. The bug is in how trivially that access can be redirected into a free-for-all shell.

We have intentionally kept it conceptual. The published repository contains everything needed to weaponize the bug, and several independent confirmations exist. We are not going to recap the byte-level details here; this is a forensics blog, not a tutorial for the other side.

Using YellowKey in a Forensic Workflow

Translated for an examiner with a seized device on the bench, the procedure breaks into three phases: rebooting into the Windows Recovery Environment, dropping into an unrestricted shell, and extracting the BitLocker recovery key. A few pre-flight notes first.

First, the procedure modifies the device. The FsTx replay changes content inside the WinRE image, and once winpeshl.ini has been deleted on the recovery partition, the device is no longer in its original state. Image the drive first with a hardware write blocker or with a tool such as Elcomsoft System Recovery, and document hash values before and after. The exploit operates on the running hardware, but having a clean forensic image in hand means any later challenge to the chain of custody can be answered with the pre-exploit image as a reference.

Second, confirm the target is in scope. Windows 10 is currently not affected. Verify the operating system version on the seized device before planning around YellowKey. Server 2022 and Server 2025 are in scope alongside Windows 11.

Third, the procedure is finicky. The key-press timing in particular is unforgiving, and independent testers have noted that it often takes several attempts to land cleanly. Beyond timing, the exploit also does not work on every in-scope device – see the caveat at the end of this section about Trusted WIM Boot. Plan for retries and for a non-trivial false-negative rate.

Phase 1: Rebooting into the Windows Recovery Environment

Prepare a USB stick with the published FsTx folder placed at the correct path inside System Volume Information, and connect it to the seized machine before initiating reboot. How you get to WinRE then depends on the state of the device.

If the device is locked but already authenticated – for example, it was seized while powered on, asleep, or hibernated, and the lock screen is displayed – the fastest path is the Shift-plus-Restart trick. From the lock screen, click the power button in the bottom-right corner, hold Shift, and click Restart. The device reboots directly into WinRE. This is enabled on most consumer Windows installations by default. It can be blocked in enterprise environments where Group Policy hides the power options from the lock screen (most commonly via the “Remove and prevent access to the Shut Down, Restart, Sleep, and Hibernate commands” policy), in Assigned Access or kiosk configurations, on devices managed via Intune or another MDM where the administrator has disabled the on-screen power button, or anywhere a local policy has hidden it manually. If the power button is missing from the lock screen, or if Shift-plus-Restart still goes through a normal reboot rather than into Recovery, fall back to the cold method below.

If the device is fully powered off – the default state for anything that has been sitting in the evidence room for any length of time – force WinRE entry by triggering Windows’s automatic repair flow. Microsoft documents the procedure in its Windows recovery environment article: power the device on, then hold the power button to force a hard shutdown before Windows finishes loading. Do this twice. On the third power-on, Windows recognizes the previous failed boot attempts and brings up the Recovery Environment automatically. This path is reliable but not forensically neutral – the forced shutdowns alter the boot counter in BCD, write unclean-shutdown entries to the event log, and on rare occasions can cause filesystem inconsistencies. Hash before and after and document the procedure exactly as performed.

Phase 2: Getting into the Shell

The moment WinRE entry is triggered by either method, release any other keys and immediately press and hold the Ctrl key. Do not release it. Keep Ctrl held down until a command prompt window appears. If the timing lands correctly, the shell that spawns has direct read access to the BitLocker-protected system volume.

The key-press window is narrow. Multiple testers have reported that landing cleanly takes several attempts, so do not give up after a single failed try. Each retry means going back through Phase 1, which on a cold device involves another sequence of interrupted boots – slow, but the process works.

One important caveat: the exploit does not succeed on every device in the affected version range. Microsoft has had a mechanism called Trusted WIM Boot in place since BitLocker recovery support was added to WinRE. The mechanism stores a hash of the WinRE.wim image inside the BitLocker FVE metadata block, which is itself integrity-protected via AES-CCM, and verifies the hash during recovery boot. When YellowKey’s FsTx replay modifies content within the WinRE image, that hash check is supposed to fail, in which case the OS volume remains locked and the dropped shell has no access to encrypted data. Whether Trusted WIM Boot actually triggers depends on whether the device’s BitLocker metadata contains the expected WIM hash entry in the first place. According to a community researcher’s analysis posted in discussion of the exploit, the metadata on a substantial share of laptops in the wild – roughly half, by their estimate – does not include the WIM hash, meaning YellowKey works against those devices but fails against the rest. That estimate has not been independently validated, but the underlying mechanism is real and documented by Microsoft. Treat this as a hit-rate problem rather than a hard gate: attempt the procedure on every in-scope seized device, but expect that on a meaningful fraction of them the shell will land without access to the encrypted volume, and plan accordingly.

Phase 3: Extracting the Recovery Key with manage-bde

Once the shell is live and the BitLocker volume is accessible, the practical move is not to simply read files off the volume, but to extract material that lets you decrypt the original forensic image offline. Use manage-bde from the cmd prompt to enumerate the protectors on the volume and to read out the recovery information.

Note that in WinRE, drive letters get reassigned because WinRE itself runs on X:. The OS volume is often C: but may land as D: or another letter depending on partition layout. So the sequence is:

manage-bde -status

Review the output and identify which volume shows Protection Status: Protection On and BitLocker Version: 2.0. That is your target drive letter. Then:

manage-bde -protectors -get C:

(substituting whatever letter was identified). Look for the Numerical Password protector in the output. It will appear as a 48-digit key in eight groups of six digits separated by hyphens – that is the BitLocker Recovery Key. Copy it down verbatim; it is usable both as a manual unlock password and as input for Elcomsoft Forensic Disk Decryptor when decrypting the offline image.

One thing to note: the Numerical Password protector is generated and stored when BitLocker is first provisioned, regardless of which primary protector (TPM-only, TPM+PIN, password, etc.) the volume uses. So even on a TPM-only Device Encryption setup where the user never saw a recovery key prompt, the protector is there – it was just silently backed up to their Microsoft Account. Extracting it here gives you a persistent key that survives any subsequent patch or hardware change, which is useful for long-running investigations.

This numeric password is what your workflow downstream actually wants. With that in hand, Elcomsoft Forensic Disk Decryptor can decrypt the original forensic image you captured earlier, or mount it as a virtual drive for live analysis, without ever having to touch the seized hardware again. That is the soundest path: use YellowKey only as the keying primitive, do the actual analysis on the offline image.

The variant that works without any external storage, by writing the same payload to the EFI System Partition on the device’s own drive, is convenient when the device’s USB ports are inconvenient or disabled but generally requires brief removal of the drive, which has its own evidence-handling implications.

Why This Is a Bigger Deal Than the Forensic Community Has Acknowledged

The reason this disclosure deserves more attention than it has been getting is that it dissolves a category of cases that examiners have been writing off for years.

Consider a typical scenario. A laptop is seized as evidence in an investigation. It runs Windows 11. The user account was local, or the Microsoft Account credentials are unknown, or the recovery key was never synced. The BitLocker-protected drive is, on paper, unrecoverable without the user’s cooperation. Until now, the realistic options were: try to coerce or negotiate the recovery key out of the user, hope memory forensics on a still-running device yielded the VMK (impossible on a powered-off seizure), or shelve the device. With YellowKey, the same device, in the same powered-off state, can be processed today.

Device Encryption widens the impact dramatically. The number of consumer laptops out there with BitLocker silently enabled, whose owners do not know it is enabled and whose recovery keys are tied to forgotten Microsoft Accounts, is enormous. Cases involving such devices were a recurring pain point. They are not, for the duration of this vulnerability’s life, anymore.

One more dimension worth flagging: the affected versions. Windows 10 stays untouched, at least for now. Anything Windows 11 or Server 2022/2025 is in play. A quick inventory pass through your evidence room, sorted by OS, is probably a worthwhile afternoon. Seized devices are, by definition, cold – they will not receive any patches while they sit in storage, so an affected device in evidence today will still be affected next year, regardless of what Microsoft ships in the meantime. The window of opportunity applies to future seizures: once a patched build is in widespread deployment, devices acquired from that point onward may no longer be exploitable. For everything already on the shelves, this is not a race against the clock so much as a backlog that has quietly become workable.

A Note on the TPM+PIN Claim

The researcher has stated, in their follow-up blog post, that the bug is also exploitable on devices configured with TPM+PIN, and that they have a working PoC but are withholding it. Their words: “Second thing is, No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I’m just not publishing the PoC, I think what’s out there is already bad enough.”

This claim deserves caution. By design, TPM+PIN requires the user PIN to be entered before the TPM releases the VMK. A stolen laptop, powered off and then booted, should not have the encrypted volume mounted by the time WinRE is reached, because the TPM has nothing to release. The mechanism that makes YellowKey work in the TPM-only case – the volume already being unlocked when WinRE inherits the system – does not obviously apply.

That said, it is worth taking the claim seriously rather than waving it away. The published TPM-only bypass already implies a code path inside WinRE that does not behave the way the public documentation would suggest. If, as the researcher believes, this is a deliberately introduced channel rather than an accidental flaw, there is nothing to stop that channel from including its own access path to the encrypted volume, independent of the user PIN. WinRE legitimately needs to be able to talk to the protected volume for some repair operations, and the exact mechanism by which it does so is not well documented publicly. JaGoTu, who tested the published PoC, noted that TPM+PIN behaviour appeared to depend on the specific WinRE implementation, suggesting that something more is going on than a simple “PIN gates everything.” Until Microsoft reverses the component and explains it, or the researcher releases the second PoC, the honest position is: it is plausible, it is not independently confirmed, and on a TPM+PIN-protected target there is no harm in attempting the standard YellowKey procedure as part of your toolkit. If it works, you have your shell. If it does not, you have lost an hour.

So What the Hell Was That, Microsoft?

Stepping back from the procedural stuff, this whole thing deserves a moment of genuine bewilderment.

The researcher’s framing is that YellowKey looks like a backdoor. Not in the conspiratorial sense, necessarily, but in the structural one: the vulnerable component lives only inside the WinRE image. The same component, with the same name, exists inside a normal Windows install, but without the specific functionality that produces the bypass. That is not the shape of a normal bug. Normal bugs are uniform; they exist in code that ships everywhere the code is needed. Functionality that exists in one image and not another, where the difference is precisely the part that produces unauthorized access to encrypted data, is the kind of asymmetry that gets people asking questions.

There are basically two ways to read it. The charitable reading is that this is a legacy maintenance or debug pathway that someone inside Microsoft built years ago for some legitimate repair scenario, never properly gated, and forgot about. The recovery environment is a strange corner of Windows, full of historical accretion, and “we needed to be able to fix things in the field” is a real engineering pressure. That reading lands you at gross negligence: a feature that effectively defeats the entire promise of BitLocker on a default install, sitting in production code for years, undocumented, undetected by internal review.

The less charitable reading is that someone meant it to be there. Whether for internal Microsoft tooling, for cooperation with specific partners, or for reasons that nobody outside the room ever needs to know, an access path was built and quietly kept. Nothing in the public evidence forces this reading over the negligence one, and accusations of intentional backdoors should not be made lightly. But the structural oddity is real, the researcher is not the only one who has noticed it, and Microsoft so far has not offered an explanation.

Either reading is bad news for the BitLocker brand. The whole pitch of TPM-bound encryption is that the user can stop worrying. Drive gets stolen, drive stays scrambled, full stop. That promise underpins a lot of policy: governments standardising on BitLocker for sensitive endpoints, enterprises ticking the compliance box, consumers assuming that the laptop they lost in a taxi will not become a data breach. YellowKey punches a clean hole through that. Not a “with enough specialised equipment and a soldering iron” hole, which sophisticated readers always knew existed for TPM-only setups. A USB-stick-and-a-keyboard-shortcut hole, accessible to anyone who can read a README.

None of this should have happened. A vulnerability of this severity, sitting inside a component whose entire job is to be invoked by an untrusted user during an unauthenticated state, should have been caught by internal review long before it shipped. The fact that it was not – and the further fact that Microsoft’s response to this researcher’s previous disclosures has, by their own account, included silent patches without advisories – is going to do real damage to the assumption that “encrypted by Microsoft” means “safely encrypted.”

For the forensic community, this is a gift, and a temporary one. For Microsoft customers, it is a wake-up call to think harder about whether TPM-only Device Encryption is actually enough for the threat model. For the rest of us, it is yet another reminder that the most consequential vulnerabilities are not usually the clever ones. They are the ones nobody noticed because nobody thought to look.