If your laptop fleet relies on BitLocker and you have never thought hard about how BitLocker is configured, this is the week to start. Microsoft’s June 2026 Patch Tuesday closed not one but two BitLocker bypasses — YellowKey (CVE-2026-45585) and a second, separate flaw tracked as CVE-2026-50507 — and both share an uncomfortable property: an attacker with physical access can read a TPM-only encrypted drive without a password, a PIN, or any elevated privileges.
For most of the threats we cover here, the answer involves local admin rights and privilege escalation. This one is different. These are data-at-rest bugs, and they matter every time a device leaves your building.
What YellowKey actually does
YellowKey, discovered and named by researchers at Eclypsium, lives in the Windows Recovery Environment (WinRE) — the small recovery partition that ships on every modern Windows install. By abusing a trust gap in how WinRE handles the BitLocker unlock flow, an attacker with the device in hand can reach the decrypted contents of the system drive.
The important detail for risk assessment: the exploit requires physical access, but it needs nothing else. No login. No user interaction. No admin rights. According to BleepingComputer, a working proof-of-concept was publicly released, and the flaw affects TPM-only BitLocker configurations on Windows 10, Windows 11, and Windows Server 2022 and 2025. Microsoft shipped an interim mitigation in May before the full fix landed in June’s Patch Tuesday.
The second bypass: CVE-2026-50507
Alongside YellowKey, the June updates also addressed CVE-2026-50507, which BleepingComputer describes as a separate BitLocker bypass with the same practical outcome: a missing check in the protection flow lets someone with physical access reach an encrypted system drive. Microsoft has not fully detailed where one flaw ends and the other begins, but the operational takeaway is identical — TPM-only BitLocker had more than one way around it.
Why “we use BitLocker” is not the same as “our data is safe”
A lot of compliance checklists treat BitLocker as a binary: encrypted or not. These bugs are a reminder that how you unlock the drive is the part that matters.
In the default TPM-only mode, the disk decrypts automatically at boot as long as the device’s hardware looks unchanged. That is convenient — no PIN to forget, no help desk calls — but it means the only thing standing between an attacker and your data is the integrity of the early-boot and recovery code. YellowKey and CVE-2026-50507 are exactly that integrity assumption breaking.
Add a pre-boot authentication factor — a PIN or a startup key — and the calculus changes. The attacker no longer has an automatic unlock to attack; they need a secret the device cannot supply on its own.
Who is actually at risk
Because exploitation needs the physical device, this is not a “patch tonight or the internet eats you” scenario. It is a lost-and-stolen-laptop scenario, a device-disposal scenario, and an “unattended in a hotel room” scenario. If your honest answer to “what happens when one of our laptops walks out the door?” has always been “BitLocker has us covered,” these CVEs just weakened that answer for any device still running TPM-only.
What to do now
- Deploy the June 2026 updates — and update WinRE explicitly. The recovery partition is not always serviced by a normal monthly update. Confirm the recovery environment itself is patched, not just the running OS.
- Move TPM-only devices to TPM+PIN or add a startup key. This is the single most effective change. Pre-boot authentication breaks the automatic-unlock assumption both bugs rely on.
- Audit your fleet’s BitLocker configuration. Use
manage-bde -statusor Intune encryption reporting to find every device still on TPM-only, and prioritise laptops and anything that travels. - Confirm recovery keys are escrowed and protected. Make sure keys live in Entra ID or Active Directory, are not sitting in a spreadsheet, and rotate any that may have been exposed.
- Treat any device lost while unpatched as potentially readable. Factor that into your breach and data-protection assessments rather than assuming encryption held.
- Write the policy down. Make pre-boot authentication the documented standard for portable devices, so new machines are not silently provisioned back to TPM-only.
None of this is exotic. It is the same lesson that keeps coming back on Windows endpoints: the default that is easiest for users is rarely the one that holds up under pressure. BitLocker is still worth running — just not on trust alone.
