CVE-2026-8863：マイクロソフト署名のUEFI shimブートローダーを武器化するセキュアブートバイパス

マイクロソフトは2026年6月9日のパッチチューズデーにおいて、UEFIセキュアブートのセキュリティ機能バイパスの脆弱性「CVE-2026-8863」を公開しました 。この脆弱性の核心は、複数のマイクロソフト署名済みUEFI shimブートローダーにあります。これらのブートローダーは、有効な暗号署名を持つがゆえにセキュアブートから信頼されてしまいます。しかし、そのブートローダーが古く、欠陥を含む場合、攻撃者はオペレーティングシステム(OS)が読み込まれる前の段階で任意のコードを実行できてしまうのです 。これは、OSの信頼基盤を確立するというセキュアブートの根本的な約束を骨抜きにするものであり、攻撃者がブート前環境を標的にする長年の傾向を継続するものです。

欠陥のあるサプライチェーン：署名は有効、されど忘れ去られる

CVE-2026-8863の本質は、サプライチェーンの問題です。脆弱なコンポーネントは、オープンソースプロジェクト shim 由来のブートローダー群です。shimは、UEFIファームウェアと、LinuxシステムにおけるGRUB2のような完全なブートローダーとの橋渡し役となる小さなアプリケーションです。マイクロソフトは、Linuxディストリビューションやその他サードパーティーOSのセキュアブート互換性を確保するために、過去にshimの各バージョンに署名を付与していました 。

主な影響を受けるバージョンは、shim 0.9以前です。重要なのは、これらの古いバージョンには、Secure Boot Advanced Targeting (SBAT) 機構の適切な強制と検証が欠如していた点です 。SBATとは、特定の脆弱なブートローダーの世代のみを無効化し、ベンダーの署名証明書全体を失効させる必要をなくすための失効フレームワークです 。これらの古いshimはSBATを考慮しないため、既知の脆弱性が発見され、安全な新しいshimがリリースされた後も、実行可能な状態で残り続けました 。

これらの脆弱なブートローダーが実環境に残存するのは、オープンソースのshimを自社製品向けにフォーク（分岐開発）したものの、更新を怠った様々なハードウェア・ソフトウェアベンダーの存在が原因です。Positive Technologies社は、WhiteCanyon WipeDrive、Baramundi Management Suite、PC-Doctor Service Center、フィンランドの大学入学資格試験システム「Abiti」など、影響を受ける具体的な製品を特定しました 。これらのサードパーティーツールは、古いマイクロソフト署名済みshimをEFIシステムパーティションにインストールするため、メインOSが完全にパッチ適用された後も、システムに恒久的なバックドアを残す結果となりました 。

攻撃手法：ブートローダー版BYOVD

CVE-2026-8863の悪用は、リモートからの非認証攻撃ではありません。脅威アクターはまず、標的マシン上で管理者権限を取得するか、ブートプロセスを変更する能力を手に入れる必要があります 。このアクセスが確立されると、攻撃者は「Bring Your Own Vulnerable Driver (BYOVD)」スタイルのテクニックを活用します。これは、カーネルドライバの代わりに、脆弱でありながら正規のマイクロソフト署名がなされたshimブートローダーをブートパスに配置する手法です。

セキュアブートが有効な状態でシステムが起動する際、UEFIファームウェアはshimのデジタル署名をチェックし、それが有効である（信頼できる「Microsoft UEFI CA 2011」証明書で署名されている）と判断し、実行してしまいます 。攻撃者は、この古いshimを利用してブートプロセスを迂回させ、Windowsやセキュリティソフトウェアが初期化される前に悪意のあるペイロードを読み込むことができます。これにより、マシン動作の最も初期の段階でシステムを完全に制御下に置く、いわゆるOS起動前の任意コード実行が可能となります 。

OS起動前のコード実行リスク：永続的かつ除去困難

OS起動前のコード実行能力は、MITRE ATT&CK フレームワークのテクニック T1542.003 — Pre-OS Boot: Bootkit (OS起動前のブート：ブートキット) に直接分類されます 。ブートキットとは、OSの層よりも下で動作するマルウェアの一種であり、OSの再インストール後も生き残り、従来のウイルス対策ソフトの大半による検知を回避できる、ステルス性の高い永続化メカニズムを提供します 。

