Vulnerable shim bootloaders enable Secure Boot bypass
Multiple Microsoft-signed UEFI shim bootloaders from version 0.9 and earlier contain vulnerabilities allowing Secure Boot bypass and pre-OS code execution via BYOVD techniques.
Sourcekb.cert.org — open the original
What to check
- Applies to
- The 1 CVE named below. Whether you run an affected version is not assessed: check the versions the source lists.
- Exploitation
- No exploitation in the wild and no public exploit is recorded for the CVEs named.
ESET researchers identified multiple vulnerable Microsoft-signed UEFI bootloaders from the open-source shim project, primarily affecting version 0.9 and earlier releases. These bootloaders, which serve as a bridge between UEFI firmware and Linux distributions, contain security vulnerabilities that allow attackers with administrative privileges to bypass Secure Boot protections. The vulnerabilities stem from vendors forking or customizing older shim versions that were never updated after upstream security fixes were released, creating a supply chain exposure where vulnerable components remained trusted by Secure Boot systems.
An attacker exploiting these vulnerabilities using Bring Your Own Vulnerable Driver (BYOVD)-style techniques can execute arbitrary code during the early boot phase, before operating system initialization. This enables persistent platform compromise, including the ability to load unsigned or malicious kernel components that survive reboots and OS reinstallation while evading detection by endpoint security solutions. Microsoft will add the affected bootloaders to the UEFI Forbidden Signature Database (DBX) as part of coordinated disclosure.
Organizations should apply the latest software updates, bootloader updates, and Microsoft DBX updates to all UEFI-based systems. Enterprises are advised to update the authorized signature database (DB) before applying DBX revocations to prevent boot failures. Audit tools such as Check-UEFISecureBootVariables for Windows and uefi-dbx-audit for Linux can help verify DBX updates and identify vulnerable boot components.
Mentioned in this report
Detection guidance
Bcdedit Used to Disable Driver Signature Enforcement or Test Signing
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
Detects bcdedit.exe invocations disabling code integrity/test signing, a common precursor to loading unsigned kernel components after a Secure Boot bypass via vulnerable bootloaders. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: Bcdedit Disables Driver Signature Enforcement or Test Signing
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: \bcdedit.exe
CommandLine|contains:
- nointegritychecks
- testsigning
- loadoptions DISABLE_INTEGRITY_CHECKS
filter_common:
CommandLine|contains:
- /enum
- /export
condition: selection and not filter_common
falsepositives:
- Legitimate kernel driver development or debugging workstations enabling test signing
- IT staff troubleshooting boot configuration on non-production systems
level: high
tags:
- attack.t1542.001
- attack.t1068
id: ea6cf8a2-c897-5d93-85a0-33593f057ae7
status: experimental
author: Vorant
EFI System Partition Mounted via Mountvol for Direct Access
A behavioural hunt for the technique in general, not a signature for the CVEs this report names.
Detects use of mountvol.exe to assign a drive letter to the hidden EFI System Partition, a step attackers use to directly read or write bootloader files such as vulnerable or replaced shim binaries. Auto-generated starting point — validate and tune in your environment before deploying. IOC matches can false-positive on shared infrastructure and decay as adversary infrastructure rotates.
title: EFI System Partition Mounted via Mountvol
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: \mountvol.exe
CommandLine|contains: /s
condition: selection
falsepositives:
- System administrators or imaging tools legitimately mounting the ESP for boot repair
or bootloader updates
- Backup and disk management software that mounts the ESP during maintenance windows
level: medium
tags:
- attack.t1542.001
- attack.t1068
id: 39a9aefa-ad0e-5690-ac45-48e6a3690f5e
status: experimental
author: Vorant
Behavioural rules are generated from public reporting — validate in your environment before deploying.
Source reporting: https://kb.cert.org/vuls/id/616257
Free public brief. The indicators and the detections with Splunk SPL already written (plus Elastic and KQL where they apply) are in the app with a free account, no card. Slack alerts on the vendors you run come with the paid plans, and a new account gets three days of them.
What this brief leaves out
This page is the free tier: the write-up, the severity, the names. In the app the same report carries its extracted indicators, its detections (Splunk SPL already written, plus Elastic and Microsoft KQL where they apply), and live profiles of the CVEs it names. The paid plans add the security research and news reporting the free tier leaves out.
It sits in a corpus of 16,433 reports from 149 sources, 661 of them written in the last seven days, and it grows through the day.
A new account starts with three days of all of it, no card, then keeps the government and CERT reporting free. Slack alerts are a paid-plan feature: name the vendors you run and Slack hears about the reports that touch them, not the rest of the week's. Nothing is charged unless you subscribe.
Create a free account What it costs