A trusted, vendor-signed UEFI shell can disable Secure Boot enforcement and load unsigned pre-OS code.
The firmware can continue to report Secure Boot enabled after the handler is overwritten.
Affects
Vendor-signed UEFI Shell applications used by Acer, Dell, Eurosoft, Framework, Getac, Lenovo, MinisForum, MSI, Seagate, Uniwill, and unidentified OEMs on UEFI systems.
What it enables
Secure Boot bypass and persistent pre-OS code execution
Obtain physical access or equivalent administrative control over boot files and configuration→↓Place or select a vendor-signed UEFI Shell accepted by the target's Authorized Signature Database→↓Use the shell's memory-modification command to overwrite the Secure Boot security-handler pointer→↓Load unsigned UEFI code or kernel components while firmware still reports Secure Boot enabled→↓Run before operating-system and EDR initialization and optionally establish firmware-level persistence→↓The complete set of trusted certificates, vulnerable shell hashes, affected device models and deployed DBX revocations is not yet public.
Research leadEnumerate the certificates and Authenticode hashes covered by VU#738147, then compare them with OEM firmware DB and DBX contents and shipped revocation updates.
Why this matters
The bypass comes from code already accepted by the platform trust database, making signature trust the route around the control it is meant to enforce.
Detail and 4 sources
Required access
Physical access to the device, or administrative control sufficient to stage and boot a shell trusted by the platform UEFI DB
Affected versions
Systems whose UEFI DB trusts an affected vendor certificate or the Authenticode hash of an affected UEFI Shell, UEFI Shell binaries listed by CERT/CC for Acer, Dell, Eurosoft, Framework, Getac, Lenovo, MinisForum, MSI, Seagate, and Uniwill, Three additional unidentified UEFI Shell binaries listed by SHA-256 in VU#738147
Proof of concept
Demonstrated by the researcher
With physical access—or administrative control sufficient to stage and boot an accepted shell—an attacker can use the shell's memory-write command to overwrite the Secure Boot security-handler pointer.
Unsigned UEFI or kernel code can then run before operating-system and EDR initialization, with firmware still reporting Secure Boot enabled and firmware-level persistence possible.
The response is incomplete: pre-fix images remain accepted, revocation is not complete, and we still do not know the full certificate, hash and device population or whether remediation reaches end-of-life hardware.
Evidence
CERT/CC confirms that trusted shells with direct memory access can bypass Secure Boot and execute untrusted pre-boot codeEclypsium demonstrated overwriting the UEFI security handler and loading unsigned codeExact cross-vendor affected and revoked population
The same brief, every morning. One email a day, nothing else.
Every finding here carries a source that was checked before it published. If something is wrong, write to admin@fullchain.sh — corrections are published on the day they affect.