YellowKey CVE-2026-45585 Bypasses BitLocker Before a Patch Lands
Microsoft has issued a mitigation for CVE-2026-45585, a publicly disclosed BitLocker bypass zero-day dubbed YellowKey, while a full patch is still pending. CVSS 6.8 understates the risk for encrypted-disk-dependent security models.
A BitLocker Bypass With a Name Should Get Your Attention
When a vulnerability gets a catchy name before it gets a patch, that is usually a sign the researcher community found it first and Microsoft is playing catch-up. That is exactly the situation with YellowKey, now formally tracked as CVE-2026-45585.
The CVSS score of 6.8 will tempt some teams to deprioritize this one. We would push back on that instinct hard. BitLocker is not just a compliance checkbox for most organizations. It is frequently the last meaningful control standing between a stolen or seized device and the data on it. A bypass at that layer is not a medium severity problem in practice, regardless of what the number says.
What We Know So Far
Microsoft confirmed the issue publicly after it was already disclosed, describing it as a security feature bypass in Windows. The advisory language, "publicly referred to as YellowKey," tells us the name originated outside Redmond. That means exploit details, proof of concept code, or at least enough technical information to reconstruct the attack path was circulating before Microsoft had a mitigation ready.
What we do not yet know publicly: the exact attack vector, whether physical access is required, and whether any exploitation has been observed in the wild. Those details matter enormously for triage, and until they surface, operators should treat this as requiring physical access controls at minimum and potentially more depending on your threat model.
Mitigation Is Not the Same as a Patch
Microsoft released a mitigation, not a full fix. This distinction matters operationally. A mitigation typically means a configuration change, a policy setting, or a workaround that reduces exposure without actually closing the underlying vulnerability. It can be rolled back, misconfigured, or simply missed during deployment.
For teams managing large Windows fleets through Intune, SCCM, or Group Policy, the immediate action items are:
- Pull the Microsoft advisory and identify the specific mitigation steps
- Prioritize endpoints that travel outside physical security perimeters: laptops, field devices, remote worker machines
- Audit your BitLocker policy configurations and confirm TPM plus PIN or TPM plus network unlock is enforced where appropriate, since a bypass vulnerability may interact differently with various protector configurations
- Track the full patch release date and treat it as a mandatory rapid deployment, not a standard monthly cycle
The Broader Pattern Here
This is the second high-profile BitLocker adjacent issue in recent memory. The encryption-at-rest story in Windows has gotten more complicated as researchers have invested more time in the boot chain and pre-OS environment. If your security architecture treats BitLocker as a hard guarantee rather than a strong probabilistic control, now is a good time to revisit that assumption.
For organizations in regulated industries where full disk encryption is a compliance requirement, document your mitigation deployment carefully. Auditors will ask, and "we saw the CVSS score and waited for the patch" is not a satisfying answer when a named zero-day was publicly disclosed.
We will update coverage here as Microsoft releases the full patch and as technical details about the attack vector become available.
Source: The Hacker News
Original source: thehackernews.com
Keep reading in Threat Intel