Skip to finding
§
High
Boot chain
Confirmed

Thirty trusted UEFI shells now have published hashes for a Secure Boot bypass.

Physical access or equivalent administrative control is still required, but the signed shell is accepted before it turns off enforcement for an unsigned payload.

Affects

UEFI PCs and servers whose Authorized Signature Database trusts one of 30 identified shell binaries or its signing certificate.

What it enables

Secure Boot bypass and persistent execution of unsigned pre-OS code

Attacker with physical access or equivalent administrative control places an identified signed UEFI shell, startup.nsh, and an unsigned payload on boot-accessible storage.→↓The platform accepts the shell because its vendor certificate or Authenticode hash is present in the UEFI Authorized Signature Database.→↓startup.nsh invokes the shell's memory-modification capability to overwrite the Security Architectural Protocol state used by LoadImage.→↓The modified verifier accepts and executes the unsigned UEFI payload before the operating system and endpoint controls start.→↓The payload can load unsigned kernel components or establish persistent platform compromise while Secure Boot still appears enabled.
Why this matters

The 30-binary inventory turns a known bypass class into something fleets can search for, while revocation remains incomplete and pre-remediation images can still be accepted.

Detail and 3 sources
Required access

Physical access, or administrative control sufficient to place a listed shell and startup.nsh on boot media and select or create its UEFI boot entry

Proof of concept

Demonstrated by the researcher

An attacker places a listed shell, startup.nsh, and an unsigned payload on boot-accessible storage. The trusted shell runs the script, which overwrites the Security Architectural Protocol state checked by LoadImage and causes the payload to execute before operating-system defenses start.

This is not a completed revocation event: older images remain usable, revocation coverage is incomplete, and we do not know whether remediation reaches end-of-life hardware.

Evidence
CERT/CC public table naming all 30 binaries with Authenticode and SHA-256 hashesResearcher demonstration of mm-based gSecurity2 overwrite and unsigned UEFI payload loadingFramework model-specific limited-shell and DBX remediation table
Share this finding
Get it by email

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.

Sunday, September 27, 2026