CVE-2026-8863を介した攻撃が成功すると、攻撃者はBitLocker (ドライブ暗号化機能) を無効化したり、OSカーネルに悪意のあるコードを注入したり、システム起動のたびに実行される永続的なバックドアを確立したりできる可能性があります。ブートキット感染の修復は非常に困難で、多くの場合、システムファームウェアの完全な再書き込みが必要となるため、この脆弱性は悪用にローカルアクセスが必要であるにも関わらず、企業のセキュリティチームにとって優先度の高い懸念事項です。Rapid7社の評価では、この脆弱性はCVSS v3.1基本スコア 7.8 とされ、悪用可能性は「低い」と分類されつつも、機密性、完全性、可用性への技術的影響は「高」と評価されています 。

UEFIの信頼問題の歴史

CVE-2026-8863は孤立した事例ではなく、UEFIブートプロセスの安全性確保という継続的な戦いにおける最新の一章です。この手法は、同じくセキュアブートバイパスを許し、大規模なDBXアップデートでの修正を余儀なくされた、2020年のGRUB2における「BootHole」脆弱性 (CVE-2020-10713) や 、Windowsブートローダーの欠陥を悪用して同様のOS起動前永続化を達成した「BlackLotus」ブートキットなどを彷彿とさせます 。

この問題は、同時期に発生している大規模な信頼期限切れイベントによってさらに複雑化しています。脆弱なshimやその他無数のサードパーティーブートコンポーネントに署名した Microsoft Corporation UEFI CA 2011証明書 自体が、2026年6月27日に失効予定だったのです 。マイクロソフトは、エコシステム全体に対して新しい2023年版証明書への移行を推進していましたが、これは多くの組織にとって、CVE-2026-8863が公開された時点でまだ進行中の複雑な作業でした 。

修復と企業導入における注意点

CVE-2026-8863の修正は、単純なWindows Updateのパッチではありません。中心的な緩和策は、UEFI禁止署名データベース (DBX) の更新です。これは、脆弱なshimブートローダーの暗号化ハッシュをファームウェアの失効リストに追加するものです。一度適用されると、それらのブートローダーが有効に署名されていても、UEFIファームウェアは実行を拒否します 。

企業のITおよびセキュリティチームがDBXアップデートを展開するには、慎重な計画が必要です。

1. まずDBXアップデートをテスト展開する： 本番環境ではないテストグループに更新プログラムを展開し、古いshimをブロックしても、特に影響を受けるサードパーティーブートローダーに密かに依存している可能性のある重要なシステムが起動不能にならないことを確認します 。
2. サードパーティー製ブートローダーを監査する： インベントリツールを使用してEFIシステムパーティションをスキャンし、特定の脆弱なブートローダーが存在しないか調べます。Positive Technologies社が公開した、ディスク消去、システム管理、ハードウェア診断などに使用されるツールを含む影響製品リストと、調査結果を照合します 。
3. デュアルブートおよびLinuxシステムを検証する： WindowsとLinuxをデュアルブートしているシステム、特に古いディストリビューションのリリースを使用しているシステムは、DBXアップデート後に起動できなくなるリスクが高いです。失効措置を強制する前に、インストールされているすべてのLinuxディストリビューションが、脆弱性のない最新バージョンのshimブートローダーに移行していることを確認してください 。
4. ソフトウェアベンダーと連携する： 特定された影響を受けるブートローダー（WhiteCanyonやBaramundiなど）のベンダーに連絡し、古いものをブロックする前に、更新されたセキュアブート互換バージョンのツールを入手します 。
5. BitLocker回復の準備をする： セキュアブートの設定変更は、BitLocker回復キーの入力を求めるプロンプトを表示させる可能性があります。DBXアップデートを展開する前に、回復キーがバックアップされ、ヘルプデスクがアクセスできる状態であることを確認し、大規模なロックアウトを回避してください。
6. 更新リングを使用して展開を段階的に行う： IT部門、パイロットユーザー、そして全社展開といった段階的アプローチを使用し、各段階でブートの完全性に問題がないか監視します。

CVE-2026-8863の脆弱性は、セキュアブートの保護機能は、それが信頼するサードパーティーの署名済みコードエコシステムの強度に依存する、ということを如実に示しています。ブート前環境の注意深い監査と、DBX失効リストの迅速な適用は、プラットフォームの完全性を維持するための、今や不可欠かつ継続的なタスクとなっています。