WinRE bypass unlocks BitLocker, UEFI passwords
A flaw in Windows Recovery Environment lets attackers with physical access bypass UEFI/BIOS passwords and weaken BitLocker protections.
Sourcekb.cert.org — open the original
What to check
- Applies to
- The 1 CVE named below. Whether you run an affected version is not assessed: check the versions the source lists.
- Exploitation
- No exploitation in the wild and no public exploit is recorded for the CVEs named.
CERT/CC has published an advisory describing a vulnerability in Microsoft's Windows Recovery Environment (WinRE) that can allow an attacker with physical or administrative access to bypass firmware-level security controls, including administrator-configured UEFI/BIOS passwords. The issue stems from inconsistent enforcement of security checks along WinRE's alternate boot path, and from the unauthenticated nature of the UEFI BootNext NVRAM variable, which takes precedence over the standard BootOrder and is not guaranteed to trigger a full platform reset or re-authentication.
The vulnerability, tracked as CVE-2026-45585, enables so-called 'Evil Maid' attack scenarios in which a brief window of unattended physical access is used to manipulate boot configuration and circumvent pre-boot protections, potentially weakening BitLocker full-disk encryption and exposing sensitive data. The research underlying this advisory draws on work from Eclypsium (referenced as the 'YellowKey' BitLocker bypass). No active exploitation is described in the advisory; this is a disclosed design/implementation weakness with vendor guidance rather than an observed in-the-wild campaign.
CERT/CC and Microsoft recommend that organizations with high-security requirements not rely solely on UEFI/BIOS passwords, and instead disable or restrict WinRE where unnecessary, require ephemeral authorization before invoking recovery, pair BitLocker with TPM+PIN or TPM+Startup Key, restrict NVRAM/ESP modifications, deploy EDR with pre-boot/measured-boot attestation, and enforce physical security controls for high-value devices.
Mentioned in this report
Detection guidance
BCDEdit Modifying Boot Manager Sequence or Boot Entries
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
Detects bcdedit.exe being used to alter the boot manager's default entry, boot sequence, or timeout - the local mechanism for manipulating BootNext/BootOrder equivalents that CVE-2026-45585 abuses at the firmware layer, and a technique attackers use post-compromise to force boot into WinRE or an alternate OS loader. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: BCDEdit Modifying Boot Manager Sequence or Boot Entries
description: Detects bcdedit.exe invocations that change the default boot entry, one-time
boot sequence, or bootmgr settings. This is the OS-visible analogue of the unauthenticated
UEFI BootNext manipulation described in CVE-2026-45585 (WinRE/BitLocker bypass),
and is also used generically by attackers to force a reboot into WinRE, Safe Mode,
or an alternate loader for pre-boot tampering.
tags:
- attack.stealth
- attack.t1542
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: \bcdedit.exe
CommandLine|contains:
- bootsequence
- /default
- /set {fwbootmgr}
- /set {bootmgr}
- /displayorder
filter_common_recovery_tools:
ParentImage|endswith:
- \TrustedInstaller.exe
- \MoUsoCoreWorker.exe
condition: selection and not filter_common_recovery_tools
falsepositives:
- Legitimate dual-boot configuration changes by administrators
- OS deployment / imaging tools (MDT, SCCM) adjusting boot order during provisioning
- Windows Update or feature-update servicing temporarily altering boot entries
level: medium
id: d845ee18-049b-5d7d-9c34-101c2f80ac9b
status: experimental
author: Vorant
ReagentC Used to Disable, Enable, or Boot Into WinRE
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
Detects reagentc.exe invocations that toggle Windows Recovery Environment state or force a one-time boot into WinRE (/boottore), the alternate boot path described in the advisory as inconsistently enforcing pre-boot security checks. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: ReagentC Used to Disable, Enable, or Boot Into WinRE
description: Detects use of reagentc.exe to disable/enable the Windows Recovery Environment
or to force an immediate one-time boot into WinRE (/boottore). CVE-2026-45585 highlights
that WinRE's alternate boot path can bypass firmware-level protections such as UEFI/BIOS
passwords, making unexpected reagentc activity worth reviewing, especially outside
planned maintenance windows.
tags:
- attack.stealth
- attack.t1542
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: \reagentc.exe
CommandLine|contains:
- /boottore
- /disable
- /enable
filter_sccm_imaging:
ParentImage|endswith:
- \CcmExec.exe
- \TSManager.exe
condition: selection and not filter_sccm_imaging
falsepositives:
- IT staff intentionally disabling WinRE per hardening guidance recommended by CERT/CC
- OS deployment / task sequence tools invoking reagentc during imaging
level: medium
id: 500191c2-8fd1-597e-bc91-1946e198a629
status: experimental
author: Vorant
PowerShell or Command-Line Access to UEFI Firmware Environment Variables
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
Detects use of PowerShell firmware-variable cmdlets or bcdedit's firmware-store option to read/write UEFI NVRAM variables directly, the unauthenticated storage layer (e.g. BootNext) that CVE-2026-45585 exploits to override BootOrder without re-authentication. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: PowerShell or Command-Line Access to UEFI Firmware Environment Variables
description: Detects PowerShell use of Get-/Set-FirmwareEnvironmentVariable cmdlets,
or bcdedit targeting the firmware boot manager store, which directly read or write
UEFI NVRAM variables such as BootNext. The advisory notes these variables are unauthenticated
and take precedence over BootOrder, enabling pre-boot security bypass; legitimate
use of these APIs outside firmware tooling/OEM utilities is rare.
tags:
- attack.stealth
- attack.t1542
logsource:
category: process_creation
product: windows
detection:
selection_ps:
Image|endswith:
- \powershell.exe
- \pwsh.exe
CommandLine|contains:
- FirmwareEnvironmentVariable
selection_bcdedit_store:
Image|endswith: \bcdedit.exe
CommandLine|contains: firmware
condition: 1 of selection_*
falsepositives:
- OEM firmware update utilities or diagnostic tools reading UEFI variables
- Administrative scripts inventorying secure-boot or firmware configuration for compliance
checks
level: medium
id: 0374827f-4b43-58ec-87ed-f77818394e59
status: experimental
author: Vorant
Behavioural rules are generated from public reporting — validate in your environment before deploying.
Source reporting: https://kb.cert.org/vuls/id/226679
Free public brief. The detections with Splunk SPL already written (plus Elastic and KQL where they apply) are in the app with a free account, no card. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them.
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply) and live profiles of the CVEs it names. The paid plans add the security research and news reporting the free tier leaves out.
It sits in a corpus of 16,436 reports from 149 sources, 661 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Slack alerts are a paid-plan feature: name the vendors you run and Slack hears about the reports that touch them, not the rest of the week's. Nothing is charged unless you subscribe.
Create a free account What it costs