2026年6月9日、MicrosoftはWindows Secure BootとWindows Boot Managerに関する3件のセキュリティ機能バイパス脆弱性を公開しました。結論として、対象端末では2026年6月の累積セキュリティ更新、またはそれ以降の累積更新を適用し、修正済みビルドに到達していることを確認する必要があります。(Microsoft Security Response Center)
ただし、月例更新の適用だけで作業完了とは限りません。2026年6月から始まるSecure Boot証明書の更新は別の確認項目です。管理者は「OSの脆弱性修正」「Secure Bootの有効状態」「2023年証明書への移行」「更新済みBoot Manager」の4点を分けて確認してください。
2026年6月のSecure Boot bypass fixesで何が変わったのか
今回確認すべき脆弱性は次の3件です。
| CVE | 対象コンポーネント | 公開された内容 | CVSS |
|---|---|---|---|
| CVE-2026-45588 | Windows Secure Boot | ローカルの権限を持つ攻撃者によるセキュリティ機能の回避 | 7.9 |
| CVE-2026-47656 | Windows Boot Manager | ローカルの権限を持つ攻撃者によるセキュリティ機能の回避 | 7.9 |
| CVE-2026-48568 | Windows Secure Boot | ローカルの権限を持つ攻撃者によるセキュリティ機能の回避 | 7.9 |
3件はいずれもCWE-693「Protection Mechanism Failure」に分類されています。公開されたCVSSベクトルも共通しており、攻撃元はローカル、必要権限は高、ユーザー操作は不要です。機密性と完全性への影響が高く評価される一方、可用性への直接的な影響は評価されていません。(NVD)
少なくとも公開情報上は、インターネットから未認証で直接侵入するタイプの脆弱性ではありません。しかし、すでに管理者権限を取得した攻撃者が起動時の信頼関係を回避できる可能性があるため、軽視は禁物です。
特に優先度を上げたいのは、次のような端末です。
- ドメイン管理者やサーバー管理者が日常的に使用する端末
- BitLockerを利用しているPC
- ドメインコントローラーや認証基盤
- リモート管理用の踏み台サーバー
- デュアルブート、独自ブートローダー、特殊なOption ROMを使用する端末
- Secure Bootを有効にした仮想マシンやVDI
- OEMサポートが終了した古い機種
まず確認すべき4項目
| 確認項目 | 合格条件 | よくある見落とし |
|---|---|---|
| OSの更新状況 | 修正済みビルド以上 | KBが表示されていても再起動未完了 |
| Secure Bootの状態 | 有効になっている | 無効化を暫定回避策にしてしまう |
| 証明書とBoot Manager | 2023年証明書と更新済みBoot Managerが適用済み | 緑色のアイコンだけで判断する |
| ファームウェアと展開イメージ | 対象機種、VM、WinPE、インストールメディアまで検証済み | 稼働中OSだけを更新する |
ここで重要なのは、CVE修正とSecure Boot証明書移行は関連しているものの、同じ完了条件ではないことです。修正済みOSビルドでも証明書が古い場合があり、反対に新しい証明書が入っていても、更新済みBoot Managerが未適用の可能性があります。
影響を受けるWindowsと修正KB・ビルド
本稿で扱う3件のCVEでは、次のWindowsクライアントおよびWindows Serverが対象として示されています。
| Windowsバージョン | 2026年6月の更新 | 修正済みビルド |
|---|---|---|
| Windows Server 2012 | KB5094042 | 6.2.9200.26132 |
| Windows Server 2012 R2 | KB5094041 | 6.3.9600.23228 |
| Windows 10 Version 1607／Windows Server 2016 | KB5094122 | 14393.9234 |
| Windows 10 Version 1809／Windows Server 2019 | KB5094123 | 17763.8880 |
| Windows 10 Version 21H2 | KB5094127 | 19044.7417 |
| Windows 10 Version 22H2 | KB5094127 | 19045.7417 |
| Windows 11 Version 23H2 | KB5093998 | 22631.7219 |
| Windows 11 Version 24H2 | KB5094126 | 26100.8655 |
| Windows 11 Version 25H2 | KB5094126 | 26200.8655 |
| Windows 11 Version 26H1 | KB5095051 | 28000.2269 |
| Windows Server 2022 | KB5094128 | 20348.5256 |
| Windows Server 2025 | KB5094125 | 26100.32995 |
修正ビルドの境界はMicrosoftがCVE情報として提供した製品データと一致します。表より新しい累積更新を適用し、ビルド番号が表の値以上であれば、この3件の修正を含むと判断できます。(NVD)
各KBのリリース日とビルド番号はMicrosoftの更新履歴でも確認できます。(マイクロソフトサポート) (マイクロソフトサポート)
Windows Server 2012と2012 R2はESU対象です。Windows 10 Version 21H2／22H2向けのKB5094127も、Windows 10 ESU、Enterprise LTSC 2021、IoT Enterprise LTSC 2021などが適用先となっています。通常サポートが終了したエディションでは、OSが存在するだけでは更新を受け取れません。ESUの登録状況やエディション、ライセンス条件を確認してください。(マイクロソフトサポート)
一般ユーザーが確認する手順
Windows Updateを実行して再起動する
Windows 11では、次の順に開きます。
- 「設定」を開く
- 「Windows Update」を選択する
- 「更新プログラムのチェック」を実行する
- 累積更新をインストールする
- 再起動を求められた場合は再起動する
- 「更新の履歴」でインストール結果を確認する
2026年6月のKBそのものではなく、それより新しい累積更新が入っている場合も修正は含まれます。KB番号だけでなく、最終的なOSビルドを確認するのが確実です。
OSビルドを確認する
WindowsキーとRキーを押し、次を入力します。
winver表示されたOSビルドを、前述の修正済みビルドと比較してください。
PowerShellで完全なビルド番号を取得する場合は、次のコマンドを使用できます。
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"{0}.{1}" -f $cv.CurrentBuild, $cv.UBRたとえばWindows 11 Version 24H2で26100.8655以上なら、今回の3件については修正済みの範囲です。
Secure Bootが有効か確認する
管理者権限でPowerShellを開き、次を実行します。
Confirm-SecureBootUEFITrueならSecure Bootは有効です。Falseなら無効です。Legacy BIOSで起動している端末、UEFI Secure Bootに対応していない端末、管理者権限がない環境ではエラーになる場合があります。MicrosoftもこのコマンドをSecure Bootの確認方法として案内しています。(マイクロソフトサポート)
Secure Bootが無効な端末では、2023年証明書の展開手順は適用対象外です。ただし、Secure Bootが無効だから月例セキュリティ更新も不要という意味ではありません。OS更新は通常どおり適用してください。
Windowsセキュリティで証明書の状態を見る
対応端末では、次の画面からSecure Boot証明書の状態を確認できます。
Windows セキュリティ
> デバイス セキュリティ
> セキュア ブート注意したいのは、緑色のチェックマークだけでは証明書更新済みと断定できない点です。「必要な証明書更新がすべて適用されている」という趣旨のメッセージまで確認してください。
Microsoftが定義する「完全に更新済み」の状態には、新しい証明書だけでなく、更新済みBoot Managerのインストールも含まれます。企業管理端末やWindows Serverでは、バッジや通知が既定で無効になっている場合があるため、管理者は画面表示だけに依存しないようにしてください。(マイクロソフトサポート)
管理者向けの安全な展開手順
資産情報を先に収集する
最初に、少なくとも次の情報を一覧化します。
- OS名、エディション、バージョン、ビルド番号
- Secure Bootの有効・無効
- メーカー、機種、マザーボード
- BIOS／UEFIファームウェアのバージョン
- 物理端末か仮想マシンか
- BitLockerの利用状況と回復キーの保管先
- デュアルブートや独自EFIアプリケーションの有無
- ESU対象OSのライセンス状態
Secure Boot証明書の更新にはデバイスのファームウェアが関与します。同じWindowsバージョンでも、メーカー、機種、BIOSバージョンが異なれば結果が変わる可能性があります。
機種とファームウェアごとに先行検証する
全端末へ一斉配信せず、メーカー、モデル、BIOSバージョンごとに代表端末を選びます。Microsoftの管理者向けガイダンスでは、固有のハードウェア構成ごとに4台以上を目安として検証する方法が示されています。(マイクロソフトサポート)
先行グループでは、次の項目を確認します。
| 確認場面 | テスト内容 |
|---|---|
| 更新前 | BitLocker回復キー、Secure Boot状態、現在の証明書状態を記録 |
| 更新中 | 更新プログラムの成功、保留中の再起動、イベントログを確認 |
| 再起動後 | 通常起動、BitLocker回復画面の有無、ネットワーク接続を確認 |
| 業務確認 | VPN、EDR、ディスク暗号化、PXE、業務アプリを確認 |
| 特殊構成 | Linuxデュアルブート、独自WinPE、Option ROM、外部起動を確認 |
OS更新と証明書更新を別々に監視する
OS更新は、修正済みビルドへの到達をもって確認します。
一方、証明書移行では次の処理が段階的に行われます。
- Windows UEFI CA 2023をDBへ追加
- 必要に応じてMicrosoft UEFI CA 2023とOption ROM用証明書を追加
- Microsoft Corporation KEK 2K CA 2023を追加
- 2023年証明書で署名されたWindows Boot Managerを適用
- 再起動後に処理結果を再確認
各工程は前の工程が成功してから進みます。対象化された端末ではスケジュールタスクが12時間ごとに処理を試行し、完了まで48時間程度と複数回の再起動が必要になる場合があります。(マイクロソフトサポート)
イベントログでは、次のイベントIDが判断材料になります。
| イベントID | 意味 |
|---|---|
| 1801 | 更新された証明書が端末に適用されていないことを示すエラー |
| 1808 | 必要な新しいSecure Boot証明書がファームウェアへ適用されたことを示す情報 |
イベント1808だけでなく、OSビルドとBoot Managerの状態も合わせて確認してください。新しい端末には2023年証明書が入っていても、2023年証明書で署名されたBoot Managerが未適用の場合があります。(マイクロソフトサポート)
ファームウェアと仮想環境も確認する
証明書更新が進まない場合、Windows側の再試行だけでは解決しないことがあります。OEMが提供するBIOS／UEFIファームウェアを確認してください。
仮想マシンでは、ゲストOSだけでなく仮想UEFIの証明書ストアも関係します。Hyper-V、VMware、Azure、AWSなどでは、仮想基盤側の更新や新しいVMテンプレートが必要になる場合があります。長期稼働VMは、仮想ファームウェアがSecure Boot変数の更新を受け入れられるか確認します。(マイクロソフトサポート)
WinPEやインストールメディアを放置しない
稼働中OSだけを更新し、次の資産を古いまま残すのは典型的な失敗です。
- WinPE
- Windows回復環境
- OS展開用イメージ
- ゴールデンイメージ
- USBインストールメディア
- PXE起動用ファイル
- 仮想マシンテンプレート
特にWindows Server 2012／2012 R2の2026年6月更新では、既存イメージへ更新を統合する際、Windowsのバージョンとアーキテクチャに一致するboot.stlをインストールメディアへ含めるよう案内されています。不一致や欠落があると、メディアから起動できず0xc0430001が発生する可能性があります。また、Server 2012ではSSU KB5079234、Server 2012 R2ではSSU KB5079233の承認・適用も確認が必要です。(マイクロソフトサポート)
CVE修正と2023年証明書への移行は別作業
2026年6月の累積更新は、今回のWindows Secure Boot／Windows Boot Manager脆弱性を修正します。
一方、証明書移行は、2011年に発行されたSecure Boot関連証明書の有効期限切れに備え、UEFIのDBやKEKを2023年版へ切り替える作業です。
| 旧証明書 | 有効期限 | 新証明書 | 主な役割 |
|---|---|---|---|
| Microsoft Corporation KEK CA 2011 | 2026年6月24日 | Microsoft Corporation KEK 2K CA 2023 | DB／DBX更新への署名 |
| Microsoft UEFI CA 2011 | 2026年6月27日 | Microsoft UEFI CA 2023 | サードパーティ製ブートローダーやEFIアプリの署名 |
| Microsoft UEFI CA 2011 | 2026年6月27日 | Microsoft Option ROM UEFI CA 2023 | サードパーティ製Option ROMの署名 |
| Microsoft Windows Production PCA 2011 | 2026年10月19日 | Windows UEFI CA 2023 | Windowsブートローダーの署名 |
DBだけでなくKEKも更新が必要です。(マイクロソフトサポート)
証明書の有効期限を迎えた瞬間に、すべてのPCが起動不能になるわけではありません。新しい証明書を受け取っていない端末でも、当面は起動し、通常のWindows Updateもインストールされます。
問題は、Windows Boot Manager、Secure Bootデータベース、失効リスト、起動レベルの新しい脆弱性対策などを受け取れなくなる可能性があることです。時間がたつほど起動前の保護が陳腐化し、BitLocker強化やサードパーティ製ブートローダーにも影響が及ぶおそれがあります。(マイクロソフトサポート)
証明書期限への対処としてSecure Bootを無効にするのは避けてください。 起動はしやすくなっても、ブートキットや未承認コードを防ぐ保護そのものを失います。
設定・移行・料金・期限で誤解しやすいポイント
LimitSecureBootRequiredServiceDataはCVEの緩和策ではない
一部の2026年6月更新では、次の場所にLimitSecureBootRequiredServiceDataポリシーが追加されています。
コンピューターの構成
> 管理用テンプレート
> Windows コンポーネント
> Secure Bootこの設定は、Microsoftへ送信されるSecure Boot関連のサービスデータを制限するためのものです。CVE-2026-45588などを修正したり、証明書を更新したりする設定ではありません。ポリシーを有効にしても、月例更新の適用は必要です。(マイクロソフトサポート)
証明書を手作業で一括投入しない
UEFI証明書は起動の信頼関係そのものを構成します。MicrosoftやOEMの手順を確認せず、独自スクリプトやUEFI設定画面からDB、DBX、KEKを一括変更するのは危険です。
特に、独自PKI、Linux、特殊なOption ROM、ネットワークブートを使用する環境では、信頼する証明書を誤って削除すると起動不能や機器認識失敗につながります。まず代表端末で検証し、イベントログを監視しながら段階的に展開してください。
修正プログラム単体の追加料金はない
サポート対象のWindowsでは、今回の修正は通常の累積セキュリティ更新として配信されます。CVEごとに別料金が請求されるものではありません。
料金が発生し得るのは、主に次のケースです。
- Windows 10 ESUへの登録が必要
- Windows Server 2012／2012 R2のESUが必要
- Intune、Configuration Managerなどの管理基盤を追加する
- OEMの延長保守やファームウェア対応を依頼する
- サポート切れ端末を更新可能な機種へ交換する
ESUの価格や契約方法は、エディション、契約年、ライセンス形態、クラウド利用状況などで異なります。固定額を前提にせず、契約先とMicrosoftの最新条件を確認してください。
Windows Server 2012／2012 R2はOS移行も急ぐ
Windows Server 2012と2012 R2のESU最終日は2026年10月13日です。これはWindowsブートローダーに使われる旧証明書の有効期限である2026年10月19日より前です。
2026年6月更新を適用しても、古いサーバーを長期運用できるようになるわけではありません。Secure Boot対応と並行して、Windows Server 2022や2025など、サポート対象OSへの移行計画を進める必要があります。(マイクロソフトサポート)
よくある疑問
Secure Bootが無効なら今回の脆弱性を無視できる？
無視できません。Secure Boot証明書の展開処理は対象外になりますが、月例セキュリティ更新は適用してください。
Secure Bootを新たに有効化する場合は、UEFI起動、GPTディスク、BitLocker、周辺機器、独自ブートローダーとの互換性を事前に確認します。既存端末で設定だけを突然切り替えるのは避けてください。
2026年6月のKBを入れれば証明書移行も完了する？
必ずしも完了しません。
KBの適用はCVE修正の確認項目です。証明書移行では、UEFIのDBとKEK、新しい証明書、更新済みBoot Managerまで確認する必要があります。自動展開の対象になっていない端末や、ファームウェアに制約がある端末では別途対応が必要です。
緑色のチェックが出ていれば安全？
緑色のアイコンだけでは不十分です。
Windowsセキュリティに「必要な証明書更新がすべて適用済み」と表示され、更新済みBoot Managerがインストールされていることを確認してください。管理対象端末では通知やバッジが無効な場合もあります。
仮想マシンも確認が必要？
Secure Bootを利用する仮想マシンは確認対象です。
ゲストOSの更新に加え、仮想UEFI、ホストやクラウド基盤、VMテンプレート、ゴールデンイメージを確認してください。新規作成VMだけが更新され、既存の長期稼働VMが古い証明書のまま残るケースにも注意が必要です。
証明書の期限を過ぎるとすぐ起動しなくなる？
Microsoftの案内では、未更新端末も引き続き起動し、標準のWindows Updateを受け取れます。ただし、新しい起動時保護やBoot Manager更新を受けられなくなる可能性があります。
「起動できるから問題ない」ではなく、「今後のブート関連セキュリティ更新を受けられるか」で判断してください。
管理者が今行うべき対応
最初に、全端末のOSビルドとSecure Boot状態を収集します。続いて、2026年6月更新またはそれ以降の累積更新を適用し、表に示した修正済みビルド以上であることを確認してください。
その後、2023年証明書と更新済みBoot Managerの状態を確認します。未更新端末は、メーカー、機種、BIOSバージョンごとに分類し、少数の代表端末から段階的に展開します。
最終的な完了条件は、次の4点です。
- OSが修正済みビルド以上
- Secure Bootが意図した状態で有効
- 必要な2023年証明書と更新済みBoot Managerが適用済み
- 物理端末、VM、WinPE、展開イメージで起動テストが完了
2026年6月のSecure Boot bypass fixesは、単にWindows Updateを実行するだけの案件ではありません。OSの修正状況と起動時の信頼基盤を分けて管理することが、更新漏れや将来のブート保護停止を防ぐ最も確実な方法です。
コメント