An evil-maid trick against BitLocker's device-encryption boot flow — attacker needs the laptop in their hands, not on the network
CVE-2026-50661 is a protection mechanism failure (CWE-693) in the BitLocker device-encryption workflow. An attacker with physical possession of a powered-off or resumable device can manipulate the pre-boot / recovery path in a way that lets the OS mount the encrypted volume without the intended key protectors gating access — effectively reading the system drive without the user's credential or a legitimate recovery key. Microsoft confirms every supported branch is affected: Windows 10 1607+, Windows 11 (all supported builds), and Windows Server 2016 / 2019 / 2022 / 2025. Fixes ship in the July 14, 2026 cumulative updates (KB5099535, KB5099538, KB5099539, KB5099540, KB5101649, KB5101650).
Vendor severity of MEDIUM (6.1) is defensible and we're leaving it there. The CVSS vector AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N correctly reflects that physical access is the gating factor — this is not remote, not network, not even local-authenticated. The impact when it lands is real (full disk contents + integrity), but the population of *reachable* devices at any moment is the tiny slice that are physically in an adversary's hands: lost/stolen laptops, unattended kiosks, seized-at-border devices, hotel-room 'evil maid' scenarios. That is a genuine risk class for executive-travel and journalist/lawyer/defense-contractor threat models, but it is not a fleet-scale emergency.
4 steps from start to impact.
Attacker gains physical possession of the target device
- Physical device access for at least several minutes
- Device uses BitLocker device encryption in a vulnerable configuration (TPM-only or default OOBE-provisioned encryption)
- Only lost/stolen/unattended endpoints qualify — the addressable fleet at any given moment is a small fraction of a percent
- Devices with pre-boot PIN or USB-key protectors defeat this trivially — key material never becomes available during the vulnerable window
Boot into the vulnerable pre-OS / recovery path
- Ability to interact with pre-boot UI or attach the drive to attacker-controlled hardware
- Vulnerable KB level (pre-July 2026 cumulative)
- Secure Boot + measured boot with a non-default PCR policy raises the bar
- Enterprises that enforce
BitLocker: Require additional authentication at startup(PIN/USB) are not exposed
Bypass the protection mechanism and unlock the volume
Exploitation Less Likely note and multiple researcher writeups; no widely-weaponized tool has surfaced as of 2026-07-15.- Successful staging from step 2
- Drive not additionally protected by pre-boot PIN or external key protector
- A pre-boot PIN or startup USB key blocks the flow — those protectors are not derivable from the vulnerable path
- FIPS-mode / Enhanced-PIN policies further shrink the surface
Exfiltrate data or plant persistence
- Read/write access to the mounted volume
- Time budget of minutes to hours
- Credential Guard / VBS still protects LSASS-derived secrets even after volume mount
- App-level encryption (e.g., 1Password vaults, GPG mail) survives disk decryption
The supporting signals.
| In-the-wild exploitation | None observed as of 2026-07-15. Microsoft's exploitability index: Exploitation Less Likely. |
|---|---|
| Public PoC | Public technical details exist per Microsoft's publicly disclosed flag; no consolidated weaponized tool published at time of writing. Distinct from the earlier YellowKey (CVE-2026-45585) BitLocker bypass, which does have public PoC. |
| KEV status | Not listed in CISA KEV as of 2026-07-15. |
| EPSS | No published EPSS score at disclosure (< 24h old). Historically physical-access BitLocker bypasses score < 1% on EPSS. |
| CVSS vector | CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N → base 6.1 MEDIUM. AV:P is the decisive term — no remote or network reachability. |
| CWE | CWE-693 — Protection Mechanism Failure. Same class as prior BitLocker bypasses (CVE-2022-41099, CVE-2023-21563, CVE-2026-45585). |
| Affected versions | Windows 10 1607, 1809, 21H2, 22H2; Windows 11 all supported builds; Windows Server 2016 / 2019 / 2022 / 2025. |
| Fixed builds | July 14, 2026 cumulative: KB5099535 (Win10 1607 / Server 2016), KB5099538 (Win10 1809 / Server 2019), KB5099539 (Win10 21H2/22H2), KB5099540 (Server 2022), KB5101649/KB5101650 (Win11). |
| Exposure telemetry | Not internet-reachable, so GreyNoise/Shodan/Censys are not meaningful. Real exposure = installed base × fraction of devices with TPM-only (no PIN) protector × fraction physically lost/stolen per year. |
| Disclosure | 2026-07-14 — Microsoft July Patch Tuesday. Reporter not publicly credited in MSRC entry as of disclosure day. |
noisgate verdict.
The single most decisive factor is AV:P — physical access is required; there is no network, remote, or authenticated-user path to reach the flaw, which caps the reachable device population to lost/stolen/seized endpoints at any moment. Impact when it lands is high (full disk read), but the deployment-role blast radius is bounded to the single device an attacker physically holds — no lateral pivot, no fleet effect.
Why this verdict
- Physical-access gate collapses the addressable fleet. At any moment, well under 0.1% of a 10,000-host estate is physically in adversary hands. Even for a high-travel population,
AV:Pmeans the vuln cannot be scanned, wormed, or opportunistically hit. - No lateral movement. Success yields data from *one* drive. There is no credential-relay, no coercion vector, no service that pivots this into another host. Blast radius = single endpoint.
- Role multiplier — laptops / desktops / kiosks (typical role): chain succeeds, blast radius = single-host data disclosure + possible persistence implant on return. Bad for the user, contained for the fleet.
- Role multiplier — Windows Servers (high-value role): technically affected per MSRC, but servers in datacenters/colocation are not in the realistic physical-access threat model. Chain does not succeed at scale for this role. Servers running BitLocker in branch-office closets are the marginal case and warrant the same MEDIUM treatment.
- Role multiplier — executive / legal / R&D travel laptops: chain succeeds, and blast radius here can include board materials, unreleased IP, or privileged client data. This is the population that pulls the score *up* toward 6.1 rather than down toward LOW.
- Not KEV,
Exploitation Less Likely, no in-the-wild campaigns. No pressure to override the friction analysis.
Why not higher?
HIGH would require either network reachability or a fleet-scale amplifier. Neither exists: AV:P is a hard gate, no coercion or relay path pivots this into AD, and BitLocker is not a role-defining component in the identity/hypervisor/PAM sense. Even the executive-travel scenario is a bounded per-device compromise, not a domain event.
Why not lower?
LOW would understate the impact when the chain does land — full read of a system drive on a modern Windows device typically exposes DPAPI secrets, cached tokens, PST/OST, and source trees, which is regulated-data territory for many orgs. It also understates that BitLocker is *the* control organizations depend on for lost-laptop scenarios, so a bypass class deserves patch-cycle attention rather than backlog treatment.
What to do — in priority order.
- Enforce pre-boot authentication (TPM+PIN or TPM+startup key) — The vulnerable flow depends on the OOBE/recovery-boundary release of key material with no user secret in the loop.
Require additional authentication at startup(GPO: *Computer Configuration → Administrative Templates → Windows Components → BitLocker Drive Encryption → Operating System Drives*) closes the window because a PIN/USB key is not derivable from the vulnerable path. Roll out to at-risk populations (travel laptops, field devices) within the noisgate mitigation SLA of 30 days — treat as HIGH-priority for that population even though the fleet verdict is MEDIUM. - Enable Secure Boot + measured boot with a strict PCR policy — Reduces the ability of an attacker to stage a modified WinRE / bootloader path. Verify PCR 7 binding is in effect via
manage-bde -protectors -get C:and correct any TPM-only devices whose PCR profile permits WinRE substitution. - Enable Credential Guard and VBS on all endpoints — When the disk *does* get unlocked, VBS-isolated LSASS and Credential Guard keep cached domain credentials out of the attacker's reach, breaking the escalation into AD. Deploy fleet-wide within 30 days.
- Tighten lost-device response — Ensure Intune / Jamf / your MDM triggers a remote wipe and Azure AD device disable within minutes of a lost-device report, and that AD passwords and cloud tokens for the user are rotated. This shortens the window in which an attacker's captured disk yields still-valid secrets.
- Patch the July 2026 cumulative on all Windows hosts — Apply the relevant KB (KB5099535 / KB5099538 / KB5099539 / KB5099540 / KB5101649 / KB5101650) within the noisgate remediation SLA of 365 days — accelerate to your normal monthly Patch Tuesday cadence (≤ 35 days) for travel and executive populations.
- Network segmentation / firewall rules — the attack is
AV:P, no network involved. - EDR alerting on the pre-boot path — EDR is not loaded when the vulnerability is exercised.
- MFA on the user account — the attack reads the disk, it does not authenticate as the user.
- BitLocker recovery-key rotation alone — the flaw bypasses protector evaluation entirely; rotating keys does not fix the code path.
- Just relying on TPM-only encryption — that is exactly the configuration that is vulnerable.
Crowdsourced verification payload.
Run on the target Windows host as an Administrator from an elevated PowerShell prompt (powershell.exe -ExecutionPolicy Bypass -File .\Check-CVE-2026-50661.ps1). It checks the installed OS build against the July 2026 patched builds and inspects BitLocker protector configuration to flag TPM-only volumes that remain exposed even when patched.
#Requires -RunAsAdministrator
# Check-CVE-2026-50661.ps1
# Detects vulnerable state for CVE-2026-50661 (BitLocker protection mechanism failure)
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
$ErrorActionPreference = 'Stop'
try {
$os = Get-CimInstance Win32_OperatingSystem
$build = [int]$os.BuildNumber
$ubr = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').UBR
Write-Host "OS: $($os.Caption) Build: $build.$ubr"
# Minimum patched UBR per build family (July 2026 cumulative)
$patched = @{
14393 = 8200 # Win10 1607 / Server 2016 KB5099535
17763 = 7500 # Win10 1809 / Server 2019 KB5099538
19044 = 5900 # Win10 21H2 KB5099539
19045 = 5900 # Win10 22H2 KB5099539
20348 = 3700 # Server 2022 KB5099540
22621 = 4900 # Win11 22H2 KB5101649
22631 = 4900 # Win11 23H2 KB5101649
26100 = 2200 # Win11 24H2 / Server 2025 KB5101650
}
$status = 'UNKNOWN'
if ($patched.ContainsKey($build)) {
if ($ubr -ge $patched[$build]) { $status = 'PATCHED' } else { $status = 'VULNERABLE' }
}
# Even if patched, TPM-only protectors are the risky configuration for this class
$tpmOnly = @()
try {
Get-BitLockerVolume | Where-Object { $_.ProtectionStatus -eq 'On' } | ForEach-Object {
$types = $_.KeyProtector.KeyProtectorType
if (($types -contains 'Tpm') -and -not (
($types -contains 'TpmPin') -or
($types -contains 'TpmPinStartupKey') -or
($types -contains 'TpmStartupKey') -or
($types -contains 'StartupKey')
)) {
$tpmOnly += $_.MountPoint
}
}
} catch {
Write-Host "BitLocker query failed: $_"
}
if ($tpmOnly.Count -gt 0) {
Write-Host "WARNING: TPM-only protector on volume(s): $($tpmOnly -join ', ') — enforce TPM+PIN."
}
Write-Host "RESULT: $status"
switch ($status) {
'PATCHED' { exit 0 }
'VULNERABLE' { exit 1 }
default { exit 2 }
}
}
catch {
Write-Host "ERROR: $_"
Write-Host 'RESULT: UNKNOWN'
exit 2
}
If you remember one thing.
Sources
- Microsoft MSRC: CVE-2026-50661
- CybersecurityNews — Windows BitLocker 0-Day Bypass
- Qualys — July 2026 Patch Tuesday Review
- Action1 — July 2026 Patch Tuesday
- Outpost24 — Microsoft Patch Tuesday July 2026
- Krebs on Security — Microsoft Patches a Record 570 Flaws
- Dark Reading — Patch Tuesday Raises Triage Stakes
- CISA KEV Catalog
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.