24 May 2026 Windows Security

YellowKey CVE-2026-45585: The BitLocker Bypass That Turns a Stolen Laptop Into a Data Breach

A researcher calling themselves Nightmare-Eclipse released working exploit code on 13 May 2026 for a zero-day that defeats Windows BitLocker encryption without needing a password, a network connection, or any pre-installed software. All an attacker needs is a USB drive and a few minutes alone with your laptop. Microsoft acknowledged the flaw on 20 May, assigning it CVE-2026-45585 with a CVSS score of 6.8, but no security update exists yet — only a manual mitigation. If your business relies on BitLocker to protect data on company laptops, the risk calculus just changed.

Disclosure: This post contains affiliate links. We only recommend tools we've researched and trust. If you purchase through our links, we may earn a commission at no extra cost to you.

A Disgruntled Researcher and a Public Zero-Day Drop

On 13 May 2026, a security researcher operating under the handle Nightmare-Eclipse — also known as Chaotic Eclipse — published working proof-of-concept exploit code for two previously undisclosed Windows vulnerabilities. The pair, dubbed YellowKey and GreenPlasma, were dropped simultaneously on GitHub with no prior notice to Microsoft and no coordination with any CERT or disclosure programme. The move was deliberate: posts accompanying the release described Microsoft's vulnerability reward programme as "a waste of time" and suggested the company had ignored earlier private reports from the same researcher.

This is not the first time Nightmare-Eclipse has taken this approach. Earlier in 2026, the same researcher published BlueHammer, RedSun, and UnDefend — a cluster of Windows privilege escalation flaws and a denial-of-service bug that Microsoft subsequently patched. The pattern is consistent: private submission, no response within the researcher's self-imposed deadline, then a public drop with a working exploit attached.

Microsoft acknowledged the YellowKey flaw on 20 May 2026, assigning it the identifier CVE-2026-45585 and publishing a CVSS 6.8 score reflecting the physical-access prerequisite. Critically, no security update was released alongside the acknowledgement — only a mitigation guide requiring manual registry edits and a BitLocker configuration change. As of the publication of this article, no patch exists. GreenPlasma, the companion privilege escalation flaw, had received neither a CVE number nor a mitigation from Microsoft.

Multiple major security outlets — including BleepingComputer and SecurityWeek — reported independently on the disclosure. The Hacker News confirmed Microsoft's mitigation publication date as 20 May. The one-week gap between public PoC release and any official Microsoft response is itself significant: it meant that for seven days, any attacker with a USB drive and brief physical access to a Windows 11 device had a working, publicly documented method to read everything on that machine's encrypted drive.

Why BitLocker Bypass Matters for Australian Organisations

BitLocker is the default full-disk encryption tool built into Windows 11 Pro and Enterprise, and it is widely deployed across Australian small and medium businesses, government agencies, and healthcare organisations. Many businesses deploy it specifically because laptops get lost, stolen, or left unattended — the assumption being that even if a device walks out the door, the data on it is unreadable without the encryption key.

YellowKey undermines that assumption entirely. If an attacker gains even brief physical access to a Windows 11 device — a stolen laptop from a bag at a café, a device left in a hotel room, a machine temporarily unattended at a coworking space — they can now read the contents of the encrypted drive using nothing more than a USB drive and publicly available tools. The Vertex Cyber Security firm in Australia noted the implication plainly: "a stolen laptop stops being a hardware problem and becomes a breach notification."

That framing has direct legal consequences in Australia. Under the Notifiable Data Breaches (NDB) scheme administered by the Office of the Australian Information Commissioner (OAIC), organisations covered by the Privacy Act 1988 must notify affected individuals and the OAIC when a data breach is likely to result in serious harm. A stolen laptop containing client records, financial data, or health information that has been encrypted — and which was previously considered adequately protected — may now fall within the notification threshold if the encryption can no longer be considered an effective barrier.

The Australian Signals Directorate's Essential Eight Maturity Model includes "restrict Microsoft Office macros" and "patch applications" as top controls, but it also expects organisations to implement device encryption as a baseline. The implicit assumption underpinning that guidance is that device encryption works as designed. A zero-day that renders that control ineffective without a patch being available is exactly the kind of scenario the Essential Eight is designed to mitigate through defence-in-depth — but only if other controls are also in place.

