11本の古いMicrosoft署名UEFI shimでSecure Boot迂回 — ESETが未失効だった署名済みバイナリの危険性を実証(CVE-2026-8863 / CVE-2026-10797)

スロバキアのセキュリティ企業ESETが2026年7月14日、Microsoftが第三者ブート用に署名した11本のUEFI shimブートローダーが、長年にわたり失効されず、Secure Bootの迂回に利用できる状態だったと公表しました。発見と報告を担当したMartin Smolár研究員によると、影響を受けるのは、UEFI Secure Bootが有効で、Microsoftの第三者UEFI署名を信頼し、対象11本の失効情報がdbxへ反映されていないシステムです。OSの種類や該当製品のインストール有無には依存しません。

この事案がで特筆すべきは、新たなゼロデイ脆弱性や複雑な悪用手法を必要としない点です。管理者権限またはブートプロセスを改変できる攻撃者は、既知の弱点を持ちながら失効されていなかった古いshimと、対応する第二段階ブートローダーを持ち込むことで、Secure Bootが有効な環境でもOS起動前に未信頼コードを実行できます。ESETは2026年2月16日にCERT/CC経由で調整開示を開始し、Microsoftは2026年6月9日のPatch Tuesdayで該当11本のハッシュをUEFI失効データベース(dbx)に追加しました。CERT/CCの脆弱性ノートVU#616257も同日公開されています。

Secure Bootとshimブートローダーの関係

UEFI Secure Bootは、2011年公開のUEFI 2.3.1で仕様化され、2012年のWindows 8世代以降に広く普及した起動時検証機構です。マザーボードのファームウェアが、起動時に実行するブートローダーやドライバーを検証し、信頼済みの証明書またはハッシュで認証でき、失効対象にも含まれていないコードだけを実行することで、ブートキット(bootkit)の侵入を防ぎます。ファームウェアは2つのデータベースを参照し、dbは許可された証明書とPE Authenticodeハッシュを、dbxは取り消された証明書とハッシュを列挙します。あるバイナリを起動するにはdbで許可されており、かつdbxに載っていないことが必要です。OEMは出荷時にMicrosoftの複数の証明書をdbに事前登録するのが一般的で、そのうちMicrosoft Corporation UEFI CA 2011(および後継のMicrosoft UEFI CA 2023)は、Microsoft自身が管理するWindows Boot Manager以外の第三者製ブートコンポーネントに署名するためのものです。Linuxディストリビューションのブートローダー、リカバリツール、ディスク暗号化ユーティリティなどが対象で、多くのOEMがMicrosoftの第三者UEFI証明書をdbへ登録しているため、Microsoftが署名したブートコンポーネントは、幅広い機器のSecure Boot信頼チェーンへ接続されることになります。

shimはLinux環境がSecure Bootと共存するための小さな第一段階ブートローダーです。ディストリビューションごとに異なるカーネルやブートローダーの署名をMicrosoftに個別に依頼する運用は現実的でないため、Microsoftが署名したshimを起点として、各ディストリビューションが管理する証明書へ信頼を橋渡しする方式が採用されました。ブート時は、まずファームウェアがdb内のMicrosoft証明書でshimを検証し、shimが自分に埋め込まれたベンダー証明書で第二段階ブートローダー(多くの場合GRUB 2)を検証し、GRUB 2がさらにLinuxカーネルを検証する、という三段階の信頼チェーンが形成されます。shimにはMachine Owner Key(MOK)という利用者独自の署名鍵を追加できる拡張機構もあり、許可リストMokListと禁止リストMokListXが用意されています。もう一つ、shim 15.3以降で導入されたSecure Boot Advanced Targeting(SBAT)は、バイナリ単位のハッシュ列挙ではなくコンポーネントのバージョン単位で失効させる仕組みで、脆弱なコンポーネントが混入した際に「あるコンポーネントのある世代以下は起動禁止」という規則で一括ブロックできるようにします。

報告された11本のshimブートローダー

