Researchers find hidden backdoor in PC firmware that bypasses Secure Boot

Attackers can bypass Secure Boot by spawning the UEFI Shell, a command-line utility built directly into firmware for debugging or repair. Several vendors, including AMI, Gigabyte, Insyde Software, and Cisco, have acknowledged the vulnerability, with many more likely affected.

UEFI Secure Boot is supposed to ensure that the computer loads only trusted, digitally signed software during boot, such as bootloaders and the operating system kernel.

However, researchers have disclosed a way that privileged attackers can bypass this security feature.

SPI Flash, a memory module that stores the system’s UEFI (Unified Extensible Firmware Interface) firmware, often has a UEFI Shell module embedded. It’s a standalone command-line interface that lets you interact directly with the UEFI environment.

This utility was implemented for debugging, diagnostics, and advanced platform management, but many OEMs and independent BIOS vendors ship it in production firmware.

“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,” reads the advisory by the CERT Coordination Center (CERT/CC) within Carnegie Mellon University.

Many firmware implementations include a boot entry for the UEFI Shell. Normally, it isn’t easily accessible – vendors remove or suppress this entry when Secure Boot is enabled.

However, due to a severe vulnerability, attackers can craft UEFI boot entries that still get the shell to run.

“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,” reads the advisory.

With access to the UEFI shell, the attacker can mess with the pre-boot environment however they like, including overwriting Secure Boot-related memory values, and running unauthorized code during the early boot process.

“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,” warns CERT/CC.

This malicious activity can be invisible to OS-based security controls and endpoint detection and response (EDR) software.

This vulnerability affects multiple vendors in the entire firmware supply chain.

AMI (American Megatrends Incorporated), Gigabyte, Insyde, and Cisco (in UCS servers) have already confirmed some flavor of the bug.

A vulnerability in AMI’s flagship Aptio V UEFI firmware, tracked as CVE-2026-33197, is rated 8.7 out of 10 – high severity.

Successful exploitation of this vulnerability may lead to arbitrary code execution and impact system Confidentiality, Integrity, and Availability,

AMI said.

Cisco UCS Servers and UCS-based appliances are also affected by a variation of this UEFI Shell issue. The vendor has assigned CVE-2026-20293, which has a severity score of 7.1 out of 10.

Cisco also released an advisory warning that a physical unauthenticated attacker, or an authenticated attacker with valid credentials for a user account with the user or admin role, can bypass UEFI Secure Boot validation and execute unauthorized software on affected devices. Software updates are available.

Gigabyte uses AMI’s firmware, confirmed it is affected, and released BIOS updates to the public before July 14th, 2026.

Insyde Software, a global low-level computer firmware developer, said that only a subset of customers “have chosen to include shell for their own reasons and may be affected. Most customers don’t ship the shell.

Intel and Phoenix Technologies said they’re not affected.

However, a long list of major names, including Dell, HP, Lenovo, Microsoft, Asus, Supermicro, and others, are listed as “unknown,” meaning CERT/CC hasn’t received any statement.

In any case, it’s recommended to apply the latest firmware updates.

“Please 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,” CERT/CC said.

Organizations are also recommended to review their Secure Boot configurations and platform security policies to prevent any unauthorized modifications to UEFI boot entries.