CERT/CC has published vulnerability VU#718077, which describes a way to bypass UEFI Secure Boot via a UEFI Shell embedded in the platform’s SPI flash memory. An attacker who is able to create additional UEFI boot entries can launch the UEFI Shell even when Secure Boot is enabled and use its direct memory access commands to modify the pre-boot environment and execute arbitrary code before the operating system starts. The issue affects products from several vendors — Cisco, AMI (GIGABYTE) and Insyde — and requires a firmware update from the specific platform manufacturer.
Essence of the vulnerability and attack mechanism
UEFI Shell is a command shell that is part of the UEFI specification and implemented in the TianoCore EDK II project. Many OEMs and independent BIOS vendors (IBV) include the UEFI Shell in SPI flash for service and diagnostic purposes. The shell provides the dmem (memory read) and mm (memory modification) commands, which give direct access to the system’s physical memory at the pre-OS stage.
The standard protection approach is to delete or suppress the UEFI Shell boot entry when Secure Boot is active. However, researcher Stas Lyakhov from Eclypsium discovered that an attacker who can create additional UEFI boot entries can bypass this control by creating redundant entries that point to the embedded shell. After launching the UEFI Shell, the attacker can use its scripting capabilities (auto-start scripts) and memory modification commands to overwrite values related to Secure Boot and execute unauthorized code.
Affected products and CVEs
The vulnerability spans several vendor implementations, each of which has received its own CVE identifier. This is not a single universal problem but a set of configuration-dependent vulnerabilities:
- CVE-2026-20293 — according to CERT/CC, affects Cisco UCS servers and UCS-based appliances. Cisco has published a separate security advisory. We have previously written about vulnerabilities in Cisco products.
- CVE-2026-33197 — according to a statement by GIGABYTE via CERT/CC, is related to a logical error in the AMI Aptio UEFI BDS module. A flaw in the process of deleting the Shell boot entry makes it possible to create duplicate entries, bypassing the Secure Boot check and gaining access to arbitrary reading and writing of physical memory.
- CVE-2026-6485 — according to Insyde, most systems with Insyde BIOS are not affected. Only configurations in which the UEFI Shell is included in system code areas approved for execution when Secure Boot is active are vulnerable. Insyde rates this vulnerability at 8.2 on the CVSS scale. This score applies exclusively to CVE-2026-6485 and should not be extended to other CVEs or to the umbrella advisory VU#718077.
The key condition for exploitation is that the UEFI Shell must be physically present in the firmware or in an approved system code area, and the attacker must be able to modify UEFI boot entries. The mere fact that Secure Boot is enabled is not sufficient protection if these conditions are met.
Impact of exploitation
Code executed at the pre-boot stage runs before the operating system and its security mechanisms are initialized. According to CERT/CC, successful exploitation can lead to:
- Loading malicious kernel-level components that survive a reboot and, in some cases, an OS reinstallation
- Reducing the effectiveness of OS-level security tools, including EDR-class solutions
- Establishing persistent access to the system by modifying the pre-boot environment
As of the time of publication, none of the sources considered has confirmed active exploitation of VU#718077 in real-world attacks.
Mitigation recommendations
Eliminating the vulnerability requires a UEFI firmware update from the specific platform manufacturer. This is not a standard OS update — the process may require OEM-specific tools and separate deployment procedures. CERT/CC recommends:
- Apply firmware updates from the platform vendor, following their deployment instructions
- Perform an inventory — determine whether UEFI Shell is present in your systems’ firmware. The presence of the embedded shell is a necessary condition for exploitation
- Configure monitoring of UEFI boot entries — track and audit changes in the boot configuration wherever technically possible
- Review Secure Boot policies — ensure the platform configuration does not allow unauthorized creation of boot entries
An enabled Secure Boot indicator by itself does not guarantee protection against this vulnerability. Priority should be given to checking for the presence of UEFI Shell in the firmware and controlling boot entries. Organizations using Cisco UCS servers, platforms based on AMI Aptio, or systems with Insyde BIOS should contact the respective vendors for firmware updates and integrate them into their existing firmware lifecycle management processes.
