ESET研究人员发现了11个版本0.9及以下的旧且被遗忘的UEFI shim引导加载程序，这些引导加载器可以用于绕过任何信任Microsoft Microsoft Corporation UEFI CA 2011第三方UEFI证书授权中心（CA）证书的基于UEFI的机器上，无论安装的操作系统（OS）为何。报告中的 shim 可以在系统启动时被利用执行不可信代码，使攻击者能够在启用 UEFI 安全启动的系统上部署恶意 UEFI 启动套件（如 Bootkitty、HybridPetya 或 BlackLotus）。我们于2026年2月向CERT/CC报告了调查结果，且这些易受攻击的UEFI应用于6月9日被Microsoft撤销th2026年补丁星期二。
虽然本案被分配了两个CVE ID，分别是CVE-2026-8863和CVE-2026-10797，但每个报告的垫片的利用不仅仅是针对这些旧垫片中直接存在的一两个漏洞。事实上，攻击面还被shim可信的二级引导加载程序（主要是GRUB 2）扩展，这些引导加载程序和shim本身一样，可能包含已知漏洞的过时版本。发现的垫片来自多种工具或软件包，包括PC诊断软件、Linux发行版及其他基于UEFI的工具。重要的是，攻击不仅限于安装了受影响软件或操作系统的系统，攻击者可以将自己带有易受攻击的垫片副本带到任何注册了Microsoft第三方UEFI证书的UEFI系统。
依赖报告垫片的所有软件产品及其受影响版本的完整列表可在CERT/CC的漏洞说明中查阅。针对ESET研究人员的报告，包含以下PE Authenticode哈希的UEFI shim引导加载程序在Microsoft的dbx更新中被撤销6月9日th补丁星期二:
- AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
- 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
- EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
- FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
- A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
- 95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
- 236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
- 5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
- 8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
- 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
- 96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629
这篇博客文章的要点：
- ESET研究人员发现了11个老旧的Microsoft签名UEFI应用程序，这些应用允许在大多数基于UEFI的系统上绕过UEFI安全启动。
- 攻击者利用这些易受攻击的应用程序可以在系统启动时执行不受信任的代码，从而部署恶意的UEFI启动套件或其他恶意软件。
- 攻击不仅限于安装了受影响软件或操作系统的系统，攻击者可以将他们自己的易受攻击二进制文件带到任何注册了Microsoft第三方UEFI证书的UEFI系统。
- 所有启用Microsoft第三方UEFI签名的UEFI系统都会受到影响（Windows 11安全核心电脑默认应关闭此选项）。
- Microsoft于6月9日撤销了这些易受攻击的二进制文件th2026年补丁星期二更新。
以下是协调披露时间表。我们感谢CERT/CC在协调漏洞披露流程中的帮助，以及受影响供应商在漏洞披露和修复过程中的顺畅透明沟通与合作。为了保护你的系统免受这种威胁，安装最新的 Microsoft dbx 更新。关于如何操作的说明可以在保护与检测部分找到。
协调披露时间表：
- 2026-02-16 – ESET向CERT/CC报告了研究结果及概念验证。
- 2026-03-18 – DBX 更新及公开披露日期定于 5 月 19 日th，2026年（Microsoft五月补丁星期二）。
- 2026-03-30 – DBX更新及公开披露日期推迟至6月9日th2026年（Microsoft六月补丁星期二）。
- 2026-06-09 – Microsoft 六月补丁星期二更新，发布了 CERT/CC 漏洞说明。
- 2026-07-14 – ESET博客文章发布。
UEFI shim 引导加载程序和 UEFI 安全启动
要理解这些易受攻击的 shims 对 UEFI 安全启动保护系统的影响，我们需要了解 UEFI 安全启动的工作原理，以及签名 UEFI shim 引导加载程序如何扩展安全启动信任链。本节我们将探讨UEFI安全启动基础知识，UEFI垫片如何扩展UEFI安全启动信任链，以及两个与SHIM相关的功能：机器所有者密钥（MOK）和安全启动高级定位（SBAT）。对于已经熟悉该理论的玩家，我们建议直接跳到“利用旧夹片绕过UEFI安全启动”这一部分。
UEFI 安全启动
如图1所示，当UEFI固件加载启动应用程序——如Windows Boot Manager或UEFI shim——会将二进制文件与两个安全启动数据库进行验证：
- db（允许证书和Authenticode哈希），以及
- dbx（禁止证书和Authenticode哈希）。
该镜像必须被数据库信任且不被列入dbx——否则启动管理器会触发安全违规而非执行。为了在新购的启用 UEFI 安全启动的设备上实现即用，大多数 OEM 会在数据库中注册一套 Microsoft UEFI 证书，具体包括：
- Microsoft Windows Production PCA 2011 和 Windows UEFI CA 2023（用于签署 Microsoft 自有的 UEFI 启动应用程序;由于 BlackLotus 相关漏洞，2011 证书将很快加入 dbx）。
- Microsoft Corporation UEFI CA 2011 和 Microsoft UEFI CA 2023（用于签署第三方 UEFI 启动软件，如 Linux 抖动、恢复工具和磁盘加密工具）。
这意味着任何希望启动时软件默认兼容UEFI安全启动的人，都可以将二进制文件提交给Microsoft，通过Windows硬件开发中心签名，一旦批准，签名文件在绝大多数UEFI系统中即被视为信任。因此，Microsoft在保护大多数基于UEFI的设备中扮演核心角色，实际上决定了启动时哪些设备允许运行，哪些不允许运行。
UEFI撤销（dbx）
UEFI 安全启动的撤销设计很简单：当一个之前受信任的启动应用——其 PE Authenticode 哈希或签署证书存在于数据库中——被发现存在漏洞时，其 PE Authenticode 哈希会被添加到 dbx——Microsoft 管理的禁止签名数据库（最新的 dbx 内容通常发布在 Microsoft 的 GitHub 仓库中）。证书本身只有偶尔被吊销。
虽然在安全启动引入时，通过哈希撤销单个易受攻击二进制文件的想法可能合理，但像BootHole和BlackLotus这样的案例表明，这种方法远非理想。根本问题是规模性，这一点在 Red Hat 引导加载程序团队的 SBAT 提案/规范中得到了很好的体现：
作为最近“BootHole”安全事件CVE-2020-10713的一部分，在流行的x64架构上的UEFI安全启动撤销数据库dbx中添加了3张证书和150个镜像哈希值。这次撤销事件占用了UEFI平台上通常可用的32kB中约三分之一的10kB。由于UEFI合并撤销列表的方式，这加上之前的撤销事件可能导致dbx体积接近15kB，容量接近50%。
同样的 dbx 容量压力在 BlackLotus 相关 Windows Boot Manager 二进制文件被撤销时再次出现。这两项措施促使Microsoft及其合作伙伴引入了额外的基于版本的撤销机制，每个机制都绑定在两个广泛部署的安全启动兼容引导加载程序中的一个：
- 安全启动高级定位（SBAT）——由 shim 使用，shim 是 Linux 的 UEFI 引导加载程序，从 15.3 版本开始使用。
- Microsoft的安全启动安全版本号（SVN）——被Windows Boot Manager（2024年4月发布）使用——在Bill Demirkapi的《谨慎启动》第62页中也称为通过嵌入安全版本信息撤销（REVISE）;然而，这个名称和缩写似乎并未在 Microsoft 官方文档中使用。
简而言之，dbx 撤销二进制文件，而 SBAT 和 Microsoft 的安全启动 SVN 则撤销版本。当支持此类基于版本的撤销机制的UEFI应用发现漏洞时，真正需要排除的是所有构建，包括破损版本——这比用一长串哈希更容易通过版本号来捕捉。我们在“安全启动高级定位（SBAT）”部分详细解释了SBAT。
UEFI shim 引导加载程序和安全启动
随着支持UEFI安全启动的Linux发行版，上述围绕Microsoft密钥构建的安全启动机制带来了一些挑战。每个Linux发行版都生成自己的引导加载程序二进制文件，每个都有不同的哈希值。让每个Linux引导加载程序都由Microsoft直接签署，将是缓慢、繁琐且不切实际（甚至不可能）在所有Linux发行版中维护起来的。
解决这个问题的方法是 shim：一个小型、最小化的第一阶段引导加载程序，Microsoft 只需审核并签署一次，然后为 Linux 发行版专用的启动栈——通常是 GRUB 2 和 Linux 内核——创建一个次级信任锚。该信任锚是另一种证书，称为供应商证书（由分发厂商管理），在Microsoft签署前添加到shim二进制文件中。
图2展示了在支持安全启动的Linux系统上使用垫片的简化启动序列。
UEFI 固件会加载垫片，并验证其签名是否与固件中存储的 Microsoft CA（数据库变量）进行对照。然后 shim 接管并验证第二阶段引导加载程序（通常是 GRUB 2）是否符合其自身嵌入式厂商证书——例如，Debian 的 Debian UEFI 密钥、Ubuntu 的 Canonical UEFI 密钥，或 Red Hat 的 RHEL 和 Fedora 的 keyGRUB 2 则使用同一厂商证书验证内核，然后再交接控制权。每一步都由前一步进行密码学认证。
这种间接性意味着Linux发行版可以快速发布引导加载器和内核更新，并用自己的厂商密钥签名，而无需每次更新都返回Microsoft。只有垫片本身需要Microsoft的签名——而且它很少更换。
除了厂商证书外，shim 通常还包含仅与该特定 shim 构建/二进制相关联的另一个内置证书。该证书通常被称为 shim 证书，用于签署和验证 shim 构建期间可生成的实用工具完整性，例如 MokManager（用于管理 MOK，下面将详细说明）或 shim 的备用文件。
机器所有者密钥（MOK）
谈到垫片时，我们不能忽略另一个重要机制，它允许垫片使用用户管理的外部密钥，称为机器所有者密钥（MOK）。MOK 允许列表（可以把它看作是 UEFI 数据库数据库中针对 shim 的“扩展”）存储在一个仅用于启动的 NVRAM 变量 MokList 中，而禁止列表（UEFI dbx 数据库的 shim 专用“扩展”）存储在仅启动的 NVRAM 变量 MokListX 中;在启用 UEFI 安全启动的系统中，修改这两个变量需要物理访问（仅启动变量只能在启动时修改，在操作系统加载器调用 UEFI 启动服务函数 ExitBootServices 之前）。为了管理列表，shim 使用 MokManager UEFI 应用程序。关于如何管理MOK的指南可以在这里找到。图3展示了MOK如何扩展shim的UEFI安全启动信任链。
正如我们在 BlackLotus 和 Bootkitty 发现中描述的，由于 MOK 机制中使用的仅启动 NVRAM 变量是非认证的，bootkit 一旦成功绕过 UEFI 安全启动，往往会滥用 MOK 来实现持久化。
安全启动高级目标定位（SBAT）
每个支持 SBAT 的 UEFI 应用程序（组件）在其 PE 文件中专门的 .sbat 部分携带一小段元数据，该部分由与二进制文件相同的签名保护。元数据为组件命名（例如shim或grub），并为其分配一个生成编号，每次安全修复发布时都会增加。
使这些数字成为撤销机制的是UEFI系统本身的匹配策略：一个仅引导的UEFI变量SbatLevel，记录每个已知组件的最小可接受生成次数。关键是，这个变量是由 shim 管理和强制执行的，而不是固件，这使得撤销更新比 dbx 更新更快。shim 嵌入了策略，因此执行不再仅依赖外部变量，而是包含通过 SbatLevel 提供的任何新策略。每次启动时，shim 首先会对其自身的 SBAT 元数据进行策略验证——这样过时的 shim 可以被拒绝——然后对它加载的每个二进制文件都应用同样的测试，拒绝任何生成数低于政策最低要求的项目。
SBAT撤销的示例见图4。这些数据取自位于 shim 仓库中的 SbatLevel_Variable.txt 文件，该文件是 SBAT 撤销的唯一来源。
强制级别不会对操作系统隐藏——shim 通过运行变量 SbatLevelRT 发布了只读副本。操作系统可以检查当前生效的撤销策略，但无法修改。在 Windows 上，同样的信息也可以通过注册表值 HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\SBAT\SbatLevel 获得。
利用旧的 shims 绕过 UEFI 安全启动
在前一节中解释了 shim 的安全启动信任链理论后，我们现在可以聚焦于那些被遗忘且陈旧但受信任的 UEFI 二进制文件对 UEFI 系统安全可能产生的实际影响。
我们通过分析报告中的几个具体问题来说明这一点——这些问题容易被利用，并凸显了它们暴露的攻击面的广泛性。
易受攻击的第二阶段引导加载程序
每个报告的 shims 都嵌入了厂商管理和内置 shim 证书，作为 shim 第二阶段引导加载程序或工具的信任锚点：GRUB 2 二进制文件、MokManager、备用加载器，以及偶尔其他供应商签名的 shims，进一步扩展信任链。每个 shim 信任的二进制文件数量各异：专用专用软件不到十个，而知名 Linux 发行版则接近一百个。
我们报告的shim信任应用的签名和编译时间戳从2013年到2025年——足以证实这些二进制文件中有相当一部分是老旧的，并且很可能受到许多公开已知漏洞的影响，包括前面提到的GRUB 2中的BootHole。虽然大多数受信任组件都足够老，存在一定的安全风险，但GRUB 2似乎是最薄弱的环节。这是一个复杂的软件，旧版本会相应地积累漏洞。
以我们报道的Oracle Linux垫片为例。它信任由甲骨文公司签发的证书签名的二进制文件（SHA-1 拇指纹：2E434A724B4759C981E4189AA5AD3D635096DD2F）。该证书签名的一个二进制文件是 Oracle Linux 7.1 安装 ISO （V74844-01.iso） 中的 GRUB 2 二进制文件。该二进制文件受CVE-2015-5281影响，引用漏洞说明——“当用于UEFI系统时，允许本地用户绕过预期的安全启动限制，并通过定制的（1）多重启动或（2）多启动2模块执行未验证代码”。上述模块multiboot和multiboot2允许在系统启动时使用相同名称的命令加载未签名代码，应禁止在签名UEFI安全启动兼容的GRUB 2二进制文件中使用，因为它们设计上绕过了UEFI安全启动。
漏洞很简单：无需触发内存损坏漏洞，无需构建ROP链，也无需复杂的逆向工程。唯一的前提是构建一个自定义的、无符号的多重启动2兼容内核镜像——实际上，它不过是一个包含所需头部和少量其他细节的ELF二进制文件。一旦攻击者构建了该二进制文件，并将其与易受攻击的 shim 和 GRUB 2 一起复制到 EFI 系统分区（ESP），就可以用一个 GRUB 2 的 multiboot2 命令在启动时加载并执行该命令，无论是否启用安全启动。下面的视频展示了通过旧的 Oracle Linux shim 在启用 UEFI 安全启动（未应用最新 Microsoft 补丁）的系统上利用 CVE-2015-5281 的概念验证：
缺乏新功能
多年来，UEFI shim 引导加载程序自然演进，随着上游 UEFI shim 仓库的后续版本引入了新的改进和安全特性。与此同时，许多第三方厂商利用现有的 shim 源代码版本构建自己的二进制文件，随后提交给 Microsoft 签署。这种行为是预期中的，也符合垫片的原始设计。然而，撤销过时的Microsoft签名shims的关注不足，而这些shim设计上可以被用来绕过更新的安全机制。我们用几个具体例子来说明这一差距。
MOK否认者执法
MokList（基于MOK的允许列表）自几乎从一开始（版本0.3）起就被上游UEFI shim支持。然而，MOK撤销（MokListX）直到0.9版本才开始强制执行。这有什么问题？请考虑以下情景……
一家企业注册了自己的MOK，以签署其在网络中部署的定制UEFI工具和引导加载程序。其中几个二进制文件中出现了漏洞，管理员通过将其注册到MOK拒绝名单（MokListX）中，将其撤销。然后，他们注册一个新的MOK，并用新密钥重新签名受影响的二进制文件。旧的、易受攻击的二进制现在被 shim 拒绝，而新签名的二进制文件则能正常加载，因此企业设备看起来很安全。旧证书在 MokList 中仍然存在并受信任，但在 MokListX 中被撤销，作为更高优先级规则执行。
在这种情况下，攻击者可能会用我们报告中较旧的Microsoft签名UEFIshim替换受害者的最新shim——例如，由Microsoft为芬兰中学考试委员会签署的Abitti 1软件0.8版本。该 shim 仍然信任存储在受害者 MokList 变量中的证书，而过时的 MOK 证书仍然有效，但它忽略了 MokListX，因为它是在 MOK 否认者执法引入之前构建的。因此，攻击者的垫片可以被用来无限制地加载易受攻击的二进制文件，允许任意代码执行或安装恶意的UEFI启动套件。
SBAT执法
SBAT也有同样的问题。对该支持是在 shim 15.3 版本上游引入的，因此早期的 shim 并不知道该机制：它不会读取 SbatLevel 撤销策略，也不会检查它加载的第二阶段引导加载程序中的 .sbat 部分。因此，它忽略了后续旨在阻挡易受攻击组件的SBAT撤销。
在这种情况下，攻击场景如下：攻击者利用Microsoft签名的v15.3前shim——例如我们报告中提到的Red Hat Enterprise Linux 7.2 0.9版本shim——将其与shim仍信任但SBAT已撤销的多个GRUB 2二进制文件中的一个配对， 然后将两者复制到ESP。在系统启动期间，shim 会根据自身嵌入的证书验证 GRUB 2 二进制文件，从不查阅 SBAT，并无怨言地加载易受攻击的二进制文件——让攻击者可以自由利用该 GRUB 2 二进制文件中的任何漏洞。
已知的垫片漏洞
最后，旧垫片就是旧代码，而许多老代码都存在已知漏洞。为了说明这一点，我们用一个影响0.9及以下版本垫片的旧问题为例。该漏洞直到我们的报告才被分配到CVE ID——尽管它在几乎十年前在一个shim仓库的上游提交d241bbb的消息中已经修复并详细描述过。目前该系统被标记为CVE-2026-10797。
问题在于，Authenticode 签名的 PE 二进制在两个独立位置记录其签名长度：
- 其PE头的数据目录（IMAGE_DIRECTORY_ENTRY_SECURITY），以及
- 它的WIN_CERTIFICATE结构，封装了签名本身。
在受影响的垫片中，撤销检查和签名验证功能在信任哪个尺寸值上存在分歧。撤销检查使用签名头的值，而签名验证函数使用PE头的值。
因此，可以通过篡改第二阶段引导加载程序的WIN_CERTIFICATE结构来绕过撤销机制，使撤销函数将dbx和MokListX与虚假数据进行比较，而非引导加载程序的实际签名。
简单来说，即使第二阶段引导加载程序的证书在dbx或MokListX中被撤销，shim也不会发现。这里有两个重要的评论：
- 该绕过仅适用于基于证书的撤销（不适用于基于哈希的撤销），且
- 第二阶段引导加载程序需要由嵌入 SHIM 中的证书签名（无论是 SHIM 构建过程中生成的内置证书，还是供应商证书）。
这些限制源于基于哈希的撤销和非嵌入证书（来自 MokList 和 db）会在代码的其他地方被检查，且不受此问题影响。
Microsoft UEFI证书过期难道不能解决这个问题吗？
考虑到当前的Microsoft UEFI证书到期（如图5所示，Microsoft公司UEFI CA 2011于6月27日到期th2026年），有人可能会怀疑，举报由该过期证书签署的易受攻击UEFI应用是否只是制造了不必要的噪音。
事实是，UEFI证书的到期日对安全启动验证过程没有影响。如果 Microsoft Corporation UEFI CA 2011 证书仍留在数据库中，且未在 dbx 中被撤销，那么所有有效签署该过期证书的引导加载程序都将继续被信任，除非通过哈希明确撤销。这就是为什么 Microsoft 一直用旧证书签署新提交，直到证书到期。
保护与检测
通过应用Microsoft最新的UEFI撤销措施，可以阻挡这些易受攻击的shim。Windows系统应该会自动更新。图6显示了PowerShell命令（需以提升权限运行）以检查Windows系统是否安装了必要的撤销命令。
$hashes =
'AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961',
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629'
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | Where-Object { $dbx -notmatch $_ }
if ($notRevoked) {
$notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
"All hashes revoked in dbx!"
}图6。用于检查UEFI撤销的PowerShell命令
对于Linux系统，更新应通过Linux供应商固件服务提供，且可通过uefi-dbx-audit脚本检查撤销状态。
关于如何防范（或至少检测）未知有漏洞的 UEFI 引导加载程序和 UEFI 启动套件部署的更一般建议，请参阅我们的博客文章《在 UEFI 安全启动的幌子下：介绍 CVE-2024-7344》。
结论
这些旧垫片之所以危险，并不是新漏洞，而是不需要新的漏洞来绕过UEFI安全启动。攻击者不需要复杂的利用原语——只需一份旧的、仍被信任但未被撤销的shim 二进制文件副本，以及对UEFI垫片工作原理的基本理解。这足以绕过像UEFI安全启动这样至关重要的安全功能。
虽然撤销这11件垫片解决了眼前的问题，但更深层的问题依然存在：可见度。2017年，随着shim审查仓库的引入，shim签署流程变得更加透明，厂商提交的材料会由维护者审核，然后Microsoft签署。自那以后，每一个获批的垫片都有记录——但之前签署的垫片没有，也没人能可靠地说出那些旧的、仍然被信任的垫片还有多少。未被完全透明编目的作品无法有效退役。
积极的一面是，我们认为趋势正朝着正确的方向发展。每一次此类披露都缩小了被遗忘的垫片池，借助改进的垫片签名透明度和SBAT等机制，跟踪需要撤销的物品并有效撤销，比过去更高效地处理。下一步是将Microsoft第三方UEFI签名生态系统中的这种透明度扩展到非shim第三方UEFI应用，正如多次证明的（例如CVE-2022-34302、CVE-2023-28005、CVE-2024-7344、CVE-2026-25250等）也能直接成为UEFI安全启动绕过的来源。