ESETが特定したshimは、いずれも上流(upstream)shimプロジェクトの0.9以下を基にしたベンダー固有のバイナリです。CERT/CCの脆弱性ノートに掲載されたベンダー製品と、Microsoftの6月9日dbx更新で失効されたAuthenticodeハッシュを対応させると、次の11本になります。

由来する製品はLinuxディストリビューションだけでなく、PC診断ツール(PC-Doctor)、ドライブワイプソフト(Blancco WipeDrive)、資産管理ソフト(baramundi Management Suite)、フィンランドの高校課程修了時に行われる全国統一試験「Matriculation Examination」で使用されるデジタル試験環境(Abitti)、企業向けのWindows To Go作成ツール(Spyrus WTGCreator)まで多岐にわたります。それぞれの製品を導入していない環境でも、後述するように攻撃者は自分で該当shimをコピーしてくればよいため、影響範囲はSecure BootとMicrosoft第三者UEFI署名が有効でdbx未更新のUEFI機器に及びます。

「新たな脆弱性が不要」とはどういうことか

今回の事案の要点は、古いshim自身や、そのshimが信頼する第二段階ブートローダーに既知の弱点が残る一方、Microsoft署名による信頼が長年失効されずに維持されていたという構造的な問題にあります。ESETは、問題の本質は新たなゼロデイではなく、古く脆弱なshimが失効されないまま信頼され続けていた点にあると説明しています。複雑なメモリ破壊やROPチェーンを必要とせず、古いshimと対応する第二段階ブートローダーを持ち込むだけで攻撃経路を構成できるためです。Smolár研究員は、古い未失効shimと、shimによる信頼チェーンの基本的な仕組みへの理解があれば、攻撃経路を構成できると説明しています。

この文脈でESETが挙げている「なぜ迂回できるのか」は大きく3系統に分けられます。

第二段階ブートローダーの既知脆弱性

shimがベンダー証明書で信頼する第二段階ブートローダー(多くはGRUB 2)やMokManager、fallbackローダーには、既知脆弱性が含まれていることがあります。ESETが具体例に挙げるのはOracle Linux由来のshimで、Oracle Corporation証明書で署名されたGRUB 2バイナリ(Oracle Linux 7.1インストールISOに同梱)がCVE-2015-5281の影響を受けます。この脆弱性はGRUB 2のmultiboot / multiboot2コマンドから未署名コードのロードを許すもので、Secure Bootが有効でも設計上迂回されます。攻撃者はmultiboot2準拠のカーネルイメージを1個ビルドしてESPに配置し、脆弱なshimとGRUB 2と一緒に置いておくだけで、GRUB 2のmultiboot2コマンド1行から起動できます。ESETはPoC動画も公開しています。

MOK denylist強制の不在

shimは0.3からMokList(MOK許可リスト)をサポートしていましたが、MokListX(MOK禁止リスト)の強制は0.9以降でようやく実装されました。ここに死角が生まれます。組織が自組織のMOKで署名した内製ツールに脆弱性が見つかり、管理者が古い署名証明書をMokListXに登録して失効し、新しい鍵で再署名した修正版を配布する運用を考えます。新しいshimはMokListXを評価するので旧署名バイナリは拒否されますが、攻撃者はMokListXを評価しない古いMicrosoft署名shim(例:Abitti 1のshim 0.8)を持ち込むことで、MokListに残る旧証明書を根拠に失効済みバイナリを再び通せます。

SBAT強制の不在

SBATはshim 15.3以降で導入された比較的新しい失効機構で、コンポーネント名と世代番号を.sbatセクションに埋め込み、SbatLevel UEFI変数の「最低許容世代」で版単位の失効を実現します。ハッシュを1個ずつ列挙するdbx方式の容量問題(BootHole対応時の1回の失効でdbx全体の約3分の1、150個のハッシュと3つの証明書を消費した事例がSBAT提案書に記載されています)を、世代番号で置き換えるアプローチです。この機構はshim自身が管理・強制するため、shim 15.3未満はSbatLevelを参照せず、第二段階ブートローダーの.sbatセクションも評価しません。結果として、SBATで失効済みのGRUB 2バイナリを、shim 15.3未満の古いMicrosoft署名shimと組み合わせれば、そのまま実行できてしまいます。

