~/news/2026-09-08-uefi-shell-secure-boot-bypass.md

What happened. CERT/CC published VU#718077 on 2026-09-08, covering UEFI Shell modules that board vendors leave inside SPI flash. Three identifiers: CVE-2026-33197 for the AMI AptioV BDS module, CVE-2026-6485 for Insyde BIOS, and CVE-2026-20293, which Cisco assigned for UCS servers and the appliances built on them. Dell, HP, Lenovo, Microsoft, Supermicro and Acer are listed as unknown: they have not answered.

Why it matters. The vendor table is the story. Vendors were notified on 2026-04-08; five months later two had said not affected, four had confirmed, and most of the industry had not answered. Nobody patches this layer, and CERT/CC notes a foothold here survives reboots and, in some cases, reinstalling the operating system. Cisco rates the attack as reachable by an authenticated user account or by physical access, while GIGABYTE's statement asks for host root. One flaw class, two different bars.

Mechanism. The shell is a legitimate debugging tool, and it carries dmem and mm, which read and write physical memory. So firmware suppresses the shell's boot entry while Secure Boot is on. The suppression removes an entry; it does not reliably remove several. Anyone able to add boot entries creates duplicates pointing at the same shell binary, the cleanup misses some, the shell starts under Secure Boot, and a startup script uses mm to overwrite the memory values Secure Boot is enforced from. No corruption bug, just a list that was not fully walked.

What to do. Take BIOS from your OEM. This ships in the firmware image and no operating system patch reaches it; Cisco states there is no workaround. Then read the boot configuration instead of merely cleaning it. The fix corrects how entries are removed, not what a shell already did with one, and nothing above the firmware can see that. Audit boot entries and Secure Boot variables as evidence, and treat the reinstall you would normally reach for as not a clean boundary here.