The CVSS 6.8 score assigned by Microsoft is lower than many organisations' automatic-escalation thresholds, which often trigger on 7.0 or higher. That would be a mistake. Physical access reduces the base score, but the consequence of a successful exploit — complete access to everything on the encrypted drive — is a critical business event regardless of the CVSS arithmetic. Treat this one at the severity of its impact, not its score.

How YellowKey Works — The Technical Detail

Understanding the mechanics of YellowKey matters for Australian IT teams assessing whether their current configuration is at risk and whether the mitigations Microsoft has published actually apply to their environment.

The WinRE Trust Assumption

The attack abuses a behavioural trust assumption in the Windows Recovery Environment (WinRE) — the pre-boot repair and recovery system built into Windows 11 and Windows Server 2025. WinRE is designed to run before the main OS loads, which means it operates in a context where BitLocker has already unlocked the drive volume to allow recovery operations.

The specific mechanism involves a Windows component called autofstx.exe, which is executed via the BootExecute registry value within WinRE. This executable handles cross-volume TxF (Transactional NTFS) transaction replay — a feature that allows file system transactions to be replayed across volumes during recovery. YellowKey exploits this by placing specially crafted FsTx files on a USB drive or the EFI system partition. When the machine reboots into WinRE and autofstx.exe processes these files, it spawns an unrestricted shell with full read-write access to the BitLocker-protected volume.

The exploit requires the attacker to hold down the CTRL key at a specific point during the WinRE boot sequence to trigger the shell. The whole operation — from plugging in the USB drive to having a command prompt with access to the encrypted volume — takes a matter of minutes. No credentials are required. No software needs to be installed on the target machine in advance. Any Windows 11 or Windows Server 2025 device that can be physically rebooted is potentially vulnerable.

GreenPlasma — The Companion Privilege Escalation Tool

Released alongside YellowKey, GreenPlasma is described by Nightmare-Eclipse as a "Windows CTFMON Arbitrary Section Creation Elevation of Privileges Vulnerability." Where YellowKey targets offline data via physical access, GreenPlasma operates on a running Windows system. An unprivileged user can create arbitrary memory-section objects within directory objects normally writable only by SYSTEM, gaining a SYSTEM-level shell. This affects Windows 11 and Windows Server 2025. As of this writing, Microsoft has not assigned a CVE to GreenPlasma and has issued no mitigation.

The two exploits are more dangerous in combination than either is alone. An attacker who uses YellowKey to access an encrypted laptop can extract credentials or data; an insider attacker on a running system could use GreenPlasma to escalate from a standard account to full system control. Security researchers at ThreatLocker noted that both exploits illustrate a broader problem: native Windows security controls — BitLocker, UAC, and the built-in recovery environment — are not independently sufficient when an attacker has physical access or a foothold on the machine.

Affected Windows Versions

CVE-2026-45585 as documented by Microsoft affects the following platforms: Windows 11 versions 24H2, 25H2, and 26H1 (x64); Windows Server 2025; and Windows Server 2025 Server Core. Older Windows 11 versions and Windows 10 have not been confirmed as affected. Windows Server 2022 has been mentioned in some researcher reports as potentially affected, but Microsoft's official advisory does not include it in the scope of CVE-2026-45585.

What Australian Businesses Must Do Right Now

There is no patch for CVE-2026-45585. The mitigations Microsoft published on 20 May 2026 are manual configuration changes, not a security update delivered through Windows Update. That puts the remediation burden squarely on IT teams and managed service providers — not on an automated patching process. Here is what needs to happen, in priority order.

Step 1: Apply the WinRE Registry Mitigation

Microsoft's primary mitigation involves removing the autofstx.exe entry from the BootExecute REG_MULTI_SZ value under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager. This prevents the vulnerable component from executing during the WinRE boot sequence, blocking the specific attack chain YellowKey exploits. This change requires administrator access and must be applied to each affected machine individually (or via Group Policy or an endpoint management platform like Microsoft Intune if you manage devices centrally). Microsoft's advisory, published at Help Net Security, includes the exact registry path and syntax.

Step 2: Enable BitLocker TPM+PIN Mode

The second mitigation is more impactful in the long run. Devices running BitLocker with only a TPM protector — the default configuration on most Windows 11 business deployments — are directly vulnerable to YellowKey. Devices that require a PIN at startup in addition to the TPM are not, because the encrypted volume is not unlocked by WinRE without the correct PIN being entered first. Switching from TPM-only to TPM+PIN can be done via PowerShell using Add-BitLockerKeyProtector, or through the BitLocker management console. For large estates, Microsoft Intune endpoint security policies can enforce this setting across all enrolled devices.

