{"document":{"acknowledgments":[{"urls":["https://kb.cert.org/vuls/id/226679#acknowledgements"]}],"category":"CERT/CC Vulnerability Note","csaf_version":"2.0","notes":[{"category":"summary","text":"### 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.","title":"Summary"},{"category":"legal_disclaimer","text":"THIS DOCUMENT IS PROVIDED ON AN 'AS IS' BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. ","title":"Legal Disclaimer"},{"category":"other","text":"CERT/CC Vulnerability Note is a limited advisory. It primarily identifies vendors impacted by the advisory and not specific products. We only support \"known_affected\" and \"known_not_affected\" status. Please consult the vendor's statements and advisory URL if provided by the vendor for more details ","title":"Limitations of Advisory"},{"category":"other","text":"does not apply to Supermicro's products","title":"Vendor statment from Supermicro"},{"category":"other","text":"AMI implementation enforces bios password authentication in all cases including when WinRE in leverage to enter the BIOS setup.","title":"Vendor statment from American Megatrends Incorporated (AMI)"},{"category":"other","text":"GIGABYTE has evaluated the report regarding the UEFI administrator password bypass via the Windows Recovery Environment (WinRE) \"Use a device\" functionality.\r\n\r\nWe have confirmed that this behavior is consistent with the current industry-standard UEFI trust model, where the firmware trusts boot requests (such as BootNext) initiated by a running, trusted operating system.\r\nThis is a platform security design trade-off inherent in the interaction between the UEFI specification and the OS recovery environment, rather than a specific implementation defect in GIGABYTE firmware.\r\n\r\nTo mitigate the risk of unauthorized external booting, GIGABYTE recommends that enterprise users implement a defense-in-depth strategy,\r\nincluding the enablement of full-disk encryption (e.g., **BitLocker with TPM+PIN**) and the restriction of access to WinRE advanced options where appropriate.","title":"Vendor statment from GIGABYTE"}],"publisher":{"category":"coordinator","contact_details":"Email: cert@cert.org, Phone: +1412 268 5800","issuing_authority":"CERT/CC under DHS/CISA https://www.cisa.gov/cybersecurity also see https://kb.cert.org/ ","name":"CERT/CC","namespace":"https://kb.cert.org/"},"references":[{"url":"https://certcc.github.io/certcc_disclosure_policy","summary":"CERT/CC vulnerability disclosure policy"},{"summary":"CERT/CC document released","category":"self","url":"https://kb.cert.org/vuls/id/226679"},{"url":"https://en.wikipedia.org/wiki/Pre-boot_authentication","summary":"https://en.wikipedia.org/wiki/Pre-boot_authentication"},{"url":"https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf","summary":"https://www.nsa.gov/portals/75/documents/what-we-do/cybersecurity/professional-resources/csi-uefi-lockdown.pdf"},{"url":"https://eclypsium.com/blog/yellowkey-bitlocker-bypass-windows-recovery-environment/","summary":"https://eclypsium.com/blog/yellowkey-bitlocker-bypass-windows-recovery-environment/"},{"url":"https://learn.microsoft.com/en-us/azure/security/fundamentals/measured-boot-host-attestation","summary":"https://learn.microsoft.com/en-us/azure/security/fundamentals/measured-boot-host-attestation"},{"url":"https://beafn28.es/articulos/winre-uefi-bypass","summary":"https://beafn28.es/articulos/winre-uefi-bypass"}],"title":"Microsoft WinRE allows for bypass of UEFI/BIOS password enforcement","tracking":{"current_release_date":"2026-06-22T16:21:17+00:00","generator":{"engine":{"name":"VINCE","version":"3.0.42"}},"id":"VU#226679","initial_release_date":"2026-06-22 16:16:08.123393+00:00","revision_history":[{"date":"2026-06-22T16:21:17+00:00","number":"1.20260622162117.2","summary":"Released on 2026-06-22T16:21:17+00:00"}],"status":"final","version":"1.20260622162117.2"}},"vulnerabilities":[{"title":"A vulnerability in certain OEM firmware implementations allows the BIOS/UEFI password to be bypassed during OS-initiated warm reboots into the Windows Recovery Environment.","notes":[{"category":"summary","text":"A vulnerability in certain OEM firmware implementations allows the BIOS/UEFI password to be bypassed during OS-initiated warm reboots into the Windows Recovery Environment. An authenticated local attacker may be able to boot from alternate media or access the system thus bypassing the BIOS password enforcement."}],"ids":[{"system_name":"CERT/CC V Identifier ","text":"VU#226679"}],"product_status":{"known_affected":["CSAFPID-d5a0af28-6e82-11f1-8284-1253c57fa98d"],"known_not_affected":["CSAFPID-d59fd8e6-6e82-11f1-8284-1253c57fa98d","CSAFPID-d5a0175c-6e82-11f1-8284-1253c57fa98d","CSAFPID-d5a049de-6e82-11f1-8284-1253c57fa98d","CSAFPID-d5a07be8-6e82-11f1-8284-1253c57fa98d"]}}],"product_tree":{"branches":[{"category":"vendor","name":"Supermicro","product":{"name":"Supermicro Products","product_id":"CSAFPID-d59fd8e6-6e82-11f1-8284-1253c57fa98d"}},{"category":"vendor","name":"American Megatrends Incorporated (AMI)","product":{"name":"American Megatrends Incorporated (AMI) Products","product_id":"CSAFPID-d5a0175c-6e82-11f1-8284-1253c57fa98d"}},{"category":"vendor","name":"Intel","product":{"name":"Intel Products","product_id":"CSAFPID-d5a049de-6e82-11f1-8284-1253c57fa98d"}},{"category":"vendor","name":"Insyde Software Corporation","product":{"name":"Insyde Software Corporation Products","product_id":"CSAFPID-d5a07be8-6e82-11f1-8284-1253c57fa98d"}},{"category":"vendor","name":"GIGABYTE","product":{"name":"GIGABYTE Products","product_id":"CSAFPID-d5a0af28-6e82-11f1-8284-1253c57fa98d"}}]}}