{"vuid":"VU#718077","idnumber":"718077","name":"UEFI Shell module embedded in SPI Flash can be used to bypass Secure Boot","keywords":null,"overview":"### Overview\r\nThe UEFI Shell program may expose raw memory access capabilities that, if present in platform firmware for debugging or advanced support use cases, could be abused to undermine UEFI Secure Boot protections. When the UEFI Shell is included in SPI flash, an attacker with the ability to modify UEFI boot configuration may be able to create multiple boot option entries and bypass controls intended to prevent the UEFI Shell from launching while Secure Boot is enabled. This could allow an attacker to modify the pre-boot environment and execute unauthorized software during system startup.\r\n\r\n### Description\r\nThe [Unified Extensible Firmware Interface](https://uefi.org) (UEFI) is a firmware specification that defines the interface between a computing platform's hardware and operating system (OS) during the early boot process before the operating system is loaded. UEFI Secure Boot helps ensure that only trusted and digitally signed software is executed during these early stages of platform initialization. \r\n\r\nThe [TianoCore EDK II](https://github.com/tianocore/edk2) project provides an open-source reference implementation of the UEFI and Platform Initialization (PI) specifications. The project includes the [UEFI Shell](https://uefi.org/sites/default/files/resources/UEFI_Shell_Spec_2_0.pdf), which provides command-line utilities for debugging, diagnostics, and advanced platform management. Many OEM and Independent BIOS Vendor (IBV) firmware implementations include the UEFI Shell in SPI flash for service and support purposes. Because the shell executes in the pre-boot environment, it provides powerful commands such as `dmem` (display memory) and `mm` (memory modify) that can access physical memory. Many implementations include a boot entry for the UEFI Shell but remove or suppress it when Secure Boot is enabled to reduce the risk of misuse.\r\n\r\nA vulnerability disclosed by Eclypsium researcher Stas Lyakhov details a technique in which an attacker with the ability to create additional UEFI boot entries can reference the UEFI Shell even when standard controls are implemented to prevent its execution. An attacker could then exploit the UEFI Shell and its startup scripting capabilities to modify the pre-boot environment, including overwriting Secure Boot-related memory values, and execute unauthorized code during the early boot process.\r\n\r\n### Impact\r\nAn attacker capable of modifying UEFI boot entries may be able to circumvent intended Secure Boot protections and execute arbitrary code before the operating system loads. Code executed during the pre-boot phase may establish persistent access, including the ability to load malicious boot components or kernel-level software that can survive both system reboots and, in some cases, reinstallation of the operating system. Such activity may also reduce the effectiveness of OS-based security controls and endpoint detection and response (EDR) solutions.\r\n\r\n### Solution\r\n#### Apply a Patch\r\nPlease see the Vendor Information section for responses from vendors that have released updates addressing this issue. Updating UEFI firmware may require OEM-specific tools and deployment processes, as firmware updates are often managed separately from operating system patch management. Follow the guidance provided by your platform vendor when applying firmware updates.\r\n\r\n#### Recommendations for Enterprises \r\nOrganizations should review Secure Boot configuration and platform security policies to help prevent or detect unauthorized modifications to UEFI boot entries. Changes to boot configuration should be monitored and audited where possible. Enterprises that use independent endpoint management solutions should consult their OEM vendors for guidance on integrating UEFI firmware updates into their existing firmware lifecycle and patch management processes.\r\n\r\n### Acknowledgements\r\nThanks to Stas Lyakhov from Eclypsium 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://www.uefi.org/","https://uefi.org/sites/default/files/resources/UEFI_Shell_Spec_2_0.pdf","https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/"],"cveids":["CVE-2026-20293","CVE-2026-6485","CVE-2026-33197"],"certadvisory":null,"uscerttechnicalalert":null,"datecreated":"2026-09-08T15:05:58.332417Z","publicdate":"2026-09-08T15:05:58.068772Z","datefirstpublished":"2026-09-08T15:05:58.342563Z","dateupdated":"2026-09-08T15:05:58.068768Z","revision":1,"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":243}