On Tuesday, Microsoft pushed out emergency mitigation guidance — not a full patch — for a Windows zero-day called 'YellowKey' that lets anyone with physical access to a laptop bypass BitLocker disk encryption and read everything on the drive. Working exploit code is already public on GitHub. If your business has Windows 11 laptops in employees' cars, in coffee shops, or sitting on a desk overnight, the encryption you've been counting on to protect a lost or stolen device may not actually be doing its job until your IT provider applies the workaround.
What YellowKey actually does
Microsoft released a mitigation for a BitLocker bypass vulnerability named YellowKey following its public disclosure last week. The zero-day flaw, now tracked as CVE-2026-45585, carries a CVSS score of 6.8 and has been described as a BitLocker security feature bypass.
The attack itself is brutally simple. An attacker places specially crafted FsTx files on a USB drive or EFI partition, plugs it into a target machine running BitLocker, reboots into the Windows Recovery Environment (WinRE), and holds down the CTRL key to spawn a shell with unrestricted access to encrypted data. Because YellowKey doesn't require software installation, existing credentials, or network access to break encryption, any machine that has a USB port and can be rebooted can be a target.
In plain English: a thief who grabs a laptop from a parked car can now read every file on it, even though BitLocker is supposedly protecting the drive. The flaw isn't in the encryption math — the vulnerability is not in the encryption itself, but in the recovery environment that surrounds BitLocker.
Who's affected
The flaw impacts Windows 11 versions 24H2, 25H2, and 26H1 for x64-based systems, plus Windows Server 2025 and Server Core installations. That covers essentially every modern Windows business machine purchased in the last two years.
This isn't a theoretical bug, either. Vulnerability analyst Will Dormann confirmed that the PoC exploit works. Microsoft's response is technically useful, but it also exposes the awkward truth at the center of the incident: BitLocker's default convenience model remains brittle when recovery components are trusted too generously.
And there's an even uglier wrinkle. The researcher behind the disclosure says the fix Microsoft is recommending — switching to a BitLocker startup PIN — may not be enough. "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."
What your managed-IT provider should be doing this week
Microsoft hasn't shipped a security update yet — only manual mitigation steps. That means your MSP has to actually do something; this isn't going to fix itself through Windows Update tonight.
The short list of what should be happening on your fleet this week, drawn straight from Microsoft's advisory:
Apply Microsoft's WinRE mitigation to remove autofstx.exe from the relevant BootExecute flow. Reestablish BitLocker trust for WinRE after mitigation. Move high-risk systems from TPM-only BitLocker to TPM+PIN. Use Intune or Group Policy to enforce startup PIN requirements where appropriate. Restrict physical access to sensitive endpoints and servers.
If your provider can't tell you within a day or two which of your laptops are running affected Windows builds, whether BitLocker is enabled in TPM-only or TPM+PIN mode, and whether the WinRE mitigation has been applied — that's a problem. This is the kind of inventory, patching, and endpoint-hardening work that should already be running as part of York Computer's managed IT services, not something your team scrambles to figure out after a laptop goes missing.
A reasonable interim posture for most small businesses: enable TPM+PIN where physical-access risk is real (field laptops, remote workers, anything that leaves the office), restrict who can boot from USB in BIOS, and make sure lost-device reporting actually triggers a remote wipe through Intune or your MDM.
Why a 6.8 CVSS score is misleading here
On paper, CVE-2026-45585 is a mid-severity bug because it requires physical access. Don't let that lull you. The vulnerability has a CVSS score of 6.8 and requires physical access to the target device. Although the score is medium, the impact can be serious for organizations that rely on BitLocker to protect lost, stolen, or unattended devices.
Think about how your business actually uses laptops. They get left in trucks at job sites. They get stolen out of hotel rooms during conferences. They get "borrowed" by ex-employees who walked out angry. The entire reason you turned on BitLocker in the first place was so that none of those scenarios would turn into a data-breach notification under Pennsylvania's breach law. YellowKey changes that math until the mitigation is applied.
What York Businesses Should Do
Most York County small businesses have at least a handful of Windows 11 laptops in the field — sales reps, field service techs, work-from-home staff. If you're not sure whether your machines are running an affected build or how BitLocker is currently configured, get that answered this week, before a missing laptop becomes a reportable incident.
Sources
- Microsoft Releases Mitigation for YellowKey BitLocker Bypass CVE-2026-45585 Exploit
- Microsoft provides mitigation for 'YellowKey' BitLocker bypass flaw (CVE-2026-45585)
- Windows BitLocker zero-day gives access to protected drives, PoC released
- Microsoft Rolls Out Mitigations for 'YellowKey' BitLocker Bypass
- CVE-2026-45585 Microsoft Releases Mitigation for YellowKey BitLocker Bypass