CVE-2026-10797:失効チェックと署名検証で参照位置がずれる

shim自身のコードに10年前から残っていた不具合が、今回初めてCVE識別子を与えられました。CVE-2026-10797はshim 0.9以下に影響し、Red Hat Enterprise Linux 7.2とCentOS 7.2のshimに紐付けられています。修正コミットd241bbbは上流shimリポジトリに約10年前に投入されましたが、報告直前までCVE番号が割り当てられない状態が続いていました。なお、記事執筆時点の2026年7月15日には、CVE.orgのCVE-2026-10797レコードは予約状態にあり、詳細な技術説明はESETの分析と上流の修正コミットに基づきます。

不具合の内容は、Authenticodeで署名されたPEバイナリが自身の署名長を2箇所に記録している事実に由来します。1つはPEヘッダのデータディレクトリ内IMAGE_DIRECTORY_ENTRY_SECURITYエントリで、もう1つは署名を格納するWIN_CERTIFICATE構造体です。本来これらは常に一致しているはずですが、影響を受けるshimでは失効チェック関数と署名検証関数がそれぞれ異なる箇所を参照していました。失効チェックは署名ヘッダ側の値を、署名検証はPEヘッダ側の値を採用していたのです。この差を利用して第二段階ブートローダーのWIN_CERTIFICATE構造体を改ざんすると、失効チェックが実際の署名とは別のバイト列を対象にdbxやMokListXと照合してしまいます。当該ブートローダーの証明書がdbxやMokListXで失効済みでも、shimはそれを検知しないまま署名検証だけを通してロードします。ただしESETはこの迂回に2つの制限があると明記しています。1つは証明書ベースの失効に対してのみ有効でハッシュベースの失効には効かないこと、もう1つは対象の第二段階ブートローダーがshimに埋め込まれた証明書(ビルド時に生成されるshim自身の証明書か、ベンダー証明書)で署名されている必要があることです。

攻撃者は何を持ち込むのか

CERT/CCの脆弱性ノートは攻撃前提を「管理者権限、またはブートプロセスを改変できる能力」と表現し、正規署名された脆弱なコンポーネントを攻撃者が持ち込むという点でBring Your Own Vulnerable Driver(BYOVD)に似た手法だと説明しています。BYOVDは既知脆弱性を含む正規署名のドライバーを攻撃者側が対象システムに持ち込む手口ですが、今回はドライバーではなく、古いshimと対応する第二段階ブートローダーを持ち込みます。攻撃対象マシンに当該製品(例えばOracle Linux)がインストールされていなくても、shimバイナリの写しをESP(EFI System Partition)に配置し、管理者権限またはブートプロセスを改変でき、対象ハッシュがdbxへ反映されていない環境では、対応する第二段階ブートローダーと組み合わせることでSecure Bootの迂回が可能になります。

実行がOSローダーの起動前に成立するため、OSや多くのセキュリティ製品が初期化される前に未信頼コードが動く形になります。OS起動前に実行した未信頼コードを足掛かりとして、UEFIブートキットや悪意あるカーネルコンポーネントを展開し、再起動後も影響を残す可能性があります。関連する実例として、ESETはBlackLotus(2023年、Windows対象)、Linux向けのBootkitty、Petya/NotPetya系譜のHybridPetyaなどを挙げています。このような起動初期のコード実行は、OS側のセキュリティ機構やEDRでは検知が難しく、監視を回避される可能性があります。

調整開示のタイムラインとMicrosoftの対応

ESETが公開した調整開示タイムラインは次の通りです。

• 2026年2月16日:ESETがPoCとともにCERT/CCへ報告
• 2026年3月18日:dbx更新と公開日を2026年5月19日(Microsoft 5月Patch Tuesday)に設定
• 2026年3月30日:公開日を2026年6月9日(Microsoft 6月Patch Tuesday)に延期
• 2026年6月9日:Microsoft 6月Patch Tuesdayでdbx更新、CERT/CC脆弱性ノートVU#616257公開
• 2026年7月14日:ESETがWeLiveSecurityで技術詳細を公開

