一个由 Microsoft 签名的第三方引导加载程序，加载了无签名或完整性验证的二级 EFI 二进制文件，从内部瓦解了 Secure Boot 信任链。
本仓库记录了针对 CVE-2026-25250 的研究，这是一个已向 Microsoft 披露并于 2026 年 4 月分配 CVE 编号的 Secure Boot 绕过漏洞。该漏洞迅速成为当年最重要的固件安全问题之一，原因恰恰在于受影响组件由 Microsoft 签名，因此在绝大多数支持 UEFI 的 Windows 系统中被无条件信任。
该漏洞由 Eclypsium 的 Mickey Shkatov 和 Stanislav Lyakhov 发现，Eclypsium 是业内领先的固件与供应链安全研究团队之一。Mickey Shkatov 是 UEFI 攻击性研究领域的资深人物，是 BootHole（CVE-2020-10713，一个影响几乎所有 Linux 发行版和 Windows 双启动配置的严重 GRUB2 Secure Boot 绕过漏洞）的作者，并与 Jesse Michael 在 DEF CON 30 上共同发表了题为“One Bootloader to Load Them All”的演讲，该演讲系统性地揭示了 Microsoft 签名的第三方引导加载程序如何构成 Secure Boot 生态系统中的一类弱点。
CVE-2026-25250 正属于这一类。
其特别具有启发意义之处在于它的简单性：没有内存破坏，没有固件本身的密码学缺陷，仅仅是一个受信任的二进制文件对下一步加载内容做出了不安全的决定。一个薄弱环节就足以使目标系统的整个 Secure Boot 模型崩溃。
CVE-2026-25250 是在分析部署于企业恢复环境中的第三方 UEFI 启动组件时发现的。受影响产品是 Horizon DataSys 的 Reboot Restore 解决方案。
该漏洞由 MITRE 而非 Microsoft 分配编号，因为缺陷位于第三方固件（shdloader.efi）中，而非 Windows 或任何 Microsoft 编写的代码。
官方参考：
Microsoft 安全响应中心 - 2026 年 4 月补丁星期二
月度安全更新公告。
官方 CVE 条目。CVSS 6.0 - AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N。CWE-325：缺少必需的加密步骤。
发现团队的原始研究披露，包括首次将该漏洞带入公众视野的 LinkedIn 帖子。
Eclypsium 的披露（由发现团队在 LinkedIn 上发布）提供了足够的上下文来识别受影响软件，并可直接从供应商网站下载。
Horizon DataSys Reboot Restore 安装程序可公开获取，在测试系统上安装后会将 shdloader.efi 和 Shield.efi 同时放入 EFI 系统分区，可在其中进行静态分析或运行时观察。
推荐的实验室环境：
Windows 10/11 虚拟机（QEMU 或 VMware）
├── Secure Boot：已启用
├── Horizon DataSys Reboot Restore：已安装
├── 通过以下命令访问 ESP：mountvol X: /S
└── 目标：
HorizonDataSys
X:\EFI\shdloader.efi ← 已签名、受信任、加载下一阶段
X:\EFI\Shield.efi ← 加载时无任何验证
安装后，可通过 sigcheck.exe（Sysinternals）或 pesign 确认 shdloader.efi 已由 Microsoft CA 2011 签名。Shield.efi 加载路径中缺少任何 LoadImage / StartImage 调用，这一点在静态分析中即可立即发现。
该漏洞影响的是一个多阶段引导链，而非单个二进制文件。
该漏洞不在于固件本身，而在于受信任引导加载程序的逻辑——一个已被固件批准的二进制文件——选择通过绕过所有安全检查的代码路径来加载二级二进制文件。
固件
└── 验证 shdloader.efi ✅ Microsoft CA 2011，受信任
└── ManualPEParse(Shield.efi) ❌ 无 LoadImage，无签名检查
└── EntryPoint() 💥 攻击者控制的代码，操作系统启动前
Secure Boot 边界的安全强度，取决于其所信任的最不谨慎的二进制文件。
CVE-2026-25250 是一个 Secure Boot 绕过漏洞，由启动过程中加载的二级 EFI 二进制文件验证不当所致。受影响的引导加载程序（shdloader.efi）已由 Secure Boot 签名并信任，但通过手动 PE 解析例程加载 Shield.efi，且不进行任何形式的密码学验证。
这是一个设计与信任模型缺陷——一个受信任组件做出了不安全的决定，使所有下游保护措施全部失效。
Secure Boot 强制实施一条信任链，其中启动序列中执行的每个组件在控制权转移前都必须经过验证。该模型只有在链中每个受信任的二进制文件都遵守这一约定时才成立：
固件 → 验证引导加载程序 → 引导加载程序仅执行经过验证的代码
CVE-2026-25250 破坏了第二个环节：
固件 → 验证 shdloader.efi（✅ 受信任）
↓
shdloader.efi → 加载 Shield.efi（❌ 未验证）
↓
任意未签名代码在启动前执行
一旦受信任的二进制文件引入了未经验证的执行路径，Secure Boot 在固件层面的强制措施就变得无关紧要。
| 步骤 | 是否执行 | 说明 |
|---|
| 在 ESP 上定位 Shield.efi | ✅ | 标准文件系统访问 |
| 将文件读入内存 | ✅ | - |
| 手动解析 PE 头 | ✅ | 自定义实现 |
| 验证签名 | ❌ | 未执行 |
| 对照 db / dbx 检查 | ❌ | 未执行 |
| 调用 LoadImage / StartImage | ❌ | 完全绕过 |
| 将执行权转移到入口点 | ✅ | 直接调用 |
缺少 LoadImage / StartImage 是根本原因。这些 UEFI 启动服务是 Secure Boot 策略执行的集成点，绕过它们就意味着绕过一切。
利用需要本地管理员权限和一次重启。
下次启动时，shdloader.efi 执行（受固件信任），加载攻击者控制的二进制文件并转移执行权——在操作系统启动前、EDR 加载前、任何测量启动策略执行前——Secure Boot 不会提出任何异议。
可实现：
Mickey Shkatov 和 Stanislav Lyakhov 的原始研究。Eclypsium 宣布该发现的 LinkedIn 帖子链接到 Horizon DataSys 软件，便于独立分析。
Microsoft MSRC - 2026 年 4 月补丁星期二
Microsoft 安全公告。
官方 CVE 条目。由 MITRE 分配编号，因为该漏洞位于第三方固件中，而非 Microsoft 代码。
Eclypsium - BootHole（CVE-2020-10713）
Mickey Shkatov 和 Jesse Michael——影响几乎所有 Linux 发行版和 Windows 双启动系统的严重 GRUB2 Secure Boot 绕过漏洞。
DEF CON 30 - "One Bootloader to Load Them All"
Mickey Shkatov 和 Jesse Michael——将 Microsoft 签名的第三方引导加载程序系统性地分析为一类 Secure Boot 攻击面。CVE-2026-25250 正是该威胁模型的直接实例。
shdloader.efi加载路径中缺少验证的根本原因分类。
UEFI 规范 - 启动服务：LoadImage / StartImage
强制执行 Secure Boot 策略的 UEFI 启动服务——被
shdloader.efi的手动 PE 加载器完全绕过。
正在研究类似课题？从事 UEFI、内核安全、漏洞利用或其他有趣的安全主题研究？如果您需要协助开发漏洞利用、探索某项技术，或只是想交流想法，欢迎随时联系。我一直乐于讨论研究、在力所能及之处提供帮助，并协作开展有趣的项目。欢迎通过 LinkedIn 与我联系。