CISA issues guidance on UEFI Shell Secure Boot bypass
46th article in the last 90 days, one of 600 articles referencing Cybersecurity and Infrastructure Security Agency (CISA). Previous coverage: CISA advises on Casdoor authorization bypass affecting versions 3.115.0 (Sep 2026).
Companies mentioned
Best suited for
- Job function
- Chief Information Security Officer
- Seniority
- C Level / Executive Team
- Persona
- Security Operations Leader
- Buyer role
- Decision Maker / Budget Holder
- Buyer journey
- Need to Buy
- Adoption curve
- Early Majority
- Technology maturity
- Market Correction
- Industry
- Information Technology / Software & Services / Cybersecurity / Governance, Risk & Compliance (GRC) & Security Ratings
Our classification, not the publisher's statement. Best suited for, not only for.
Several CVEs describe a vulnerability involving the UEFI Shell when it is embedded in SPI flash on affected platforms, where the flaw can enable bypass of UEFI Secure Boot protections. By creating additional UEFI boot option entries, an attacker may reference and run the UEFI Shell even when standard controls are intended to prevent it under Secure Boot, enabling pre-boot modification and execution of unauthorized software during system startup.
The UEFI Shell embedded in SPI flash can provide command-line utilities and powerful memory access commands, including dmem (display memory) and mm (memory modify), that can access physical memory. The issue is associated with CVE-2026-33197, CVE-2026-6485, and CVE-2026-20293. The described technique requires the ability to create additional UEFI boot entries that reference the UEFI Shell despite controls intended to prevent its execution while Secure Boot is enabled. With the UEFI Shell and its startup scripting capabilities, an attacker may modify the pre-boot environment, including overwriting Secure Boot-related memory values, and execute unauthorized code during the early boot process.
An attacker capable of modifying UEFI boot entries may 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.
Please see the Vendor Information section for responses from vendors that have released updates addressing this issue. The guidance also states that updating UEFI firmware may require OEM-specific tools and deployment processes, and that platform-vendor instructions should be followed when applying firmware updates.
Rewrite Secure Boot configuration and platform security policies so they help prevent or detect unauthorized modifications to UEFI boot entries, and monitor and audit changes to boot configuration where possible. The advisory also says 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. Eclypsium researcher Stas Lyakhov is credited with reporting the vulnerability.
Blog post, originally published by Vijay Sarvepalli at kb.cert.org.