{"id":427,"date":"2026-07-15T09:51:41","date_gmt":"2026-07-15T09:51:41","guid":{"rendered":"https:\/\/escudodigital.uy\/index.php\/2026\/07\/15\/forgotten-uefi-shims-undermining-secure-boot\/"},"modified":"2026-07-15T09:51:41","modified_gmt":"2026-07-15T09:51:41","slug":"forgotten-uefi-shims-undermining-secure-boot","status":"publish","type":"post","link":"https:\/\/escudodigital.uy\/index.php\/2026\/07\/15\/forgotten-uefi-shims-undermining-secure-boot\/","title":{"rendered":"Forgotten UEFI shims undermining Secure Boot"},"content":{"rendered":"<div>\n<p>ESET researchers identified 11 old and forgotten UEFI shim bootloaders at versions <span style=\"font-family: courier new, courier, monospace;\">0.9<\/span> and below that can be used to bypass UEFI Secure Boot on any UEFI-based machine that trusts Microsoft\u2019s <span style=\"font-family: courier new, courier, monospace;\">Microsoft Corporation UEFI CA 2011<\/span> third-party UEFI certificate authority (CA) certificate, regardless of the installed operating system (OS). Reported shims can be exploited to execute untrusted code during system boot, enabling attackers to deploy malicious UEFI bootkits (such as Bootkitty, HybridPetya, or BlackLotus) even on systems with UEFI Secure Boot enabled. We reported our findings to CERT\/CC in February 2026, and the vulnerable UEFI applications were revoked on Microsoft\u2019s June 9<sup>th<\/sup>, 2026 Patch Tuesday.<\/p>\n<p>While two CVE IDs were assigned to this case to cover the reported shims, <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2026-8863\">CVE-2026-8863<\/a> and <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2026-10797\">CVE-2026-10797<\/a>, exploitation of each reported shim is not just about a single bug or two that can be found in these old shims directly. In fact, the attack surface is extended by the shims\u2019 trusted, second-stage bootloaders (mostly <a href=\"http:\/\/www.gnu.org\/software\/grub\/grub.html\" target=\"_blank\" rel=\"noopener\">GRUB\u00a02<\/a>), which \u2013 like the shims themselves \u2013 may include outdated versions with known vulnerabilities. The discovered shims come from various tools or software packages, including PC-diagnostics software, Linux distributions, and other UEFI-based utilities. Importantly, exploitation is not limited to systems with the affected software or OS installed, as attackers can bring their own copy of the vulnerable shims to any UEFI system with the Microsoft third-party UEFI certificate enrolled.<\/p>\n<p>The full list of the software products relying on the reported shims along with their affected versions is available in <a href=\"https:\/\/kb.cert.org\/vuls\/id\/616257\" target=\"_blank\" rel=\"noopener\">CERT\/CC\u2019s Vulnerability Note<\/a>. In response to ESET researchers\u2019 report, UEFI shim bootloaders with the following PE <a href=\"https:\/\/learn.microsoft.com\/en-us\/windows-hardware\/drivers\/install\/authenticode\" target=\"_blank\" rel=\"noopener\">Authenticode<\/a> hashes were revoked in the <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> update that was part of Microsoft\u2019s <a href=\"https:\/\/msrc.microsoft.com\/update-guide\/releaseNote\/2026-Jun\" target=\"_blank\" rel=\"noopener\">June 9<sup>th<\/sup> Patch Tuesday<\/a>:<\/p>\n<ul>\n<li><span style=\"font-family: courier new, courier, monospace;\">AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373<\/span><\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629<\/span><\/li>\n<\/ul>\n<blockquote>\n<p><strong>Key points of this blogpost:<\/strong><\/p>\n<ul>\n<li>ESET researchers discovered 11 old, Microsoft-signed, UEFI applications that allow bypassing UEFI Secure Boot on the majority of UEFI-based systems.<\/li>\n<li>An attacker exploiting one of these vulnerable applications can execute untrusted code during system boot, enabling deployment of malicious UEFI bootkits or other malware.<\/li>\n<li>Exploitation is not limited to systems with the affected software or OS installed, as attackers can bring their own copy of the vulnerable binaries to any UEFI system with the Microsoft third-party UEFI certificate enrolled.<\/li>\n<li>All UEFI systems with Microsoft third-party UEFI signing enabled are affected (Windows 11 Secured-core PCs should have this option disabled by default).<\/li>\n<li>The vulnerable binaries were revoked by Microsoft in the June 9<sup>th<\/sup>, 2026 Patch Tuesday update.<\/li>\n<\/ul>\n<\/blockquote>\n<p>Following is the coordinated disclosure timeline. We\u2019d like to thank CERT\/CC for its help in coordinating the vulnerability disclosure process, and the affected vendors for smooth and transparent communication and cooperation during the vulnerability disclosure and remediation process. To protect your systems against this threat, install the latest Microsoft <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> updates. Instructions on how to do that can be found in the <em><a href=\"#Protection and detection\">Protection and detection<\/a><\/em> section.<\/p>\n<blockquote>\n<p><strong>Coordinated disclosure timeline:<\/strong><\/p>\n<ul>\n<li>2026-02-16 \u2013 ESET reported the findings, along with a proof of concept, to CERT\/CC.<\/li>\n<li>2026-03-18 \u2013 <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> update and public disclosure date was set to May 19<sup>th<\/sup>, 2026 (Microsoft\u2019s May Patch Tuesday).<\/li>\n<li>2026-03-30 \u2013 <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> update and public disclosure date was postponed to June 9<sup>th<\/sup>, 2026 (Microsoft\u2019s June Patch Tuesday).<\/li>\n<li>2026-06-09 \u2013 Microsoft\u2019s June Patch Tuesday update, CERT\/CC <a href=\"https:\/\/kb.cert.org\/vuls\/id\/616257\">Vulnerability Note<\/a> published.<\/li>\n<li>2026-07-14 \u2013 ESET blogpost published.<\/li>\n<\/ul>\n<\/blockquote>\n<h2>UEFI shim bootloader and UEFI Secure Boot<\/h2>\n<p>To understand the impact that such vulnerable shims can have on UEFI Secure Boot-protected systems, we need to understand how UEFI Secure Boot works, and how signed UEFI shim bootloaders extend the Secure Boot trust chain. In this section we\u2019ll look at UEFI Secure Boot basics, how UEFI shims extend the UEFI Secure Boot trust chain, and two shim-related features: Machine Owner Key (MOK) and Secure Boot Advanced Targeting (SBAT). For anyone already familiar with the theory, we recommend jumping directly to the section <a href=\"#Bypassing UEFI Secure Boot using old shims\"><em>Bypassing UEFI Secure Boot using old shims<\/em><\/a>.<\/p>\n<h3>UEFI Secure Boot<\/h3>\n<p>As shown in Figure 1, when UEFI firmware loads a boot application \u2013 like Windows Boot Manager or a UEFI shim \u2013 it verifies the binary against two Secure Boot databases:<\/p>\n<ul>\n<li><span style=\"font-family: courier new, courier, monospace;\">db<\/span> (allowed certificates and Authenticode hashes), and<\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> (forbidden certificates and Authenticode hashes).<\/li>\n<\/ul>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 1. UEFI Secure Boot simplified scheme (source: UEFI Bootkits and Where UEFI Security Fails, p. 48)\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-1.png\" alt=\"Figure 1. UEFI Secure Boot simplified scheme\" width=\"\" height=\"\"\/><figcaption><em>Figure 1. UEFI Secure Boot simplified scheme (source: <a href=\"https:\/\/static.rainfocus.com\/rsac\/us24\/sess\/1697270793852001dpne\/finalwebsite\/2024_USA24_HTA-T09_01_UEFI-Bootkits-and-Where-UEFI-Security-Fails_1713983196427001MzOd.pdf\" target=\"_blank\" rel=\"noopener\">UEFI Bootkits and Where UEFI Security Fails<\/a>, p. 48)<\/em><\/figcaption><\/figure>\n<p>The image must be trusted by <span style=\"font-family: courier new, courier, monospace;\">db<\/span> and not listed in <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> \u2013 otherwise, the boot manager triggers a security violation instead of executing it. To make this work out of the box on newly purchased devices with UEFI Secure Boot enabled, most OEMs enroll a set of Microsoft UEFI certificates in the <span style=\"font-family: courier new, courier, monospace;\">db<\/span> database, namely:<\/p>\n<ul>\n<li><span style=\"font-family: courier new, courier, monospace;\">Microsoft Windows Production PCA 2011<\/span> and <span style=\"font-family: courier new, courier, monospace;\">Windows UEFI CA 2023<\/span> (used to sign Microsoft\u2019s own UEFI boot applications; the 2011 certificate <a href=\"https:\/\/support.microsoft.com\/en-us\/topic\/how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d\" target=\"_blank\" rel=\"noopener\">will be added to dbx soon<\/a> as a result of the BlackLotus-related vulnerabilities).<\/li>\n<li><span style=\"font-family: courier new, courier, monospace;\">Microsoft Corporation UEFI CA 2011<\/span> and <span style=\"font-family: courier new, courier, monospace;\">Microsoft UEFI CA 2023<\/span> (used to sign third-party UEFI boot software, such as Linux shims, recovery tools, and disk encryption utilities).<\/li>\n<\/ul>\n<p>This means that anyone wanting their boot-time software to be UEFI Secure Boot-compatible by default can submit their binaries to Microsoft for signing through the Windows Hardware Dev Center, and once approved, the signed files become trusted on the vast majority of UEFI systems. As a result, Microsoft plays a central role in securing most UEFI-based devices, effectively deciding what is, and what is not, allowed to run during boot.<\/p>\n<h4>UEFI revocation (dbx)<\/h4>\n<p>UEFI Secure Boot\u2019s revocation design is straightforward: when a previously trusted boot application \u2013 one whose PE authenticode hash, or the certificate that signed it, is present in <span style=\"font-family: courier new, courier, monospace;\">db<\/span> \u2013 turns out to be vulnerable, its PE authenticode hash is added to <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span>, the Microsoft-managed forbidden-signatures database (with the latest <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> contents typically published in <a href=\"https:\/\/github.com\/microsoft\/secureboot_objects\/tree\/main\/PostSignedObjects\/DBX\" target=\"_blank\" rel=\"noopener\">Microsoft\u2019s GitHub repository<\/a>). Certificates themselves are revoked only occasionally.<\/p>\n<p>While the original idea of revoking individual vulnerable binaries by hash might have been reasonable at the time Secure Boot was introduced, cases such as <a href=\"https:\/\/eclypsium.com\/research\/theres-a-hole-in-the-boot\/\">BootHole<\/a> and BlackLotus demonstrate that this approach is far from ideal. The fundamental issue is scale, and it is well captured in the Red Hat Bootloader Team\u2019s <a href=\"https:\/\/github.com\/rhboot\/shim\/blob\/main\/SBAT.md\">SBAT<\/a> proposal\/specification:<\/p>\n<p style=\"margin-left: 5%; margin-right: 1%;\"><em>As part of the recent \u00abBootHole\u00bb security incident <a href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2020-10713\" target=\"_blank\" rel=\"noopener\">CVE-2020-10713<\/a>, 3 certificates and 150 image hashes were added to the UEFI Secure Boot revocation database dbx on the popular x64 architecture. This single revocation event consumes 10kB of the 32kB, or roughly one third, of revocation storage typically available on UEFI platforms. Due to the way that UEFI merges revocation lists, this plus prior revocation events can result in a dbx that is almost 15kB in size, approaching 50% capacity.<\/em><\/p>\n<p>The same pressure on <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> capacity surfaced again with the BlackLotus-related revocations of vulnerable Windows Boot Manager binaries. Both of these prompted Microsoft, together with its partners, to introduce additional, version-based revocation mechanisms, each tied to one of the two widely deployed Secure Boot-compatible bootloaders:<\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/rhboot\/shim\/blob\/main\/SBAT.md\">Secure Boot Advanced Targeting<\/a> (SBAT) \u2013 used by shim, a UEFI bootloader for Linux, from <a href=\"https:\/\/github.com\/rhboot\/shim\/releases\/tag\/15.3\" target=\"_blank\" rel=\"noopener\">version 15.3<\/a>.<\/li>\n<li>Microsoft\u2019s Secure Boot Security Version Number (SVN) \u2013 used by Windows Boot Manager (released in April 2024) \u2013 also referred to as Revocation via Embedded Secure Version Information (REVISE) in <a href=\"https:\/\/github.com\/microsoft\/MSRC-Security-Research\/blob\/master\/presentations\/2024_05_OffensiveCon\/OffensiveCon24_Booting_With_Caution_BDemirkapi.pdf\" target=\"_blank\" rel=\"noopener\">Bill Demirkapi\u2019s Booting with Caution, p. 62<\/a>; however, this name and acronym do not seem to be used in the official Microsoft documentation.<\/li>\n<\/ul>\n<p>In short, where <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> revokes <em>binaries<\/em>, SBAT and Microsoft\u2019s Secure Boot SVN revoke <em>versions<\/em>. When a vulnerability is found in a UEFI application supporting one of these version-based revocation mechanisms, what really needs to be kept out is <em>every build up to and including the broken one<\/em> \u2013 and <em>that<\/em> can be captured by a version number much easier than by a long list of hashes. We explain more about SBAT in the <em><a href=\"#Secure Boot Advanced Targeting (SBAT)\" target=\"_self\" rel=\"noopener\">Secure Boot Advanced Targeting (SBAT)<\/a><\/em> section.<\/p>\n<h3>UEFI shim bootloader and Secure Boot<\/h3>\n<p>With Linux distributions supporting UEFI Secure Boot, the above-described Secure Boot mechanism built around Microsoft keys introduces some challenges. Every Linux distribution generates its own bootloader binaries, and each of them has a different hash. Getting every Linux bootloader signed directly by Microsoft would be slow, bureaucratic, and impractical (if not impossible) to maintain across all Linux distributions.<\/p>\n<p>The solution to this problem is a shim: a small, minimal first-stage bootloader that Microsoft can vet and sign once, and which then creates a secondary trust anchor for the rest of the Linux distribution-specific boot stack \u2013 usually GRUB\u00a02 and the Linux kernel. This trust anchor is another certificate, referred to as a vendor certificate (managed by the distribution vendor), added to the shim binary before it is signed by Microsoft.<\/p>\n<p>A simplified boot sequence on a Secure Boot-enabled Linux system using a shim is depicted in Figure 2.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 2. Simplified UEFI boot flow on Linux systems\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-2.png\" alt=\"Figure 2. Simplified UEFI boot flow on Linux systems\" width=\"\" height=\"\"\/><figcaption><em>Figure 2. Simplified UEFI boot flow on Linux systems<\/em><\/figcaption><\/figure>\n<p>The UEFI firmware loads the shim and validates its signature against the Microsoft CA stored in the firmware (the <span style=\"font-family: courier new, courier, monospace;\">db<\/span> variable). The shim then takes over and validates the second-stage bootloader (often GRUB\u00a02) against its own embedded vendor certificate \u2013 for example, Debian\u2019s UEFI key for Debian, Canonical\u2019s UEFI key for Ubuntu, or Red Hat\u2019s key for RHEL and Fedora. GRUB\u00a02, in turn, validates the kernel using the same vendor certificate before handing over control. Every step is cryptographically vouched for by the step before it.<\/p>\n<p>This indirection means that a Linux distribution can release bootloader and kernel updates rapidly, signing them with its own vendor key, without needing to go back to Microsoft for every update. Only the shim itself requires Microsoft\u2019s signature \u2013 and it changes infrequently.<\/p>\n<p>In addition to the vendor certificate, the shim often contains another built-in certificate associated only with the specific shim build\/binary. This certificate is often referred to as a shim certificate and is used to sign and verify integrity of the shim\u2019s utilities that can be generated during the shim\u2019s build time, such as MokManager (used for managing MOKs and explained in more detail below) or the shim\u2019s <a href=\"https:\/\/www.rodsbooks.com\/efi-bootloaders\/fallback.html\" target=\"_blank\" rel=\"noopener\">fallback<\/a>.<\/p>\n<h4>Machine Owner Key (MOK)<\/h4>\n<p>When talking about shims, we cannot skip another important mechanism that allows a shim to use external keys managed by the user, known as <a href=\"https:\/\/edk2-docs.gitbook.io\/understanding-the-uefi-secure-boot-chain\/additional_secure_boot_chain_implementations\/machine_owner_key_mok\" target=\"_blank\" rel=\"noopener\">Machine Owner Keys<\/a> (MOKs). A MOK allowlist (think of it as a shim-specific \u201cextension\u201d of the UEFI <span style=\"font-family: courier new, courier, monospace;\">db<\/span> database) is stored in a boot-only NVRAM variable named <span style=\"font-family: courier new, courier, monospace;\">MokList<\/span>, and a forbidden list (the shim-specific \u201cextension\u201d of the UEFI <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> database) is stored in a boot-only NVRAM variable named <span style=\"font-family: courier new, courier, monospace;\">MokListX<\/span>; physical access is required to modify both variables on a system with UEFI Secure Boot enabled (boot-only variables can only be modified during boot, before the OS loader calls the UEFI boot services function <a href=\"https:\/\/uefi.org\/specs\/UEFI\/2.9_A\/07_Services_Boot_Services.html#efi-boot-services-exitbootservices\" target=\"_blank\" rel=\"noopener\">ExitBootServices<\/a>). To manage the lists, the shim uses the MokManager UEFI application. A guide on how to manage MOKs can be found <a href=\"https:\/\/www.rodsbooks.com\/efi-bootloaders\/secureboot.html#mokutil\" target=\"_blank\" rel=\"noopener\">here<\/a>. Figure 3 illustrates how a MOK extends the shim\u2019s UEFI Secure Boot trust chain.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 3. Simplified UEFI boot flow on Linux systems (with Machine Owner Key)\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-3.png\" alt=\"Figure 3. Simplified UEFI boot flow on Linux systems (with Machine Owner Key)\" width=\"\" height=\"\"\/><figcaption><em>Figure 3. Simplified UEFI boot flow on Linux systems (with Machine Owner Key)<\/em><\/figcaption><\/figure>\n<p>As we described in our BlackLotus and Bootkitty discoveries, due to the non-authenticated nature of the boot-only NVRAM variables used by the MOK mechanism, bootkits tend to misuse MOKs for persistence once they successfully bypass UEFI Secure Boot.<\/p>\n<h4>Secure Boot Advanced Targeting (SBAT)<a id=\"Secure Boot Advanced Targeting (SBAT)\"\/><\/h4>\n<p>Each UEFI application (component) that supports <a href=\"https:\/\/github.com\/rhboot\/shim\/blob\/main\/SBAT.md\" target=\"_blank\" rel=\"noopener\">SBAT<\/a> carries a small piece of metadata in a dedicated <span style=\"font-family: courier new, courier, monospace;\">.sbat<\/span> section of its PE file, protected by the same signature as the binary itself. The metadata names the component (for example, <span style=\"font-family: courier new, courier, monospace;\">shim<\/span> or <span style=\"font-family: courier new, courier, monospace;\">grub<\/span>) and assigns it a generation number that is incremented every time a security fix ships.<\/p>\n<p>What turns these numbers into a revocation mechanism is a matching policy on the UEFI system itself: a boot-only UEFI variable named <span style=\"font-family: courier new, courier, monospace;\">SbatLevel<\/span> that records the minimum acceptable generation number for each known component. Crucially, this variable is managed and enforced by the shim, not the firmware, which allows faster revocation updates compared to a <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> update. The shim embeds the policy, so enforcement does not rely solely on the external variable and incorporates any newer policy provided via <span style=\"font-family: courier new, courier, monospace;\">SbatLevel<\/span>. At every boot, the shim first verifies its own SBAT metadata against the policy \u2013 so an outdated shim can be made to reject itself \u2013 and then applies the same test to every binary it loads, refusing anything whose generation number falls below the minimum that the policy demands.<\/p>\n<p>Examples of SBAT revocations are shown in Figure 4. These are taken from the <a href=\"https:\/\/github.com\/rhboot\/shim\/blob\/main\/SbatLevel_Variable.txt\" target=\"_blank\" rel=\"noopener\">SbatLevel_Variable.txt<\/a> file located in the shim repository, which serves as the single source for SBAT revocations.<\/p>\n<figure class=\"image\"><img decoding=\"async\" title=\"Figure 4. Latest SBAT revocations in the shim repository\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-4.png\" alt=\"Figure 4. Latest SBAT revocations in the shim repository\" width=\"\" height=\"\"\/><figcaption><em>Figure 4. Latest SBAT revocations in the <a href=\"https:\/\/github.com\/rhboot\/shim\/blob\/main\/SbatLevel_Variable.txt\" target=\"_blank\" rel=\"noopener\">shim repository<\/a><\/em><\/figcaption><\/figure>\n<p>The enforced level isn\u2019t hidden from the OS \u2013 the shim publishes a read-only copy of <span style=\"font-family: courier new, courier, monospace;\">SbatLevel<\/span> in a runtime variable, <span style=\"font-family: courier new, courier, monospace;\">SbatLevelRT<\/span>. The OS can inspect which revocation policy is currently in force, but cannot modify it. On Windows the same information is also available through the registry value <span style=\"font-family: courier new, courier, monospace;\">HKLM\\SYSTEM\\CurrentControlSet\\Control\\SecureBoot\\SBAT\\SbatLevel<\/span>.<\/p>\n<h2>Bypassing UEFI Secure Boot using old shims<a id=\"Bypassing UEFI Secure Boot using old shims\"\/><\/h2>\n<p>With the theory about a shim\u2019s Secure Boot trust chain explained in the previous section, we can now focus on the practical impact that forgotten and old, though trusted, UEFI binaries can have on UEFI system security.<\/p>\n<p>We illustrate this by examining a few specific issues in the reported shims \u2013 issues that are easily exploitable and highlight the breadth of the attack surface they expose.<\/p>\n<h3>Vulnerable second-stage bootloaders<\/h3>\n<p>Each of the reported shims embeds both a vendor-managed and a built-in shim certificate that serve as a trust anchor for the shim\u2019s second-stage bootloaders or utilities: GRUB\u00a02 binaries, MokManager, fallback loaders, and occasionally other vendor-signed shims that extend the trust chain even further. The number of binaries trusted by a given shim varies: from fewer than ten in the case of dedicated, specialized software to close to a hundred in the case of well-known Linux distributions.<\/p>\n<p>Signing and compilation timestamps of the applications trusted by the shims we reported span from 2013 to 2025 \u2013 enough to confirm that a significant portion of these binaries were old and likely affected by numerous publicly known vulnerabilities, including the already mentioned <a href=\"https:\/\/eclypsium.com\/research\/theres-a-hole-in-the-boot\/\" target=\"_blank\" rel=\"noopener\">BootHole<\/a> in the case of GRUB\u00a02. While most of these trusted components are old enough to carry some security risk, GRUB\u00a02 seems to be the weakest link. It is a complex piece of software, and older versions accumulate vulnerabilities accordingly.<\/p>\n<p>Consider the shim from Oracle Linux, which is among those we reported. It trusts binaries signed by a certificate issued to <span style=\"font-family: courier new, courier, monospace;\">Oracle Corporation<\/span> (SHA\u20111 thumbprint: <span style=\"font-family: courier new, courier, monospace;\">2E434A724B4759C981E4189AA5AD3D635096DD2F<\/span>). One of the binaries signed by that certificate is a GRUB\u00a02 binary found in the Oracle Linux 7.1 installation ISO (<span style=\"font-family: courier new, courier, monospace;\">V74844-01.iso<\/span>). This binary is affected by <a href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2015-5281\" target=\"_blank\" rel=\"noopener\">CVE-2015-5281<\/a>, which \u2013 quoting the vulnerability note \u2013 \u201c<em>when used on UEFI systems, allows local users to bypass intended Secure Boot restrictions and execute non-verified code via a crafted (1) multiboot or (2) multiboot2 module<\/em>\u201d. Both mentioned modules, <span style=\"font-family: courier new, courier, monospace;\">multiboot<\/span> and <span style=\"font-family: courier new, courier, monospace;\">multiboot2<\/span>, allow loading of unsigned code during system startup using the identically named commands, and should be forbidden in signed UEFI Secure Boot-compatible GRUB\u00a02 binaries, as they bypass UEFI Secure Boot by design.<\/p>\n<p>The exploit is simple: there are no memory corruption bugs to trigger, no ROP chains to construct, and no complex reverse engineering required. The single prerequisite is building a custom, unsigned <a href=\"https:\/\/www.gnu.org\/software\/grub\/manual\/multiboot2\/multiboot.html\" target=\"_blank\" rel=\"noopener\">multiboot2-compliant<\/a> kernel image \u2013 in practice, little more than an ELF binary containing the required headers and a handful of other specifics. Once an attacker builds this binary and copies it to the EFI System Partition (ESP) along with the vulnerable shim and GRUB\u00a02, a single GRUB\u00a02 <span style=\"font-family: courier new, courier, monospace;\">multiboot2<\/span> command can be used to load and execute it during boot, Secure Boot enabled or not. A proof of concept demonstrating exploitation of CVE-2015-5281 via the old, reported Oracle Linux shim on a system with UEFI Secure Boot enabled (without the latest Microsoft patches applied) is shown in the video below:<\/p>\n<h3>Absence of newer features<\/h3>\n<p>Over the years, the UEFI shim bootloader has naturally evolved, with new improvements and security features introduced in successive releases of the upstream <a href=\"https:\/\/github.com\/rhboot\/shim\/tree\/main\" target=\"_blank\" rel=\"noopener\">UEFI shim repository<\/a>. At the same time, many third-party vendors have taken available versions of the shim source code to build their own binaries, which they subsequently submitted to Microsoft for signing. This behavior is expected and aligns with the original design of shims. However, insufficient attention has been given to revoking outdated Microsoft-signed shims, many of which can, by design, be leveraged to bypass newer security mechanisms. We illustrate this gap with a few concrete examples.<\/p>\n<h3>MOK denylist enforcement<\/h3>\n<p>The <span style=\"font-family: courier new, courier, monospace;\">MokList<\/span> (MOK-based allowlisting) has been supported by the upstream UEFI shim since <a href=\"https:\/\/github.com\/rhboot\/shim\/commit\/0848fab\" target=\"_blank\" rel=\"noopener\">almost the very beginning<\/a> (version <span style=\"font-family: courier new, courier, monospace;\">0.3<\/span>). MOK revocations (<span style=\"font-family: courier new, courier, monospace;\">MokListX<\/span>), however, only <a href=\"https:\/\/github.com\/rhboot\/shim\/commit\/b8d1bc6e98e54f6fda87ba0a248de7cba5c78f96\" target=\"_blank\" rel=\"noopener\">started to be enforced<\/a> in version <span style=\"font-family: courier new, courier, monospace;\">0.9<\/span>. Why is that a problem? Consider the following scenario&#8230;<\/p>\n<p>An enterprise has enrolled its own MOK to sign custom UEFI tools and bootloaders that it deploys across its network. A vulnerability surfaces in several of those binaries, and in response, the administrators revoke the old signing certificate by enrolling it into the MOK denylist (<span style=\"font-family: courier new, courier, monospace;\">MokListX<\/span>). Then, they enroll a fresh MOK, and re-sign patched versions of the affected binaries with the new key. The old, vulnerable binaries are now rejected by the shim, while the newly signed ones load properly, so the enterprise\u2019s devices look secure. The old certificate remains present and trusted in the <span style=\"font-family: courier new, courier, monospace;\">MokList<\/span>, but is revoked in <span style=\"font-family: courier new, courier, monospace;\">MokListX<\/span>, where it is enforced as a higher-priority rule.<\/p>\n<p>In this scenario, an attacker could replace the victim\u2019s up-to-date shim with an older Microsoft-signed UEFI shim from our report \u2013 for example, version <span style=\"font-family: courier new, courier, monospace;\">0.8<\/span> from the Abitti 1 software, signed by Microsoft for Finland\u2019s Matriculation Examination Board. This shim still trusts the certificates stored in the victim\u2019s <span style=\"font-family: courier new, courier, monospace;\">MokList<\/span> variable, where the outdated MOK certificate remains valid, but it ignores <span style=\"font-family: courier new, courier, monospace;\">MokListX<\/span>, as it was built prior to the introduction of MOK denylist <a href=\"https:\/\/github.com\/rhboot\/shim\/commit\/b8d1bc6e98e54f6fda87ba0a248de7cba5c78f96\" target=\"_blank\" rel=\"noopener\">enforcement<\/a>. As a result, the attacker\u2019s shim could be used to load vulnerable binaries without restriction, allowing arbitrary code execution or the installation of a malicious UEFI bootkit.<\/p>\n<h3>SBAT enforcement<\/h3>\n<p>The same issue applies to SBAT. Support for it was introduced upstream in shim <a href=\"https:\/\/github.com\/rhboot\/shim\/releases\/tag\/15.3\" target=\"_blank\" rel=\"noopener\">version 15.3<\/a>, so any earlier shim is unaware of the mechanism: it does not read the <span style=\"font-family: courier new, courier, monospace;\">SbatLevel<\/span> revocation policy or inspect the <span style=\"font-family: courier new, courier, monospace;\">.sbat<\/span> section of the second-stage bootloader it loads. As a result, it ignores any later SBAT revocations intended to block vulnerable components.<\/p>\n<p>In this case, an attack scenario would be the following: an attacker takes a Microsoft-signed pre-v15.3 shim \u2013 such as the version <span style=\"font-family: courier new, courier, monospace;\">0.9<\/span> shim from Red Hat Enterprise Linux <span style=\"font-family: courier new, courier, monospace;\">7.2<\/span> that was part of our report \u2013 pairs it with one of the several GRUB\u00a02 binaries that the shim still trusts but that SBAT has already revoked, and then copies both to the ESP. During system boot, the shim validates the GRUB\u00a02 binary against its own embedded certificate, never consults SBAT, and loads the vulnerable binary without complaint \u2013 leaving the attacker free to exploit any vulnerability in that GRUB\u00a02 binary.<\/p>\n<h3>Known shim vulnerabilities<\/h3>\n<p>Finally, old shims are simply old code, and much old code carries known vulnerabilities. To illustrate this, we use an example of an old issue affecting shims at version <span style=\"font-family: courier new, courier, monospace;\">0.9<\/span> and below. This vulnerability had no CVE ID assigned until our report \u2013 even though it was fixed and well described almost exactly a decade ago in the message of one of the shim repository\u2019s upstream commits, <a href=\"https:\/\/github.com\/rhboot\/shim\/commit\/d241bbbdbfb98b4f878342ef180e3994205b170a\" target=\"_blank\" rel=\"noopener\">d241bbb<\/a>. It is now tracked as <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2026-10797\" target=\"_blank\" rel=\"noopener\">CVE-2026-10797<\/a>.<\/p>\n<p>The issue is that an Authenticode-signed PE binary records its signature\u2019s length in two independent locations:<\/p>\n<ul>\n<li>its PE header\u2019s data directory (<span style=\"font-family: courier new, courier, monospace;\">IMAGE_DIRECTORY_ENTRY_SECURITY<\/span>), and<\/li>\n<li>its <span style=\"font-family: courier new, courier, monospace;\">WIN_CERTIFICATE<\/span> structure, which encapsulates the signature itself.<\/li>\n<\/ul>\n<p>In the affected shims, the revocation check and the signature verification functions diverged on which size value they should trust. The revocation check used the value from the signature header, while the signature verification function used the value from the PE header.<\/p>\n<p>It is thus possible to bypass the revocation mechanism by tampering with the second-stage bootloader\u2019s <span style=\"font-family: courier new, courier, monospace;\">WIN_CERTIFICATE<\/span> structure so that the revocation function compares <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> and <span style=\"font-family: courier new, courier, monospace;\">MokListX<\/span> against bogus data instead of the bootloader\u2019s actual signature.<\/p>\n<p>Simply put, even if the second-stage bootloader\u2019s certificate were revoked in <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span> or <span style=\"font-family: courier new, courier, monospace;\">MokListX<\/span>, the shim would not find out. Two important comments here:<\/p>\n<ul>\n<li>this bypass works only with certificate-based revocations (not hash-based revocations), and<\/li>\n<li>the second-stage bootloader needs to be signed by a certificate embedded in the shim (whether it\u2019s the shim\u2019s built-in certificate generated during the shim\u2019s build process or the vendor certificate).<\/li>\n<\/ul>\n<p>These limitations come from the fact that hash-based revocations and non-embedded certificates (from <span style=\"font-family: courier new, courier, monospace;\">MokList<\/span> and <span style=\"font-family: courier new, courier, monospace;\">db<\/span>) are checked elsewhere in the code and are not affected by this issue.<\/p>\n<h2>Won\u2019t expiring Microsoft UEFI certificates solve this?<\/h2>\n<p>With the current Microsoft UEFI certificate <a href=\"https:\/\/support.microsoft.com\/en-us\/topic\/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e\" target=\"_blank\" rel=\"noopener\">expirations<\/a> in mind (as shown in Figure 5, <span style=\"font-family: courier new, courier, monospace;\">Microsoft Corporation UEFI CA 2011<\/span> expired on June 27<sup>th<\/sup> 2026), one might wonder whether reporting vulnerable UEFI applications signed by this expired certificate is just causing unnecessary noise.<\/p>\n<p>The truth is that the UEFI certificate\u2019s expiration date has no effect on the Secure Boot verification process. If the <span style=\"font-family: courier new, courier, monospace;\">Microsoft Corporation UEFI CA 2011<\/span> certificate stays in <span style=\"font-family: courier new, courier, monospace;\">db<\/span>, and is not revoked in <span style=\"font-family: courier new, courier, monospace;\">dbx<\/span>, all bootloaders validly signed with this expired certificate stay trusted if not explicitly revoked by hash. This is the reason why Microsoft <a href=\"https:\/\/techcommunity.microsoft.com\/blog\/hardware-dev-center\/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn\/4455787\" target=\"_blank\" rel=\"noopener\">kept signing<\/a> new submissions with the old certificate up until its expiration date.<\/p>\n<figure class=\"image\"><img decoding=\"async\" style=\"width: 65%; margin: 0 auto; display: block;\" title=\"\" src=\"https:\/\/web-assets.esetstatic.com\/wls\/2026\/07-26\/uefi-shims\/figure-5.png\" alt=\"Figure 5. Microsoft Corporation UEFI CA 2011 certificate\" width=\"\" height=\"\"\/><figcaption><em>Figure 5. <\/em><span style=\"font-family: courier new, courier, monospace;\">Microsoft Corporation UEFI CA 2011<\/span><em> certificate<\/em><\/figcaption><\/figure>\n<h2>Protection and detection<a id=\"Protection and detection\"\/><\/h2>\n<p>These vulnerable shims can be blocked by applying the latest UEFI revocations from Microsoft. Windows systems should be updated automatically. Figure 6 displays PowerShell commands (to be run with elevated permissions) to check whether the necessary revocations are installed on your Windows system.<\/p>\n<pre class=\"language-markup\"><code>$hashes=\"AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961\",\n'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',\n'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',\n'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',\n'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',\n'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',\n'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',\n'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',\n'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',\n'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',\n'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' \n$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'\n$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }\nif ($notRevoked) {\n    $notRevoked | ForEach-Object { \"Hash not revoked: $_\" }\n} else {\n    \"All hashes revoked in dbx!\"\n}<\/code><\/pre>\n<p style=\"text-align: center;\"><em>Figure 6. PowerShell commands to check UEFI revocations<\/em><\/p>\n<p>For Linux systems, updates should be available through the <a href=\"https:\/\/web.archive.org\/web\/20260623050535\/https:\/fwupd.org\/\" target=\"_blank\" rel=\"noopener\">Linux Vendor Firmware Service<\/a>, and the revocation status can be checked using the <a href=\"https:\/\/github.com\/sei-vsarvepalli\/uefi-dbx-audit\/\" target=\"_blank\" rel=\"noopener\">uefi-dbx-audit<\/a> script.<\/p>\n<p>For more general recommendations regarding how to protect against (or at least detect) exploitation of unknown vulnerable signed UEFI bootloaders and deployment of UEFI bootkits, see our blogpost Under the cloak of UEFI Secure Boot: Introducing CVE-2024-7344.<\/p>\n<h2>Conclusion<\/h2>\n<p>What makes these old shims dangerous is not a novel vulnerability, it\u2019s that no new vulnerability is needed to bypass UEFI Secure Boot. An attacker needs no complicated exploitation primitives \u2013 only a copy of an old, still-trusted, <em>but unrevoked<\/em> shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot.<\/p>\n<p>While revoking these 11 shims addressed the immediate issue, a deeper issue remains: visibility. The shim signing process became significantly more transparent in 2017 with the introduction of the <a href=\"https:\/\/github.com\/rhboot\/shim-review\">shim-review<\/a> repository, where vendor submissions are vetted by maintainers before Microsoft signs them. Every shim approved since then is documented \u2013 but those signed earlier are not, and no one can reliably say how many of those old, still-trusted shims remain. What has not been fully and transparently catalogued cannot be effectively retired.<\/p>\n<p>On a positive note, we believe that the trend is moving in the right direction. Each disclosure like this one shrinks the pool of forgotten shims, and with improved shim-signing transparency and mechanisms such as SBAT, keeping track of what needs to be revoked, and effectively revoking it, can be handled far more efficiently than in the past. The next step is to extend this level of transparency in Microsoft\u2019s third-party <a href=\"https:\/\/techcommunity.microsoft.com\/blog\/hardware-dev-center\/updated-microsoft-uefi-signing-requirements\/1062916\">UEFI signing<\/a> ecosystem to non-shim third-party UEFI applications, which, as repeatedly demonstrated (e.g., <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2022-34302\" target=\"_blank\" rel=\"noopener\">CVE-2022-34302<\/a>, <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2023-28005\" target=\"_blank\" rel=\"noopener\">CVE-2023-28005<\/a>, <a href=\"https:\/\/www.cve.org\/CVERecord?id=CVE-2024-7344\" target=\"_blank\" rel=\"noopener\">CVE-2024-7344<\/a>, <a href=\"https:\/\/msrc.microsoft.com\/update-guide\/en-US\/vulnerability\/CVE-2026-25250\" target=\"_blank\" rel=\"noopener\">CVE-2026-25250<\/a>, \u2026), can also serve as a straightforward source of UEFI Secure Boot bypasses.<\/p>\n<h2>IoCs<\/h2>\n<p>As the vulnerable shims are part of legitimate software packages that are potentially present on thousands of systems that have never been compromised via these loaders, we are not providing indicators of compromise to avoid massive misidentification. Instead, defenders should follow the advice in the <em><a href=\"#Protection and detection\">Protection and detection<\/a><\/em> section.<\/p>\n<blockquote>\n<div><em>For any inquiries about our research published on WeLiveSecurity, please contact us at threatintel@eset.com.\u00a0<\/em><\/div>\n<div><em>ESET Research offers private APT intelligence reports and data feeds. For any inquiries about this service, visit the <a href=\"https:\/\/www.eset.com\/int\/business\/services\/threat-intelligence\/?utm_source=welivesecurity.com&amp;utm_medium=referral&amp;utm_campaign=wls-research&amp;utm_content=forgotten-uefi-shims-undermining-secure-boot&amp;sfdccampaignid=7011n0000017htTAAQ\" target=\"_blank\" rel=\"noopener\">ESET Threat Intelligence<\/a> page.<\/em><\/div>\n<\/blockquote>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>ESET researchers identified 11 old and forgotten UEFI shim bootloaders at versions 0.9 and below that can be<\/p>\n","protected":false},"author":1,"featured_media":428,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-427","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security"],"_links":{"self":[{"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/posts\/427","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/comments?post=427"}],"version-history":[{"count":0,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/posts\/427\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/media\/428"}],"wp:attachment":[{"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/media?parent=427"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/categories?post=427"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/escudodigital.uy\/index.php\/wp-json\/wp\/v2\/tags?post=427"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}