Microsoftは6月9日のdbx更新に、対象11本のshimのAuthenticode SHA-256ハッシュを追加しました。ESETは、Windowsで`Get-SecureBootUEFI dbx`の内容と11個のハッシュを照合するPowerShellコマンド例をブログ記事内に掲載しています。Linuxでは、CERT/CCのVijay Sarvepalli氏が公開している`uefi-dbx-audit`スクリプトで確認できます。

WindowsとLinuxで確認すべきこと

ESETはWindows向けの確認方法を掲載しており、LinuxではCERT/CC関係者が公開した監査ツールを利用できます。

• Windows: 対象の失効情報は標準の更新経路で配布されます。ただし、累積更新プログラムがインストールされていても、対象端末のdbxへ実際に反映されたかは、ESETが掲載しているPowerShellコマンド例(`Get-SecureBootUEFI dbx`の中身と11個のハッシュを比較する内容)を用いて確認してください。Windows 11 Secured-core PCは第三者UEFI署名が既定で無効とされているため、既定構成では影響を受けませんが、ファームウェア設定やOEM実装によって構成が変更されていないかを併せて確認します。
• Linux: LVFSおよびfwupd経由でdbx更新が提供される場合があります。配布状況はディストリビューションや端末によって異なるため、CERT/CCのVijay Sarvepalli氏が公開しているuefi-dbx-auditスクリプトを用いて実際の失効状態を確認してください。
• 組織展開時: CERT/CCは「先にdb側の許可リストと最新ブートコンポーネントを配布し、そのうえでdbx失効を配布する」という順序を推奨しています。逆順で配布すると、まだ更新されていないコンポーネントが失効で弾かれてブート不能になる懸念があります。

ベンダー個別の状況としては、CERT/CCの脆弱性ノートに以下の回答が掲載されています。AMIとGIGABYTEは、ファームウェア自体に対象shimを同梱していないと説明しています。一方、Microsoft Corporation UEFI CA 2011を信頼するdbx未更新のシステムでは、USBメディアなどから脆弱なshimを持ち込まれる可能性があるとしており、CERT/CC上ではAffectedに分類されています。Baramundi Softwareはshim 0.8を含んでいた2024R1以下からの更新を求めており、CVE-2026-8863のみが該当します。IntelはCERT/CC上でNot Affectedに分類されていますが、詳細なベンダー声明は掲載されていません。SUSEは「該当shimを出荷していない」と回答していますが、CERT/CC上の総合ステータスはUnknownです。CERT/CCは通知対象を38ベンダーとして掲載しており、Red Hat、Oracle、Microsoft(およびMicrosoft Vulnerability Research)、Dell、HP、Lenovo、ASUS、Acer、Google、Amazonをはじめ多くはUnknownで、影響範囲の広さと確定的な棚卸しの難しさが浮かびます。

より深い問題:透明化されない過去の署名済みバイナリ

ESETは、shimの署名プロセスが2017年のshim-reviewリポジトリ導入によって大幅に透明化されたと説明しています。それ以降に承認されたshimは記録されていますが、それ以前に署名されたshimには公開記録がなく、現在も信頼されている古いshimの総数を正確に把握できていません。

Ars Technicaの取材に応じたファームウェアセキュリティ研究者でrunZero CEOのHD Moore氏は、今回の問題がSecure Bootの信頼モデル全体へ厳しい疑問を投げかけると評価しています。同氏は、実質的なルートオブトラストがMicrosoftである点、保護がスケールしない点、上位証明書の期限切れ後もコンポーネントが起動できてしまう点を根本的な問題として挙げ、Secure Bootを迂回する署名済みバイナリがMicrosoft以外に把握されない形で大量に残っている構造そのものへの再検討を求めています。HD Moore氏の発言はArs Technicaによる取材コメントであり、ESETの技術分析とは独立した見解ですが、可視性の欠如という指摘の中核部分は一致しています。

