Secure Boot Can Be Bypassed From UEFI Shell. The OS Never Gets a Chance

• The Mess: A flaw in how firmware handles embedded UEFI Shell boot entries can expose a path around Secure Boot. The same weakness now spans AMI, Insyde and Cisco UCS implementations.
• The Damage: An attacker with sufficient local or physical access can reach the pre-boot environment, alter memory and execute unauthorized code before Windows or Linux starts.
• The Fix: Patch the system firmware, audit UEFI boot entries and disable unnecessary UEFI Shell functionality.

Secure Boot is supposed to be the bouncer at the door.

This time, the bouncer can be sent home before the party starts.

CERT/CC published VU#718077 on September 8, describing a weakness involving UEFI Shell modules embedded in SPI flash. The issue affects firmware implementations that include the shell while relying on boot-option handling to keep it unavailable when Secure Boot is enabled.

The underlying problem is surprisingly mundane.

The firmware removes a UEFI Shell boot option when Secure Boot is enabled.

But some implementations do not reliably remove every duplicate entry.

An attacker who can manipulate UEFI boot configuration can create additional boot entries pointing to the shell and get it running anyway.

Once the shell is alive, Secure Boot has a much bigger problem.

The Shell Has Memory Access

UEFI Shell isn’t a harmless command prompt.

It is a pre-OS management environment designed for diagnostics and firmware-level operations.

Among its commands are dmem and mm.

The latter can modify physical memory.

That is exactly the sort of capability you do not want sitting behind a broken Secure Boot boundary.

CERT/CC says an attacker who reaches the shell can manipulate the pre-boot environment, including Secure Boot-related memory values, and execute unauthorized software before the operating system loads.

At that point, Windows Defender has nothing to defend.

Neither does Linux.

The operating system has not started yet.

Three CVEs, One Ugly Pattern

The vulnerability is being tracked under several CVE identifiers depending on the firmware implementation.

CVE-2026-33197 affects the AMI Aptio UEFI BDS module used by GIGABYTE systems. GIGABYTE rates it CVSS 8.7 and describes a logic error in removal of embedded UEFI Shell boot options. The attack requires existing administrative/root privileges on the operating system.

CVE-2026-6485 covers the Insyde implementation. Insyde rates it CVSS 8.2 and says only a subset of systems are affected because many platforms do not place the UEFI Shell in firmware areas that can execute under Secure Boot.

Cisco has a separate variant:

CVE-2026-20293 affects Cisco UCS servers and UCS-based appliances. Cisco rates it High and has released firmware updates. An authenticated attacker with a user or admin account can exploit the issue; an attacker with physical access can also reach the affected path without authentication.

So this isn’t one broken motherboard.

It’s a class of firmware implementations sharing the same dangerous assumption.

The Attack Happens Before the OS

This is what makes the vulnerability particularly nasty.

A conventional Windows exploit has to get through the operating system.

A kernel exploit has to defeat kernel protections.

An EDR bypass still has an EDR running somewhere in the chain.

A pre-boot compromise can operate underneath all of that.

CERT/CC warns that successful exploitation can establish persistence capable of surviving system reboots and, in some cases, operating-system reinstallation. It can also reduce the visibility available to OS-level EDR products.

Reinstall Windows?

The malicious boot component can still be there.

Reset the OS?

Same problem.

The firmware and boot chain are a different security layer.

This Isn’t Just Theoretical UEFI Research

Eclypsium has previously demonstrated why signed UEFI Shell components are dangerous. The shell’s memory manipulation capabilities can be used to interfere with the mechanisms responsible for Secure Boot validation, including by modifying security-related memory structures.

That research also showed why a signed shell is not automatically safe.

The firmware trusts it.

The shell then gets access to hardware and memory at a point where normal operating-system protections don’t exist.

A legitimate diagnostic tool can therefore become an extremely privileged attack primitive when the boot chain exposes it incorrectly.

The Firmware Supply Chain Is The Real Problem

CERT/CC lists AMI, GIGABYTE, Insyde and Cisco among vendors with affected implementations or variants. Other vendors remain listed as unknown, meaning administrators cannot safely assume that an unlisted motherboard or server is unaffected without checking with the platform manufacturer.

That’s a firmware inventory problem.

Most organizations are very good at tracking Windows versions.

Far fewer maintain an equally precise inventory of:

• BIOS/UEFI versions;
• firmware vendors;
• embedded UEFI modules;
• boot entries;
• Secure Boot state;
• vendor-specific firmware configuration.

Attackers don’t care which dashboard your IT team uses.

If the firmware is vulnerable, the firmware is vulnerable.

What Defenders Should Check

Start with the firmware inventory.

Check:

• BIOS/UEFI vendor and version;
• whether Secure Boot is enabled;
• whether UEFI Shell is embedded or exposed as a boot option;
• unexpected or duplicate UEFI boot entries;
• recent changes to EFI variables;
• firmware updates supplied by the OEM;
• server platforms using AMI or Insyde firmware;
• Cisco UCS systems covered by CVE-2026-20293.

CERT/CC specifically recommends monitoring and auditing changes to UEFI boot configuration. Firmware updates need to come from the platform vendor because they are normally outside ordinary operating-system patch management.

For GIGABYTE systems affected by CVE-2026-33197, the company says it integrated the AMI fix into its BIOS build pipeline and planned BIOS updates for affected products.

Secure Boot Can Still Say “Enabled”

That’s perhaps the nastiest operational detail.

An administrator may look at Windows and see Secure Boot enabled.

The machine may still boot normally.

Nothing necessarily looks broken.

The attacker doesn’t need to disable the feature in a way that immediately triggers an alert.

The goal is to manipulate the environment in which Secure Boot performs its checks.

The control can remain visible while the trust boundary underneath it has already been compromised.

Bugstoday Opinion

Secure Boot is powerful because it moves trust below the operating system.

That also means firmware bugs move the battlefield below the operating system.

VU#718077 is a good reminder that “Secure Boot enabled” is not the same thing as “the boot chain is trustworthy.”

The attack still requires significant privileges or physical access on many affected platforms. This isn’t a drive-by exploit that compromises random Windows laptops over the Internet.

But once an attacker already has the required foothold, breaking Secure Boot changes the game completely.

The operating system isn’t the final security boundary anymore.

The firmware is.

And firmware deserves the same patch discipline as everything running above it.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

CERT/CC — VU#718077
GIGABYTE — CVE-2026-33197 Security Advisory
Cisco — CVE-2026-20293 Security Advisory
Insyde Software — CVE-2026-6485 Security Advisory
Eclypsium — UEFI Shell / Secure Boot research