If the past two weeks on the Linux side felt like a lot to manage, the Windows world has its own situation developing. A working proof-of-concept exploit for a BitLocker bypass was published publicly on May 12, 2026, with no patch available and no CVE assigned at time of writing. It's called YellowKey; it bypasses BitLocker encryption with physical access and a USB stick and has already been independently verified by external researchers.
This article is meant to help non-technical stakeholders understand what YellowKey is, why it matters even for organizations that consider physical security a solved problem, and what your team should be doing right now.
A quick note on how this one became public
YellowKey did not go through any coordinated disclosure process. There was no private notification to Microsoft, no embargo, and no patch waiting in the wings.
The vulnerability was discovered and published directly to GitHub by a researcher operating under the aliases Nightmare-Eclipse and Chaotic Eclipse. By their own account, the decision to go public was retaliatory: they allege that Microsoft violated a prior agreement and left them in a difficult personal situation. "I never wanted to reopen a blog and a new GitHub account to drop code," they wrote in their initial post. "But someone violated our agreement and left me homeless with nothing. They knew this will happen and they still stabbed me in the back anyways."
YellowKey is the fourth and fifth in a series of Microsoft zero-days this researcher has released in 2026. Earlier releases, BlueHammer (CVE-2026-33825) and RedSun, both saw real-world exploitation within days of publication. BlueHammer was patched by Microsoft in April; RedSun reportedly received a silent fix with no public advisory. The researcher has explicitly promised more disclosures tied to future Patch Tuesdays, and has described holding additional material as a "dead man's switch."
Microsoft has not, as of publishing of this post, issued a public acknowledgment of YellowKey or assigned a CVE. When contacted by press, the company provided a standard response indicating they are investigating.
This context matters for your planning: the window between "exploit available" and "patch available" is undefined, and based on prior behavior from this researcher, more disclosures are likely.
What is YellowKey?
YellowKey is a BitLocker bypass vulnerability. BitLocker is Microsoft's built-in full-disk encryption feature, designed to protect the contents of a Windows device if it is lost or stolen. YellowKey defeats that protection, giving an attacker with brief physical access to a device unrestricted access to the files on its encrypted drive - without the recovery key, without the password, and without dismantling the encryption itself.
The exploit was published on May 12, 2026 with a working proof-of-concept and has been independently verified by at least two external security researchers. Will Dormann, a well-known vulnerability researcher, confirmed reproduction with a USB drive, noting that Transactional NTFS data on the USB is able to delete a key configuration file on the WinRE recovery partition of the target machine. Kevin Beaumont, an independent security researcher, also confirmed the exploit is valid.
Affected systems: Windows 11, Windows Server 2022, and Windows Server 2025. Windows 10 is not affected.
The technical mechanism runs through the Windows Recovery Environment (WinRE), the built-in repair and troubleshooting environment that loads when Windows fails to start normally. The exploit works by placing specially crafted files (provided in the GitHub repository) onto a USB stick or the EFI partition of the target device, then triggering a specific key sequence during a WinRE boot. When executed correctly, a shell spawns with full, unrestricted access to the BitLocker-protected volume.
The researcher describes the underlying component responsible as unusual: the same component exists in a standard Windows installation under the same name, but without the functionality that enables the bypass. It exists in full only inside the WinRE image. The researcher has characterized this as potentially intentional, a backdoor, though this characterization cannot be independently verified from the information currently available.
What about TPM+PIN?
This is the question most security teams are currently asking, and the answer seems to be: it is uncertain, and the uncertainty itself is the problem.
The publicly released proof-of-concept bypasses TPM-only BitLocker configurations, which is the default for most enterprise deployments. The researcher has stated publicly that the vulnerability is also exploitable against TPM+PIN configurations, which would represent a much more serious finding, but has not released proof-of-concept code for that variant. No independent researcher has verified or refuted that claim, either.
The researcher's stated reason for not publishing the TPM+PIN exploit is that "what's out there is already bad enough."
Until Microsoft confirms or denies the full scope of the underlying defect, the responsible posture is to treat this as an unverified but credible claim from the person who found the vulnerability in the first place. Organizations running TPM-only BitLocker by policy should treat this with the same urgency as any unencrypted drive situation until a patch is available.
Why does this matter if physical access is required?
It is tempting to mentally file a physical-access requirement under "not our threat model." That would be a mistake for most organizations and here's why.
BitLocker's entire purpose is to be the last line of defense when physical security fails. If an attacker needs to bypass BitLocker, it is because they already have the device. Laptop theft, device seizure, loss during travel, a device left unattended at a conference, equipment recovered from e-waste...all of these scenarios are exactly what BitLocker is supposed to protect against. As Rik Ferguson, VP of Security Intelligence at Forescout, put it when speaking to The Register, "If this holds up, a stolen laptop stops being a hardware problem and becomes a breach notification."
Gavin Knapp, Cyber Threat Intelligence Principal Lead at Bridewell, reinforced this directly, stating that despite the physical access requirement, YellowKey represents "a huge security problem for organizations using BitLocker."
For organizations subject to breach notification requirements, this distinction is significant. A stolen device encrypted with BitLocker has historically been a defensible position; since the data is protected, no notification is required. YellowKey changes that calculus as long as it remains unpatched.
Who is affected?
As mentioned earlier in this article, this vulnerability affects any Windows 11, Windows Server 2022, or Windows Server 2025 device running BitLocker in its default TPM-only configuration. That is a very large number of devices across most organizations.
Specific risk areas to consider:
Endpoints and laptops. Any device that leaves your offices - such as executive laptops, field devices, employee personal computers with corporate data - carries this risk. A few minutes of physical access is all the exploit requires.
Devices in shared or semi-public spaces. Devices used at conferences, in coworking environments, in open offices, or in client sites represent elevated risk. The attack does not require the device to be powered on at the time; an attacker can pull the disk, copy the exploit files to the EFI partition, and return the device without the owner noticing.
Decommissioned and returned equipment. Devices awaiting redeployment, in IT storage, being returned by departing employees, or in the e-waste stream may still contain sensitive data that YellowKey could expose.
High-value targets. Executives, finance teams, HR, legal, and anyone whose devices hold particularly sensitive or regulated data represent a higher-priority concern. Targeted physical access attacks are rare but not unheard of, particularly for well-resourced adversaries.
What should you do?
1. Understand your current BitLocker configuration
Before taking any other action, determine how BitLocker is configured across your organization. There are two relevant configurations:
TPM-only is the most common enterprise default. The device decrypts automatically at boot with no user interaction. This configuration is confirmed vulnerable to the publicly available YellowKey exploit.
TPM+PIN requires the user to enter a PIN at each boot before the device will decrypt. Whether this configuration is also vulnerable to YellowKey's underlying root cause is unconfirmed; the researcher claims it is, but the proof-of-concept for that variant has not been released.
You can check the current BitLocker protection mode from an elevated command prompt:
manage-bde -status C:
Look for the "Key Protectors" field. A TPM-only system will show "TPM" as the sole protector. A TPM+PIN system will show "TPM And PIN."
2. Enable BitLocker PIN where possible
The current recommended mitigation, as cited by multiple independent researchers and by cyber threat intelligence sources, is enabling a BitLocker PIN in addition to TPM. This requires user action at every boot but closes the publicly verified attack path.
On Windows 11 Pro and Enterprise, this can be configured via Group Policy at:
Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives
Enable "Require additional authentication at startup" and set "Configure TPM startup PIN" to "Require startup PIN with TPM."
Important caveat for Windows 11 Home: Home edition does not expose Group Policy management of BitLocker PIN. Users on Home edition cannot apply this mitigation through standard tools.
Important note: If the researcher's unverified claim about TPM+PIN is accurate, this mitigation may not be fully sufficient. It closes the known public exploit path, but the underlying root cause may not be fully understood yet. Treat PIN enablement as a risk reduction measure, not a complete fix.
3. Enable a BIOS/UEFI firmware password
Independent researchers additionally recommend locking the BIOS or UEFI firmware with a password to prevent unauthorized boot device selection. This adds a layer of friction that prevents an attacker from easily booting into WinRE from an external device without the firmware password.
This is particularly important for high-value or high-mobility devices.
4. Tighten physical security controls
While you wait for a patch, physical access prevention is the most reliable mitigation. Review:
- Device tracking and check-out procedures for portable equipment
- Policies around unattended devices in public or semi-public spaces
- Storage security for decommissioned equipment
- Controls for returned devices from departing employees
5. Reassess your breach notification posture for lost or stolen devices
Until a patch is available, any lost or stolen Windows 11 or Server 2022/2025 device with TPM-only BitLocker should be treated as a potential data exposure for breach notification and incident response purposes. Work with your legal and compliance teams to understand what this means for your specific obligations.
6. Apply the patch when it arrives
Microsoft has not yet issued a patch or assigned a CVE. Watch for updates through Microsoft's Security Response Center and apply the patch promptly when it becomes available. Given the public availability of a working exploit, this vulnerability is likely to be treated as a high-priority fix.
A note on the disclosure circumstances
YellowKey sits in an unusual category: a vulnerability with a working public exploit, independently verified by third-party researchers, with no patch and no coordinated disclosure. The researcher has been explicit about their intent to continue releasing vulnerabilities against Microsoft, and has a demonstrated track record of following through.
We want to be clear about what this means practically: there is no timeline for a patch, and the organization responsible for delivering one is also the one being targeted by the researcher's campaign. Organizations cannot plan around an expected remediation date in the way they might for a standard Patch Tuesday vulnerability.
The right response is the same regardless: apply the available mitigations, assess your exposure, and watch closely for a patch.
The original GitHub repository from Nightmare-Eclipse is available at github.com/Nightmare-Eclipse/YellowKey. Microsoft's Security Response Center can be monitored at msrc.microsoft.com for any advisory when it is issued.
Summary
| CVE | Not yet assigned |
| Nickname | YellowKey |
| Type | BitLocker Security Feature Bypass |
| Affected | Windows 11, Windows Server 2022, Windows Server 2025 (TPM-only BitLocker confirmed; TPM+PIN unconfirmed but claimed by researcher) |
| Windows 10 affected? | No |
| Exploit complexity | Low — requires brief physical access, USB drive, and a key sequence in WinRE |
| Patch available? | No — no CVE assigned, no Microsoft advisory at time of writing |
| Immediate mitigation | Enable BitLocker TPM+PIN; add BIOS/UEFI firmware password |
| Breach notification impact? | Yes — lost or stolen TPM-only devices should be assessed for notification obligations |
If you need help assessing your BitLocker configuration across your fleet, applying PIN policies through Group Policy, or determining your breach notification exposure for devices lost or stolen prior to a patch being issued, get in touch. YellowKey is a good opportunity to take a broader look at your endpoint encryption posture — and that's exactly the kind of assessment CrowdSOC can help with.