14 minhigh
Forgotten UEFI shims undermining Secure Boot
ESET researchers identified 11 old, Microsoft-signed UEFI shim bootloaders (version 0.9 and below) that can bypass UEFI Secure Boot on any system trusting Microsoft's third-party UEFI CA 2011 certificate. The old shims lack modern security features (MokListX enforcement, SBAT) and contain known vulnerabilities (CVE-2026-10797) that enable revocation bypass, allowing attackers to execute untrusted code during boot and deploy UEFI bootkits. Exploitation does not require the affected software to be installed — attackers can bring their own copy of the vulnerable shim to any UEFI system with the Microsoft third-party certificate enrolled.
Sens:▲ 24hConf:
Showing defanged values
- sha256236a9cb0d71951c36398a32eb660ce2cd4a52ccfa7cf751cc6a35d9de549e19bPE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha256410260b1b6f5af5fbeeb9ea3220658435e876cb3247126ee907a437f312db373PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha2565e594c448760a3135b1a3a83e07a4f2e6fbe49414ef2c7cab1cba77f284fa63bPE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha2567b2a3f5c96f95bd8086ce54b0825e300f9c8f11fe3401bb631b3215c8de9eb10PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha2568a964d5f8373948d20a1d4296fb92e545dad4617a0c810f3b934b53d98ae8963PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha25695b6d71fc0c0f8c5e1533a37aef92cf6b0c961e2cc612a97117fa6759ce5fc06PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha25696275dfd6282a522b011177ee049296952ac794832091f937fbbf92869028629PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha256a0de9333442c1bf9349a460141ae5e80f911955c6506040fa3d021bf6c1ae3e4PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha256ae75f0d82ba3df824fbfc69340cc3b4d66c598373b1ab54cdb6c8bfd83a6b961PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha256eb86fa1386fe6e4533b8b938dcc1250616d2f1c14c15e2fcf80834a161018a0aPE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- sha256fd23d6e57de6f4e1f9d7118da1c5f31a8af6be5e5d9e8170f9493447268d50c5PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
Detection / Hunteropenrouter
What Happened
Security researchers found 11 outdated bootloader programs that carry a valid digital signature from Microsoft, meaning they are trusted by most modern computers to run during startup. Attackers can use these old programs to bypass a key security feature called Secure Boot, which is supposed to prevent unauthorized software from running before the operating system starts. The attack works because these old programs predate security improvements and do not check for updated revocation lists. Anyone with a computer that uses UEFI Secure Boot and trusts Microsoft's third-party signing certificate (which includes most computers) could be affected. The main risk is that attackers could use this bypass to install deep-rooted malware (called a bootkit) that survives operating system reinstalls. Microsoft has already released a fix in their June 2026 updates, so users and IT administrators should ensure their systems are fully updated and verify that the fix has been applied.
Key Takeaways
- 11 old, Microsoft-signed UEFI shim bootloaders (version 0.9 and below) can bypass UEFI Secure Boot on any system trusting Microsoft's third-party UEFI CA 2011 certificate, regardless of installed OS
- Attackers can bring their own copy of vulnerable shims to any UEFI system with the Microsoft third-party certificate enrolled — exploitation is not limited to systems with the affected software installed
- Old shims lack MOK denylist (MokListX) enforcement (introduced in v0.9) and SBAT enforcement (introduced in v15.3), allowing them to ignore modern revocation mechanisms entirely
- CVE-2026-10797 enables revocation bypass by exploiting a discrepancy between PE header and WIN_CERTIFICATE structure size values in shims version 0.9 and below, defeating certificate-based dbx and MokListX revocations
- Vulnerable shims were revoked in Microsoft's June 9, 2026 Patch Tuesday dbx update; defenders should verify revocation status on all UEFI-based systems
Affected Systems
- Any UEFI-based machine trusting Microsoft's Microsoft Corporation UEFI CA 2011 third-party UEFI certificate
- Systems with UEFI Secure Boot enabled (Windows and Linux)
- Windows 11 Secured-core PCs (should have third-party UEFI CA disabled by default, reducing exposure)
- Systems running various Linux distributions (Oracle Linux, Red Hat Enterprise Linux 7.2, Abitti 1)
- Systems with PC-diagnostics software or UEFI-based utilities that ship with vulnerable shims
Vulnerabilities (CVEs)
copy:
| CVE | Product | Severity | Description |
|---|---|---|---|
| CVE-2026-8863 | UEFI shim bootloaders (various third-party vendors, versions 0.9 and below) | High | Covers the reported old UEFI shim bootloaders that can be used to bypass UEFI Secure Boot on systems trusting Microsoft's third-party UEFI CA certificate. |
| CVE-2026-10797 | UEFI shim bootloader (version 0.9 and below) | High | Revocation bypass vulnerability where the revocation check and signature verification functions diverge on which size value to trust (PE header vs WIN_CERTIFICATE structure), allowing attackers to tamper with the WIN_CERTIFICATE structure to bypass certificate-based dbx and MokListX revocations. |
| CVE-2015-5281 | GRUB 2 (Oracle Linux 7.1 and other distributions) | High | Allows local users to bypass intended Secure Boot restrictions and execute non-verified code via crafted multiboot or multiboot2 modules on UEFI systems. |
| CVE-2020-10713 | GRUB 2 | High | BootHole vulnerability in GRUB 2 allowing arbitrary code execution during boot, bypassing Secure Boot; referenced in context of dbx revocation scaling issues. |
Attack Chain
- Preparation: Attacker obtains an old, Microsoft-signed UEFI shim bootloader (version 0.9 or below) that remains trusted but lacks modern security features (SBAT, MokListX enforcement)
- Initial Access: Attacker writes the vulnerable shim and a compatible vulnerable second-stage bootloader (e.g., GRUB 2 with CVE-2015-5281) to the EFI System Partition (ESP)
- Defense Evasion: During boot, the old shim bypasses UEFI Secure Boot by ignoring SBAT revocation policies and MokListX denylists, loading the vulnerable GRUB 2 binary without complaint
- Execution: The vulnerable GRUB 2 binary loads unsigned code via multiboot2 commands, executing attacker-controlled code during boot regardless of Secure Boot status
- Persistence: Attacker deploys a UEFI bootkit (e.g., Bootkitty, BlackLotus) for persistent low-level access that survives OS reinstalls, potentially abusing MOK NVRAM variables for persistence
Detection Availability
- YARA Rules: No
- Sigma Rules: No
- Snort/Suricata Rules: No
- KQL Queries: No
- Splunk SPL Queries: No
- EQL Queries: No
- Other Detection Logic: Yes
- Platforms: PowerShell (Get-SecureBootUEFI), uefi-dbx-audit script
The article provides PowerShell commands to check whether the 11 vulnerable shim PE Authenticode hashes have been revoked in the local dbx database on Windows systems. For Linux systems, the article recommends using the uefi-dbx-audit script available through the Linux Vendor Firmware Service.
Detection Engineering Assessment
copy:
| Dimension | Rating | Rationale |
|---|---|---|
| EDR Visibility | Low | UEFI boot processes occur before the operating system loads, so EDR agents typically have no visibility into shim loading or Secure Boot verification. EDR can only detect post-boot artifacts such as unexpected files on the ESP or NVRAM variable modifications after the fact. |
| Network Visibility | None | The attack occurs entirely at boot time on the local system with no network activity involved. No C2 communication or network-based indicators are generated during the Secure Boot bypass itself. |
| Detection Difficulty | Hard | Detection requires firmware-level visibility that most organizations lack. The vulnerable shims are legitimately signed by Microsoft, making signature-based detection unreliable. Identifying whether a shim is old versus malicious requires checking PE Authenticode hashes against the dbx revocation list, which must be kept current. The attack leaves minimal traces visible to standard OS-level security tools. |
Required Log Sources
- UEFI/BIOS firmware event logs
- Secure Boot verification event logs
- EFI System Partition file integrity monitoring
- NVRAM variable change logs (MokList, MokListX, SbatLevel)
- Microsoft-WSEC-Platform-Events (Windows)
- Windows Event Log for firmware and Secure Boot events
Hunting Hypotheses
copy:
| Hypothesis | Telemetry | ATT&CK Stage | FP Risk |
|---|---|---|---|
| Hunt for the presence of revoked UEFI shim binaries on the EFI System Partition by comparing their PE Authenticode hashes against the dbx revocation list published by Microsoft. | EFI System Partition file enumeration, PE file hash computation, comparison against dbx contents via Get-SecureBootUEFI on Windows or uefi-dbx-audit on Linux. | Persistence / Defense Evasion | High — the vulnerable shims are part of legitimate software packages and may be present on systems that have never been compromised. Presence indicates a vulnerable state, not necessarily active compromise. |
| Hunt for unexpected UEFI shim binaries on systems that do not run Linux, as the presence of Linux-oriented shims on Windows-only systems may indicate an attacker placed them there to bypass Secure Boot. | EFI System Partition file inventory, boot entry configuration via bcdedit on Windows, comparison against expected baseline of legitimate UEFI applications. | Initial Access / Persistence | Medium — some Windows systems may legitimately have Linux shims from dual-boot configurations or recovery tools, but unexpected shims on production Windows-only systems warrant investigation. |
| Hunt for unauthorized modifications to MOK NVRAM variables (MokList, MokListX) that could indicate a bootkit has enrolled its own keys for persistence after bypassing Secure Boot. | UEFI NVRAM variable inspection tools, MokManager enrollment logs, boot-time Secure Boot event logs. | Persistence | Medium — legitimate MOK enrollments occur in enterprise environments for custom UEFI tools, but unexpected or unauthorized MOK changes should be investigated. |
| Hunt for systems where the June 2026 dbx revocation update has not been applied, as these systems remain vulnerable to the reported shim-based Secure Boot bypass. | Check dbx contents via Get-SecureBootUEFI on Windows or uefi-dbx-audit on Linux; verify presence of the 11 revoked PE Authenticode hashes in the local dbx. | Defense Evasion | Low — checking for the presence of revocation updates is a straightforward compliance check with minimal false positive risk. |
| Hunt for UEFI boot applications signed with the Microsoft Corporation UEFI CA 2011 certificate that are not in the known-good or known-revoked lists, as these may represent additional forgotten shims with unknown vulnerabilities. | EFI System Partition file enumeration with certificate chain inspection, comparison against Microsoft dbx repository and shim-review catalog. | Defense Evasion / Persistence | High — many legitimate UEFI applications are signed with this certificate; only those with known vulnerabilities or that are unexpected on the system should be flagged. |
Control Gaps
- Standard EDR products have no visibility into UEFI boot-time processes and cannot detect shim loading or Secure Boot bypass in real time
- Network security controls (IDS/IPS, firewalls) provide no coverage as the attack is entirely local at boot time
- Signature-based antivirus cannot distinguish between legitimately signed vulnerable shims and patched versions without hash-based revocation checking
- Standard vulnerability scanners may not check UEFI dbx revocation status or enumerate EFI System Partition contents
- File integrity monitoring may not cover the EFI System Partition by default in many configurations
Key Behavioral Indicators
- Presence of UEFI shim binaries with PE Authenticode hashes matching the 11 revoked hashes on the EFI System Partition
- Unexpected .efi files on the EFI System Partition, particularly Linux-oriented shims on Windows-only systems
- UEFI boot applications signed with the Microsoft Corporation UEFI CA 2011 certificate that are not in known-good or known-revoked lists
- Unauthorized MOK enrollments in NVRAM variables (MokList) that were not added through the legitimate MokManager enrollment process
- Missing dbx revocation entries for the 11 reported shim hashes, indicating the June 2026 Patch Tuesday update has not been applied
- Unexpected boot configuration changes pointing to non-standard UEFI boot applications
False Positive Assessment
High — The article explicitly states that the vulnerable shims are part of legitimate software packages potentially present on thousands of systems that have never been compromised. Detecting these hashes as compromise indicators would generate massive false positives. The hashes should be used to verify revocation status and identify vulnerable states, not as definitive indicators of active compromise.
Recommendations
Immediate Mitigation
defender takeaway
- Verify against your organization's incident response runbook and team escalation paths before acting. Ensure all UEFI-based systems have applied Microsoft's June 9, 2026 Patch Tuesday dbx update containing revocations for the 11 vulnerable shim hashes.
- Consider running the PowerShell commands provided in the article on Windows systems to verify that all 11 PE Authenticode hashes have been revoked in the local dbx database.
- For Linux systems, consider using the uefi-dbx-audit script from the Linux Vendor Firmware Service to verify revocation status.
- If any systems are found with unrevoked vulnerable shims, consider prioritizing firmware updates for those systems and investigating whether the shims were placed by an attacker.
Infrastructure Hardening
- Consider disabling the Microsoft Corporation UEFI CA 2011 third-party UEFI certificate in db on systems that do not require third-party UEFI boot applications, particularly on Windows-only systems.
- Evaluate whether Windows 11 Secured-core PC configurations are appropriate for high-value systems, as they have the third-party UEFI CA disabled by default.
- Consider implementing firmware-level monitoring where supported, such as UEFI event logging and NVRAM variable change tracking.
- If supported by your endpoint management tools, consider deploying EFI System Partition file integrity monitoring to detect unexpected .efi files or modifications to boot entries.
User Protection
- Ensure all endpoint systems receive firmware updates through standard patch management processes, not just OS-level updates.
- Consider restricting physical access to systems where feasible, as the attack requires writing files to the EFI System Partition which typically requires elevated privileges or physical access.
- If your organization uses custom MOKs for UEFI signing, consider auditing MokList and MokListX NVRAM variables for unauthorized enrollments.
Security Awareness
- Consider incorporating UEFI Secure Boot security awareness into existing security training programs for IT administrators, emphasizing the importance of firmware-level patching alongside OS patching.
- Educate system administrators that UEFI certificate expiration does not invalidate previously signed binaries — explicit revocation in dbx is required.
- Consider adding UEFI security verification to existing system hardening checklists and onboarding procedures for new devices.
MITRE ATT&CK Mapping
MITRE ATT&CK Mapping4 techniques
Tactic
Persistence
Tactic
Stealth
Tactic
Defense Impairment
Additional IOCs
- File Hashes:
AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629(SHA256) - PE Authenticode hash of a vulnerable UEFI shim bootloader revoked in Microsoft's June 9, 2026 dbx update. Presence on the ESP indicates a vulnerable shim that can be used to bypass Secure Boot; not necessarily an indicator of active compromise.
- Other:
2E434A724B4759C981E4189AA5AD3D635096DD2F- SHA-1 thumbprint of the Oracle Corporation vendor certificate embedded in the Oracle Linux shim, used to sign trusted second-stage bootloaders including a GRUB 2 binary vulnerable to CVE-2015-5281.