ESETは結びで、今回の11本の失効は目の前の問題への対処であり、より深い課題は「見えていないものは効果的に廃棄できない」という可視性の問題だと述べています。同時に、shim-review導入以降の署名分は少なくとも公開されており、SBATのような版単位失効機構と組み合わせれば、失効の追跡と実施は過去よりずっと現実的になっていくとしています。次の課題は、shim以外の第三者UEFIアプリケーション(CVE-2022-34302、CVE-2023-28005、CVE-2024-7344、CVE-2026-25250のような同種のSecure Boot迂回が繰り返し報告されてきた領域)にも同レベルの透明性を広げていくことだと締めくくられています。

運用担当者にとってのポイント

今回の事案は、Secure Bootという「起動の入口を守るはずの機構」が過去の署名済みバイナリの総体を守り切れていない現実を明るみに出しました。個別の11本を失効させることで直近のリスクは下がります。今回確認されたバイナリに対する直接的な対策は対象ハッシュのdbxへの反映ですが、過去の署名済みバイナリを網羅的に把握できていないという構造的な課題は残ります。運用側で押さえるべきポイントは次の3点に整理できます。

• 失効反映と更新順序:Windows/Linuxとも、対象ハッシュがdbxへ実際に反映されたかを確認し、大規模展開ではdb側の許可リストとブートコンポーネントを先に更新してからdbx失効を配布する順序を徹底します(詳細は前述)。
• 物理・媒体経由のリスク評価:攻撃はshimをESPに持ち込む必要があるため、USBブート、リカバリメディア、ラップトップの物理紛失といった経路が改めて重要になります。dbx更新の代替にはなりませんが、物理アクセスやオフラインでのブート改変に対する補助策として、TPM連動のディスク暗号化や起動時PINの運用も検討できます。
• アセット把握:失効された11本を含む製品(RHEL 7.2、CentOS 7.2、Oracle Linux 7.2、openSUSE系の古いイメージ、baramundi 2024R1以下、Blancco WipeDrive 8.0.0〜8.1.3、PC-Doctor Service Center 15/16、Spyrus WTGCreator、Finland Abitti 1、NTC IT ROSA R9/R10)を運用資産に持っている場合は、媒体を最新版に更新して失効反映後もブートできる状態を維持します。

UEFI Secure Bootを「有効化してあるから安全」と単純に読むのではなく、dbxの更新状況、SBATの世代番号、Microsoft固有のSecure Version Numbering(SVN)、OEM側の署名データベースの同期状況をあわせて確認する、という運用の粒度が求められる段階に入ってきたと言えます。

一次情報・公式情報

• ESET WeLiveSecurity: Forgotten UEFI shims undermining Secure Boot(Martin Smolár、2026年7月14日)
• CERT/CC Vulnerability Note VU#616257: Microsoft-signed UEFI shim bootloaders vulnerable to Secure Boot bypass
• Microsoft Security Response Center: CVE-2026-8863
• CVE Record: CVE-2026-10797
• Microsoft SecureBoot Objectsリポジトリ(DBX更新配布)
• Microsoft: Windows Secure Boot certificate expiration and CA updates
• Red Hat Bootloader Team: Secure Boot Advanced Targeting(SBAT)仕様
• shim upstream commit d241bbb(CVE-2026-10797修正コミット)
• CERT/CC uefi-dbx-auditスクリプト(Linux用dbx確認)

参考情報

• The Hacker News: 11 Old Microsoft-Signed Linux UEFI Shims Could Let Attackers Bypass Secure Boot
• Ars Technica: Microsoft’s Secure Boot has been broken for a decade and no one noticed until now
• Help Net Security: No one knows how many old shims can still bypass UEFI Secure Boot
• ESET WeLiveSecurity: BlackLotus UEFI bootkit — myth confirmed(2023年)
• ESET WeLiveSecurity: Bootkitty — Analyzing the first UEFI bootkit for Linux
• ESET WeLiveSecurity: Introducing HybridPetya — Petya/NotPetya copycat with UEFI Secure Boot bypass
• Eclypsium: There’s a Hole in the Boot(BootHole、CVE-2020-10713)