Step 3: Audit Which Machines Are at Risk

Not every Windows device in your organisation faces the same threat level. Desktop machines in locked offices with physical security controls are materially lower risk than laptops carried by field staff, executives, or anyone who travels. Prioritise the TPM+PIN change and registry mitigation on: all portable devices (laptops, Surface tablets, mobile workstations); any Windows Server 2025 instances accessible in co-location facilities or shared data centres; and any device that could realistically end up in an untrusted physical environment.

Step 4: Protect Credentials Independently of the Operating System

One of the less-discussed consequences of a successful YellowKey attack is credential exposure. An attacker with shell access to a BitLocker-decrypted volume can access browser-saved passwords, credential files cached by Windows, locally stored SSH keys, and any password vault file that is not independently encrypted. This is where a zero-knowledge password manager provides defence that disk encryption alone cannot.

A zero-knowledge password manager like NordPass encrypts your vault on-device using XChaCha20 encryption before anything is synchronised to the cloud. The master password used to unlock the vault is never transmitted to NordPass servers — meaning even if an attacker bypasses BitLocker and accesses your disk, what they find is an encrypted vault blob that cannot be read without the master password. Contrast this with browser-saved passwords or Windows Credential Manager entries, which are protected by the OS-level login and become readable once an attacker has OS-level access — exactly what YellowKey provides. For Australian SMBs whose staff store credentials in Chrome or Edge, this is an urgent gap to close regardless of the BitLocker situation.

Layered Defence Beyond Disk Encryption

YellowKey illustrates a principle that security professionals argue about frequently: no single control is sufficient. The Essential Eight exists as a set because the ASD's research shows that attackers consistently find a way around any individual defence. BitLocker is a valuable control — it stops the casual thief from accessing your data with standard forensic tools. But it was never designed to be the sole barrier against a determined attacker with physical access and time. Here is how to build the layers that compensate for its current limitations.

Physical Security Controls

YellowKey requires physical access, so physical security matters here in a way that software-only vulnerabilities do not. For Australian SMBs: fit laptops with cable locks in shared workspaces; enforce a clear-desk policy; use device tracking tools (Microsoft's Find My Device or MDM software) to locate and remotely wipe stolen machines quickly; and require that sensitive devices be stored securely overnight — not left in cars or hotel rooms.

Windows Hello for Business and Multifactor Authentication

GreenPlasma targets privilege escalation on a running system, meaning it is most relevant when an attacker already has a standard user account on the machine. Enforcing Windows Hello for Business — which replaces passwords with biometric or PIN-based authentication tied to the device's TPM — substantially reduces the risk of an attacker obtaining those initial credentials. Combined with conditional access policies in Microsoft Entra ID (formerly Azure AD) that require MFA for all administrative actions, this limits what an attacker can do even if they gain access to a standard account.

Endpoint Management and Device Health Attestation

Organisations using Microsoft Intune can enforce BitLocker TPM+PIN via endpoint security policies and flag devices that have not applied the WinRE mitigation. For Australian businesses without a dedicated IT team, a managed service provider with Microsoft 365 Business Premium experience — which bundles Intune — can deploy both mitigations across the entire device fleet centrally.

Incident Response Preparation Under the NDB Scheme

The Notifiable Data Breaches scheme gives covered entities 30 days from discovering an eligible breach to notify the OAIC and affected individuals. The clock starts when the organisation has reasonable grounds to believe a data breach has occurred — not when they receive the police report for a stolen laptop. Update your incident response procedures now: a stolen Windows 11 device should be treated as a potential eligible data breach unless you can confirm it was running BitLocker in TPM+PIN mode or had the WinRE mitigation applied. If neither can be confirmed, initiate the NDB assessment immediately. This planning costs nothing to do in advance and is far more expensive to do under the 30-day deadline.

YellowKey and GreenPlasma are a reminder that the window between a public PoC drop and a weaponised attack in the wild is shrinking. Australian businesses that treat configuration management as periodic maintenance will consistently find themselves exposed in that gap. The organisations that fare best already have the layered controls in place before a specific vulnerability makes the headlines.