{"vuid":"VU#226679","idnumber":"226679","name":"Microsoft WinRE allows for bypass of UEFI/BIOS password enforcement","keywords":null,"overview":"### Overview\r\nMicrosoft Windows Recovery Environment (WinRE) provides a mechanism for recovering and repairing Windows systems using an alternate boot environment. Under certain platform implementations, access to WinRE may allow an attacker to bypass firmware security controls, including administrator-configured UEFI/BIOS passwords. An attacker with physical or administrative access to a device may be able to leverage WinRE-related boot mechanisms to circumvent firmware protections and gain unauthorized access to system resources.\r\n\r\n### Description\r\nMicrosoft Windows versions 10 and 11 include the WinRE capability, a recovery platform that supports features such as the *F11* recovery menu and the *Reset this PC* functionalities. WinRE is commonly used for system recovery, troubleshooting, and remote support scenarios.\r\n\r\nWhen WinRE is invoked, the system reboots into a recovery environment that may use an alternate boot path from the standard operating system startup sequence. Depending on the platform and firmware implementation, the alternate boot path may not consistently enforce the same UEFI/BIOS security controls that are applied during a normal boot process.\r\n\r\nA security concern has been [identified](https://beafn28.es/#/articulos/winre-uefi-bypass) in certain WinRE implementations where administrative UEFI/BIOS passwords may not be enforced during specific recovery operations. This inconsistency in the boot execution path may allow an attacker with physical access to a device to bypass firmware-level protections. Such scenarios are commonly associated with \"Evil Maid\" attacks, in which an attacker gains temporary physical access to an unattended system and modifies its boot configuration or security settings.\r\n\r\nIn UEFI-based systems, the UEFI boot manager supports the [BootNext](https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html) variable, which specifies a one-time boot target stored in non-volatile memory (NVRAM). The UEFI trust model assumes that only privileged software or the platform owner can modify NVRAM variables; however, the `BootNext` variable itself is not authenticated and takes precedence over the normal `BootOrder` configuration during the next boot cycle. When Secure Boot is enabled, firmware validates the integrity and signature of the boot application specified by `BootNext` before execution. The UEFI specification does not explicitly mandate a full platform reset when the `BootNext` variable is configured, leaving reset-handling and user authentication flows to the specific implementation. Consequently, the effectiveness of pre-boot security controls (such as UEFI/BIOS password protections and BitLocker full-disk encryption) can be bypassed via recovery environments like WinRE, provided a user has the privileges required to initiate such recovery.\r\n\r\nOrganizations with high security requirements for their devices should not rely solely on UEFI/BIOS passwords to protect systems where WinRE or such recovery environments are accessible to untrusted users. Additional controls should be implemented to protect against both physical-access and privileged-user attacks. \r\n\r\n### Impact\r\nAn attacker with access to the Windows Recovery Environment may be able to bypass administrator-configured UEFI/BIOS password protections on affected systems. Depending on the device configuration and firmware implementation, an attacker may also be able to perform actions that weaken or circumvent BitLocker full-disk encryption protections, potentially resulting in unauthorized access to sensitive data.\r\n\r\n### Solution\r\nMicrosoft has published [an advisory](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45585) related to recovery-environment hardening and secure boot configurations, including mitigations for vulnerabilities affecting WinRE mechanisms. Organizations should review applicable vendor guidance and evaluate whether their systems are susceptible to WinRE-based firmware security bypasses.\r\n\r\nIn addition to standard recommendations (e.g., enabling Secure Boot), the following mitigations are advised for highly sensitive systems: \r\n\r\n1. Disable or restrict WinRE on systems where recovery functionality is not operationally required.\r\n2. Require administrative authorization with ephemeral one-time access before enabling or invoking recovery environments.\r\n3. Enable BitLocker with TPM + PIN or TPM + Startup Key to ensure additional authentication is required during recovery and pre-boot scenarios.\r\n4. Enable restrictions of pluggable media with EFI System Partitions (ESP) and any modifications to sensitive items in UEFI NVRAM such as `BootNext` and `BootOrder`.\r\n5. Deploy endpoint detection and response (EDR) solutions or end-point restrictions that support pre-boot security along with remote attestation and measured boot technologies to detect or block unauthorized boot modifications.\r\n6. Implement physical security controls, including device locks, secure storage, tamper-evident protections, and chain-of-custody procedures for high-value systems.\r\n\r\nThese recommendations should be evaluated in accordance with organizational recovery requirements and operational constraints. Some of the recommendations were adapted from [Eclypsium research blog](https://eclypsium.com/blog/yellowkey-bitlocker-bypass-windows-recovery-environment/)\r\n\r\n### Acknowledgements\r\nThanks to Beatriz Fresno Naumova for reporting this vulnerability. This document was written by Vijay Sarvepalli.","clean_desc":null,"impact":null,"resolution":null,"workarounds":null,"sysaffected":null,"thanks":null,"author":null,"public":["https://en.wikipedia.org/wiki/Pre-boot_authentication","https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf","https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45585","https://eclypsium.com/blog/yellowkey-bitlocker-bypass-windows-recovery-environment/","https://learn.microsoft.com/en-us/azure/security/fundamentals/measured-boot-host-attestation","https://beafn28.es/articulos/winre-uefi-bypass"],"cveids":[],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-06-22T16:16:08.475697Z","publicdate":"2026-06-22T16:16:08.123393Z","datefirstpublished":"2026-06-22T16:16:08.496996Z","dateupdated":"2026-06-22T16:21:17.863868Z","revision":2,"vrda_d1_directreport":null,"vrda_d1_population":null,"vrda_d1_impact":null,"cam_widelyknown":null,"cam_exploitation":null,"cam_internetinfrastructure":null,"cam_population":null,"cam_impact":null,"cam_easeofexploitation":null,"cam_attackeraccessrequired":null,"cam_scorecurrent":null,"cam_scorecurrentwidelyknown":null,"cam_scorecurrentwidelyknownexploited":null,"ipprotocol":null,"cvss_accessvector":null,"cvss_accesscomplexity":null,"cvss_authentication":null,"cvss_confidentialityimpact":null,"cvss_integrityimpact":null,"cvss_availabilityimpact":null,"cvss_exploitablity":null,"cvss_remediationlevel":null,"cvss_reportconfidence":null,"cvss_collateraldamagepotential":null,"cvss_targetdistribution":null,"cvss_securityrequirementscr":null,"cvss_securityrequirementsir":null,"cvss_securityrequirementsar":null,"cvss_basescore":null,"cvss_basevector":null,"cvss_temporalscore":null,"cvss_environmentalscore":null,"cvss_environmentalvector":null,"metric":null,"vulnote":208}