Microsoft acknowledged CVE-2026-45585 on May 19, 2026, after researcher Nightmare-Eclipse publicly released YellowKey, a proof-of-concept Windows Recovery Environment technique that can bypass BitLocker protections on affected Windows 11 systems with physical access. The company’s response is technically useful and politically combustible: it offers an interim mitigation while also accusing the public release of violating coordinated disclosure norms. That framing turns a Windows recovery flaw into a larger argument about trust, not just between BitLocker and WinRE, but between Microsoft and the researchers it depends on to find ugly bugs before criminals do.
YellowKey is not a remote worm, and it is not the sort of vulnerability that lets an attacker silently reach across the internet into a laptop. Its danger is more old-fashioned and more intimate: someone needs access to the machine, a crafted USB device or equivalent access path, and a recovery environment that behaves more generously than defenders assumed it would.
That distinction matters, but it should not minimize the issue. BitLocker is sold, deployed, and trusted precisely because laptops get stolen, seized, repaired, lost in airports, and handled by people who are not their owners. A BitLocker bypass with a physical-access requirement still lands squarely in the threat model for enterprise endpoints, journalists, lawyers, executives, developers, and anyone else carrying sensitive data outside a locked office.
Microsoft’s mitigation guidance shows the company understands the practical risk. The advisory provides an interim script intended to modify the Windows Recovery Environment image by removing
But the most revealing sentence in the advisory is not the mitigation. It is Microsoft’s complaint that the proof of concept was made public in violation of coordinated vulnerability disclosure best practices. That may be true in the narrow procedural sense, but it is also a risky line for a vendor to lead with when the same advisory confirms that users need protection before a full security update is available.
YellowKey appears to exploit precisely that discomfort. The public reporting around the flaw describes a path involving the Windows Recovery Environment, BitLocker-protected volumes, and an
That is why the vulnerability feels more serious than its “physical access” label may suggest. Security teams have long treated physical access as a high bar, but modern endpoint security exists because physical loss is routine. The laptop in a hotel room, the executive machine in a stolen backpack, the developer workstation shipped to a repair depot, and the field device left in a vehicle are not exotic scenarios.
Microsoft’s CVSS vector reportedly scores the flaw at 6.8, a medium rating, with physical attack vector, low attack complexity, no privileges required, no user interaction, and high impact to confidentiality, integrity, and availability. That is a strange-looking combination to normal readers: “medium” severity paired with “high” impact everywhere. It is a reminder that scoring systems can flatten a vulnerability’s operational meaning.
For a consumer gaming PC at home, YellowKey may be mostly theoretical. For a managed fleet with thousands of BitLocker-protected laptops moving through airports, coworking spaces, home offices, and temporary contractors’ hands, it is not theoretical at all. The exploitability line is not whether an attacker is across the network; it is whether the organization’s model assumes BitLocker remains meaningful after the device leaves sight.
That level of specificity is important. WinRE is not just another folder on disk that administrators can casually patch by hand. It is part of the boot and recovery architecture, and tampering with it badly can strand users in recovery loops or trigger BitLocker trust failures. Microsoft’s script-based approach is an attempt to reduce the attack surface without asking every administrator to become a boot-chain surgeon.
It also reveals the core issue: the problem is not merely that a researcher posted code. The problem is that Windows shipped with a recovery behavior that Microsoft now believes should be suppressed while it prepares a security update. The mitigation is a tacit admission that the attack path is credible enough to warrant action before Patch Tuesday can deliver a normal servicing fix.
The company’s advice is especially relevant for organizations whose employees travel with work devices or take them home. That is almost every modern organization with a laptop fleet. The pandemic-era endpoint model never really went away; it simply became normal operations, which means the security boundary moved from the office perimeter to the boot path of a laptop sitting on a kitchen table.
There is also an administrative burden hiding beneath the mitigation. Enterprises need to discover which devices are affected, determine whether WinRE is enabled and in what state, deploy the script safely, validate that it made the intended change, and make sure future servicing does not reintroduce the vulnerable configuration. A temporary fix is still a change-management event.
Microsoft is therefore not wrong to prefer private reporting and staged disclosure. The company has a legitimate interest in preventing weaponizable details from spreading before mitigations exist. Enterprise customers have the same interest, even if they are often frustrated by vendor silence.
But disclosure norms depend on trust in both directions. Researchers are expected to give vendors time and discretion; vendors are expected to communicate, handle reports fairly, credit researchers appropriately, and avoid turning bureaucratic friction into reputational damage. When that relationship breaks down, the policy language of “best practices” stops sounding neutral and starts sounding like a press shield.
Nightmare-Eclipse’s response, as quoted in the source material, suggests exactly that kind of breakdown. The researcher alleges that Microsoft revoked access to an MSRC account used for reporting vulnerabilities, later wiped the account, and failed to answer attempts to get an explanation. Those claims are serious, and they are also disputed terrain unless Microsoft provides its own detailed account.
What is clear is that the public argument has now moved beyond YellowKey. It is about whether Microsoft’s vulnerability intake process is perceived as fair by the people finding flaws at the edge of the platform. That perception matters, because Windows security is too large for Microsoft to audit alone.
Public exploit releases create risk. Even if the researcher’s frustration is justified, defenders still wake up to a world in which attack details are easier to reproduce. Small organizations without mature endpoint management may learn about the issue from headlines long before they understand how to apply the mitigation.
At the same time, vendor frustration is not a substitute for root-cause accountability. Microsoft can criticize the timing of a proof-of-concept release, but it cannot make the underlying Windows behavior disappear by invoking process. If the recovery environment can be manipulated into undermining BitLocker’s expected protection, the security story must start there.
The researcher’s broader pattern also complicates the picture. Nightmare-Eclipse has reportedly published several Windows flaws recently, including MiniPlasma, which concerns malicious Registry modifications and revives questions about older vulnerability classes that may not have been fully extinguished. A burst of disclosures from one actor can look like pressure, protest, escalation, or all three at once.
For readers and administrators, the productive stance is not to romanticize the researcher or defend Microsoft reflexively. The productive stance is to separate three questions: whether the bug is real, whether the mitigation reduces exposure, and whether the disclosure process failed badly enough to make future public dumps more likely. On the first two, the answer appears to be yes. On the third, Microsoft has a larger reputational problem than it may want to admit.
YellowKey is unnerving because it attacks that boring assumption. It suggests that a trusted recovery path can become a place where the encrypted volume is available under conditions defenders did not expect. That is not necessarily a cryptographic failure; it is an integration failure, which is often where real-world security systems break.
This is the same uncomfortable lesson that has followed secure boot, measured boot, TPM sealing, recovery partitions, and endpoint management for years. The math can be sound while the workflow around the math leaks power. A recovery tool that must operate early and with privilege is inherently dangerous if it trusts inputs it should not trust.
That is why calling YellowKey a “backdoor,” as some public commentary has done, may be rhetorically satisfying but analytically premature. A vulnerability can be severe without being intentional. The more important question for administrators is whether the attack path is plausible in their environment and whether Microsoft’s mitigation closes enough of it until a real update lands.
The answer will vary. Devices with strong physical controls, additional pre-boot authentication, or tightly managed recovery access may face less practical exposure. Devices relying on default BitLocker configurations in mobile environments deserve more urgent attention.
The first priority is inventory. Administrators need to know which Windows versions and device classes are in scope, whether WinRE is enabled, whether BitLocker is deployed, and whether the vulnerable recovery configuration exists. The NVD listing indicates Windows 11 24H2, Windows 11 25H2, Windows 11 26H1, and Windows Server 2025 configurations are in the known affected set, though organizations should treat Microsoft’s advisory as the living source while it evolves.
The second priority is physical threat modeling. A kiosk, a lab machine, a loaner laptop, and a domain-joined executive notebook do not carry the same risk. A vulnerability requiring physical access is still urgent when the device is designed to travel or may be handled by untrusted parties.
The third priority is communications. Help desks should be ready for BitLocker recovery prompts, WinRE oddities, and user confusion if mitigation deployment goes wrong. Security teams should avoid telling users “BitLocker is broken,” because that is both imprecise and counterproductive. The more accurate message is that Microsoft has acknowledged a recovery-environment bypass risk and issued an interim hardening step.
The fourth priority is patience with the patch cycle. A proper fix may need to alter recovery behavior without breaking legitimate repair operations. That is not trivial in Windows, where recovery is expected to work across OEM images, enterprise deployments, encrypted volumes, update failures, and consumer reset workflows.
Here, the backstage drama has become part of the security event. Microsoft’s advisory language publicly criticizes the proof-of-concept release. The researcher publicly accuses Microsoft of damaging their reputation and mishandling their reporting access. Neither side benefits from this becoming the lasting story, but it already has.
For Microsoft, the danger is not only this one researcher. It is the signal sent to others who find bugs in Windows but lack the institutional patience, legal comfort, or professional incentive to navigate a difficult disclosure path. If researchers believe they will be ignored, locked out, or publicly blamed, some will choose public release first and coordination later.
For researchers, the danger is also real. Public disclosure can burn credibility, create legal exposure, and harm users who have no role in the dispute. Even when a vendor behaves poorly, releasing a working exploit before a fix exists shifts risk onto defenders who cannot patch politics.
The healthiest outcome would be boring: Microsoft clarifies the timeline, fixes the vulnerability, reviews the account-handling allegations, and improves communication around contested reports. The researcher, ideally, returns to a channel where future findings can be handled without public detonations. That may be optimistic, but it is what the Windows ecosystem needs.
YellowKey is a reminder that the Windows attack surface is not only the browser, the kernel, Office macros, or exposed services. It is also the recovery environment, the boot registry, maintenance utilities, transaction logs, and every component that runs before the operating system is fully itself. Those spaces are harder for ordinary users to understand and harder for administrators to monitor.
The most useful vendor response is therefore not indignation, even if Microsoft believes the disclosure was mishandled. The useful response is a credible fix, transparent mitigation guidance, and evidence that similar WinRE trust assumptions are being audited. Administrators do not need a morality play. They need to know whether the same class of bug exists elsewhere.
There is also a product lesson. If BitLocker’s protection depends on recovery behaviors that are too subtle for users and admins to reason about, Microsoft needs to make the secure state easier to see and maintain. A fleet owner should not need a security researcher’s GitHub repository and an emergency advisory to learn whether a recovery component can undercut disk encryption.
Microsoft’s Recovery Problem Has Become a Trust Problem
YellowKey is not a remote worm, and it is not the sort of vulnerability that lets an attacker silently reach across the internet into a laptop. Its danger is more old-fashioned and more intimate: someone needs access to the machine, a crafted USB device or equivalent access path, and a recovery environment that behaves more generously than defenders assumed it would.That distinction matters, but it should not minimize the issue. BitLocker is sold, deployed, and trusted precisely because laptops get stolen, seized, repaired, lost in airports, and handled by people who are not their owners. A BitLocker bypass with a physical-access requirement still lands squarely in the threat model for enterprise endpoints, journalists, lawyers, executives, developers, and anyone else carrying sensitive data outside a locked office.
Microsoft’s mitigation guidance shows the company understands the practical risk. The advisory provides an interim script intended to modify the Windows Recovery Environment image by removing
autofstx.exe from the BootExecute registry value. In plain English, Microsoft is trying to stop a recovery-time component from running early in a privileged boot path where it can be abused before the normal operating system security model is fully in place.But the most revealing sentence in the advisory is not the mitigation. It is Microsoft’s complaint that the proof of concept was made public in violation of coordinated vulnerability disclosure best practices. That may be true in the narrow procedural sense, but it is also a risky line for a vendor to lead with when the same advisory confirms that users need protection before a full security update is available.
YellowKey Hits the Awkward Boundary Between Encryption and Recovery
Disk encryption is only as strong as the boot chain around it. BitLocker protects data at rest, but Windows must still support recovery, repair, updates, rollback, diagnostics, and automated repair operations. Those features live in an uncomfortable space: they must be powerful enough to fix a broken system, but constrained enough not to become a skeleton key.YellowKey appears to exploit precisely that discomfort. The public reporting around the flaw describes a path involving the Windows Recovery Environment, BitLocker-protected volumes, and an
FsTx folder placed through removable media or similar access. The apparent result is a recovery-mode sequence in which an attacker can reach data that should remain protected from someone who merely has the device.That is why the vulnerability feels more serious than its “physical access” label may suggest. Security teams have long treated physical access as a high bar, but modern endpoint security exists because physical loss is routine. The laptop in a hotel room, the executive machine in a stolen backpack, the developer workstation shipped to a repair depot, and the field device left in a vehicle are not exotic scenarios.
Microsoft’s CVSS vector reportedly scores the flaw at 6.8, a medium rating, with physical attack vector, low attack complexity, no privileges required, no user interaction, and high impact to confidentiality, integrity, and availability. That is a strange-looking combination to normal readers: “medium” severity paired with “high” impact everywhere. It is a reminder that scoring systems can flatten a vulnerability’s operational meaning.
For a consumer gaming PC at home, YellowKey may be mostly theoretical. For a managed fleet with thousands of BitLocker-protected laptops moving through airports, coworking spaces, home offices, and temporary contractors’ hands, it is not theoretical at all. The exploitability line is not whether an attacker is across the network; it is whether the organization’s model assumes BitLocker remains meaningful after the device leaves sight.
The Interim Fix Says More Than the Press Statement
Microsoft’s mitigation is careful, limited, and clearly positioned as a stopgap. It is not presented as the final fix. It modifies the offline Windows RE image, edits the SYSTEM registry hive, removes the relevant boot entry if present, commits the image, and reseals the recovery environment so BitLocker trust is not broken in the process.That level of specificity is important. WinRE is not just another folder on disk that administrators can casually patch by hand. It is part of the boot and recovery architecture, and tampering with it badly can strand users in recovery loops or trigger BitLocker trust failures. Microsoft’s script-based approach is an attempt to reduce the attack surface without asking every administrator to become a boot-chain surgeon.
It also reveals the core issue: the problem is not merely that a researcher posted code. The problem is that Windows shipped with a recovery behavior that Microsoft now believes should be suppressed while it prepares a security update. The mitigation is a tacit admission that the attack path is credible enough to warrant action before Patch Tuesday can deliver a normal servicing fix.
The company’s advice is especially relevant for organizations whose employees travel with work devices or take them home. That is almost every modern organization with a laptop fleet. The pandemic-era endpoint model never really went away; it simply became normal operations, which means the security boundary moved from the office perimeter to the boot path of a laptop sitting on a kitchen table.
There is also an administrative burden hiding beneath the mitigation. Enterprises need to discover which devices are affected, determine whether WinRE is enabled and in what state, deploy the script safely, validate that it made the intended change, and make sure future servicing does not reintroduce the vulnerable configuration. A temporary fix is still a change-management event.
Microsoft Is Right About Disclosure Norms, But That Is Not the Whole Story
Coordinated vulnerability disclosure exists for a reason. Giving vendors time to investigate, reproduce, build, test, and ship fixes reduces the window in which attackers have reliable public instructions and defenders have nothing but anxiety. Public proof-of-concept code can accelerate exploitation, especially when the bug affects a ubiquitous platform like Windows.Microsoft is therefore not wrong to prefer private reporting and staged disclosure. The company has a legitimate interest in preventing weaponizable details from spreading before mitigations exist. Enterprise customers have the same interest, even if they are often frustrated by vendor silence.
But disclosure norms depend on trust in both directions. Researchers are expected to give vendors time and discretion; vendors are expected to communicate, handle reports fairly, credit researchers appropriately, and avoid turning bureaucratic friction into reputational damage. When that relationship breaks down, the policy language of “best practices” stops sounding neutral and starts sounding like a press shield.
Nightmare-Eclipse’s response, as quoted in the source material, suggests exactly that kind of breakdown. The researcher alleges that Microsoft revoked access to an MSRC account used for reporting vulnerabilities, later wiped the account, and failed to answer attempts to get an explanation. Those claims are serious, and they are also disputed terrain unless Microsoft provides its own detailed account.
What is clear is that the public argument has now moved beyond YellowKey. It is about whether Microsoft’s vulnerability intake process is perceived as fair by the people finding flaws at the edge of the platform. That perception matters, because Windows security is too large for Microsoft to audit alone.
The Researcher’s Anger Is Not a Patch
There is a temptation in stories like this to choose a side and stop thinking. Either the researcher is a reckless actor burning down disclosure norms, or Microsoft is a giant vendor blaming an outsider for exposing an uncomfortable truth. Reality is usually less satisfying and more useful.Public exploit releases create risk. Even if the researcher’s frustration is justified, defenders still wake up to a world in which attack details are easier to reproduce. Small organizations without mature endpoint management may learn about the issue from headlines long before they understand how to apply the mitigation.
At the same time, vendor frustration is not a substitute for root-cause accountability. Microsoft can criticize the timing of a proof-of-concept release, but it cannot make the underlying Windows behavior disappear by invoking process. If the recovery environment can be manipulated into undermining BitLocker’s expected protection, the security story must start there.
The researcher’s broader pattern also complicates the picture. Nightmare-Eclipse has reportedly published several Windows flaws recently, including MiniPlasma, which concerns malicious Registry modifications and revives questions about older vulnerability classes that may not have been fully extinguished. A burst of disclosures from one actor can look like pressure, protest, escalation, or all three at once.
For readers and administrators, the productive stance is not to romanticize the researcher or defend Microsoft reflexively. The productive stance is to separate three questions: whether the bug is real, whether the mitigation reduces exposure, and whether the disclosure process failed badly enough to make future public dumps more likely. On the first two, the answer appears to be yes. On the third, Microsoft has a larger reputational problem than it may want to admit.
BitLocker’s Promise Depends on Boring Assumptions
BitLocker works best when nothing exciting happens. The TPM measures the boot path, the system starts as expected, recovery keys remain protected, and the user never thinks about the cryptographic ceremony happening underneath Windows. Full-disk encryption is supposed to be boring infrastructure.YellowKey is unnerving because it attacks that boring assumption. It suggests that a trusted recovery path can become a place where the encrypted volume is available under conditions defenders did not expect. That is not necessarily a cryptographic failure; it is an integration failure, which is often where real-world security systems break.
This is the same uncomfortable lesson that has followed secure boot, measured boot, TPM sealing, recovery partitions, and endpoint management for years. The math can be sound while the workflow around the math leaks power. A recovery tool that must operate early and with privilege is inherently dangerous if it trusts inputs it should not trust.
That is why calling YellowKey a “backdoor,” as some public commentary has done, may be rhetorically satisfying but analytically premature. A vulnerability can be severe without being intentional. The more important question for administrators is whether the attack path is plausible in their environment and whether Microsoft’s mitigation closes enough of it until a real update lands.
The answer will vary. Devices with strong physical controls, additional pre-boot authentication, or tightly managed recovery access may face less practical exposure. Devices relying on default BitLocker configurations in mobile environments deserve more urgent attention.
The Enterprise Risk Is Physical, Fleet-Wide, and Annoyingly Practical
For sysadmins, YellowKey is less a cinematic heist than another fleet hygiene problem with security consequences. The work is to identify exposure, deploy mitigation, verify state, and prepare for Microsoft’s eventual patch. None of that is glamorous, and all of it matters.The first priority is inventory. Administrators need to know which Windows versions and device classes are in scope, whether WinRE is enabled, whether BitLocker is deployed, and whether the vulnerable recovery configuration exists. The NVD listing indicates Windows 11 24H2, Windows 11 25H2, Windows 11 26H1, and Windows Server 2025 configurations are in the known affected set, though organizations should treat Microsoft’s advisory as the living source while it evolves.
The second priority is physical threat modeling. A kiosk, a lab machine, a loaner laptop, and a domain-joined executive notebook do not carry the same risk. A vulnerability requiring physical access is still urgent when the device is designed to travel or may be handled by untrusted parties.
The third priority is communications. Help desks should be ready for BitLocker recovery prompts, WinRE oddities, and user confusion if mitigation deployment goes wrong. Security teams should avoid telling users “BitLocker is broken,” because that is both imprecise and counterproductive. The more accurate message is that Microsoft has acknowledged a recovery-environment bypass risk and issued an interim hardening step.
The fourth priority is patience with the patch cycle. A proper fix may need to alter recovery behavior without breaking legitimate repair operations. That is not trivial in Windows, where recovery is expected to work across OEM images, enterprise deployments, encrypted volumes, update failures, and consumer reset workflows.
Microsoft’s MSRC Problem Is Now Part of the Vulnerability
MSRC exists to convert chaos into process. Researchers submit findings, Microsoft triages them, engineers assess impact, fixes are built, credits are assigned, and users eventually receive updates. When that process works, the public sees a CVE and a patch; the drama remains backstage.Here, the backstage drama has become part of the security event. Microsoft’s advisory language publicly criticizes the proof-of-concept release. The researcher publicly accuses Microsoft of damaging their reputation and mishandling their reporting access. Neither side benefits from this becoming the lasting story, but it already has.
For Microsoft, the danger is not only this one researcher. It is the signal sent to others who find bugs in Windows but lack the institutional patience, legal comfort, or professional incentive to navigate a difficult disclosure path. If researchers believe they will be ignored, locked out, or publicly blamed, some will choose public release first and coordination later.
For researchers, the danger is also real. Public disclosure can burn credibility, create legal exposure, and harm users who have no role in the dispute. Even when a vendor behaves poorly, releasing a working exploit before a fix exists shifts risk onto defenders who cannot patch politics.
The healthiest outcome would be boring: Microsoft clarifies the timeline, fixes the vulnerability, reviews the account-handling allegations, and improves communication around contested reports. The researcher, ideally, returns to a channel where future findings can be handled without public detonations. That may be optimistic, but it is what the Windows ecosystem needs.
The Lesson Microsoft Should Not Miss
Microsoft’s security posture in 2026 is paradoxical. The company has invested heavily in secure development, default encryption, hardware-backed identity, cloud telemetry, and endpoint defense. Yet Windows remains a vast compatibility machine with old corners, recovery subsystems, and privileged utilities that can surprise even experienced researchers.YellowKey is a reminder that the Windows attack surface is not only the browser, the kernel, Office macros, or exposed services. It is also the recovery environment, the boot registry, maintenance utilities, transaction logs, and every component that runs before the operating system is fully itself. Those spaces are harder for ordinary users to understand and harder for administrators to monitor.
The most useful vendor response is therefore not indignation, even if Microsoft believes the disclosure was mishandled. The useful response is a credible fix, transparent mitigation guidance, and evidence that similar WinRE trust assumptions are being audited. Administrators do not need a morality play. They need to know whether the same class of bug exists elsewhere.
There is also a product lesson. If BitLocker’s protection depends on recovery behaviors that are too subtle for users and admins to reason about, Microsoft needs to make the secure state easier to see and maintain. A fleet owner should not need a security researcher’s GitHub repository and an emergency advisory to learn whether a recovery component can undercut disk encryption.
The YellowKey Fight Leaves Admins With Work, Not Closure
Microsoft has turned YellowKey into an interim mitigation story, but the operational reality for Windows administrators is still unresolved. Until a full security update arrives and is broadly deployed, the responsible posture is to reduce exposure, verify recovery images, and treat physically accessible BitLocker-protected systems as needing extra scrutiny.- Organizations should prioritize mitigation on Windows laptops and mobile workstations that leave controlled premises.
- Administrators should test Microsoft’s script on representative devices before broad deployment because WinRE and BitLocker trust failures can become support incidents.
- Security teams should review whether high-risk users need additional pre-boot authentication or tighter physical handling procedures.
- Help desks should prepare clear language for users so the message is not reduced to the misleading claim that BitLocker no longer works.
- Microsoft should publish enough detail about the eventual fix to let defenders understand whether this was a narrow
autofstx.exeproblem or evidence of a broader WinRE trust issue.
References
- Primary source: Neowin
Published: 2026-05-22T09:10:12.792597
Microsoft apparently blames researcher for publicly exposing a Windows 11 Recovery flaw
Microsoft appears to blame a security researcher for publicly revealing a legitimate Windows 11 Recovery vulnerability affecting BitLocker protection.
www.neowin.net
- Related coverage: pcgamer.com
Microsoft says public sharing of Windows 11 vulnerability violates 'best practices'
The king in yellow.www.pcgamer.com
- Related coverage: windowscentral.com
Microsoft fixes a major BitLocker bug… but leaves Windows 10 users hanging (for now)
Microsoft ships critical BitLocker bug fix for Windows 11 (25H2) users, Windows 10 waits in the cold.
www.windowscentral.com
- Related coverage: techradar.com
Chaotic Eclipse strikes again with another worrying Windows security flaw
A new Windows 11 bug called MiniPlasma was disclosed on GitHub, together with a PoC.www.techradar.com
- Related coverage: notebookcheck.net
Microsoft mitigates YellowKey BitLocker bypass, no patch yet
Microsoft released mitigation steps for YellowKey (CVE-2026-45585), a BitLocker bypass that grants physical attackers access to encrypted Windows drives.
www.notebookcheck.net
- Related coverage: threataft.com
YellowKey BitLocker Bypass: Microsoft Releases Mitigation | ThreatAft
Microsoft released mitigations for YellowKey (CVE-2026-45585) — a BitLocker bypass where FsTx files on USB give physical attackers a shell on encrypted drives.threataft.com
- Related coverage: innovationnetworkdesign.com
HIGH: Microsoft Ships Mitigation for YellowKey BitLoc… | Innovation ND
Microsoft published mitigation guidance for CVE-2026-45585, the YellowKey BitLocker bypass zero-day publicly disclosed by researcher Chaotic Eclipse last week. The flaw lives in the FsTx Auto Recovery Utility inside Windows Recovery Environment and lets anyone with physical access and a USB...www.innovationnetworkdesign.com
- Related coverage: techspot.com
- Related coverage: imtr.net
Microsoft shares mitigation for YellowKey Windows zero-day
Microsoft has shared mitigations for YellowKey, a recently disclosed Windows BitLocker zero-day vulnerability that grants access to protected drives. [...]imtr.net
- Related coverage: computerworld.com
Microsoft is working on a patch for 'YellowKey' attack on Bitlocker, offers temporary fix
Exploitation requires physical access, so enterprises should look to their device security policies.
www.computerworld.com
- Related coverage: tomshardware.com
Microsoft BitLocker-protected drives can now be opened with just some files on a USB stick — YellowKey zero-day exploit demonstrates an apparent backdoor
Also, it's a twofer with the GreenPlasma zero-day local privilege escalation.www.tomshardware.com
- Related coverage: aha.org
- Related coverage: labs.cloudsecurityalliance.org
