2026年6月のHyper-V RCE修正まとめ|対象ホスト・KB・確認手順

2026年6月9日のWindowsセキュリティ更新では、Windows Hyper-Vに関する3件のリモートコード実行(RCE)脆弱性が修正されました。管理者が最初に行うべき対応は、仮想マシンではなくHyper-VホストのOSに、2026年6月の累積更新プログラムまたはそれ以降を適用し、再起動後のOSビルドを確認することです。

今回の修正に伴うVM設定の変更や、仮想マシン構成バージョンの更新は基本的に必要ありません。一方、ゲストOSだけを更新してもホスト側の脆弱性は解消されないため注意が必要です。外部ユーザーや委託先が管理するVM、侵害される可能性が高いVMを収容しているホストは、特に優先して更新してください。(CVEAWG)

目次

2026年6月のHyper-V RCE修正で何が変わるのか

今回のHyper-V RCE fixesは、新機能の追加ではなく、Hyper-V内部のメモリ処理に関するセキュリティ修正です。

対象となるのは、次の3件です。

CVE主な問題攻撃に必要な条件CVSS
CVE-2026-45607境界外読み取りゲスト内でコードを実行できる攻撃者。追加権限は不要と評価8.4
CVE-2026-45641型の混同に関連する不正なメモリアクセスゲスト内でコードを実行できる攻撃者。追加権限は不要と評価8.4
CVE-2026-47652ヒープベースのバッファーオーバーフローゲスト内で高い権限を持つ攻撃者8.2

3件とも、悪用された場合はHyper-Vホスト側でコードが実行される可能性があります。CVE-2026-45607とCVE-2026-45641はゲスト内の追加権限を必要としない評価であるため、複数の利用者がVMを操作する環境では特に警戒が必要です。CVE-2026-47652は高い権限が必要ですが、仮想化境界を越えてホストへ影響し得る点は変わりません。(CVEAWG)

「RCE」でもインターネットから直接攻撃されるとは限らない

今回の脆弱性は、一般的なWebサーバーのRCEとは攻撃経路が異なります。

攻撃者は、まずHyper-V上のゲスト環境でコードを実行できる状態を作り、細工した処理をHyper-Vへ渡します。その結果、仮想マシンとホストの境界を越えて、ホスト側でコードが実行される可能性があります。

したがって、「ホストの管理ポートをインターネットに公開していないから安全」とは判断できません。インターネット公開されたシステムを動かすVMが侵害され、その後にホストへの攻撃へ進まれるケースも想定しておく必要があります。

影響を受けるHyper-Vホスト

Windows Serverでは、2026年6月9日の更新を基準にすると、次のOSビルド以降で修正を取り込めます。

ホストOS2026年6月の更新修正後のOSビルド関係するCVE
Windows Server 2016KB509412214393.9234CVE-2026-45607
Windows Server 2019KB509412317763.8880CVE-2026-45607
Windows Server 2022KB509412820348.52563件すべて
Windows Server 2025KB509412526100.329953件すべて

Windows Server 2022とWindows Server 2025は、今回取り上げる3件すべての対象です。Windows Server 2016と2019も安全というわけではなく、CVE-2026-45607への対応が必要です。Server Core環境も、該当するOSとビルドを利用している場合は確認対象に含めてください。(Microsoft サポート)

上表のKBと完全に一致していなくても、後日公開された累積更新プログラムを適用し、表より新しいOSビルドになっていれば修正は含まれます。資産管理では、KB番号だけでなく完全なOSビルド番号を確認することが重要です。

Windows 10・Windows 11のクライアントHyper-Vも確認する

開発用PCや検証端末でHyper-Vを有効にしている場合も、確認から除外できません。

主な2026年6月更新後のビルドは次のとおりです。

クライアントOS更新プログラム修正後のOSビルド
Windows 10 バージョン21H2KB509412719044.7417
Windows 10 バージョン22H2KB509412719045.7417
Windows 11 バージョン23H2KB509399822631.7219
Windows 11 バージョン24H2KB509412626100.8655
Windows 11 バージョン25H2KB509412626200.8655

CVEごとに対象バージョンやCPUアーキテクチャが異なるため、個別の適用可否を判断する場合はMSRCの対象製品一覧も照合してください。(CVEAWG)

更新を急ぐべきHyper-Vホストの判断基準

Microsoftが組織ごとの適用期限を指定しているわけではありません。実務では、ゲストが侵害される可能性と、ホスト侵害時の影響を基準に優先順位を決めます。

優先度該当する環境運用上の適用目安
最優先顧客・委託先・開発者が管理するVM、マルウェア解析環境、複数組織で共用するホスト検証後、72時間以内を目安に適用
高インターネット公開システムを収容する本番ホスト、VDI、重要な業務サーバー原則7日以内、または直近の緊急メンテナンス
通常Hyper-Vを有効にしているが、現在VMを稼働させていない端末次回の更新サイクルで確実に適用
要整理用途や管理者が不明なホスト、台帳に載っていない検証機先に所有者と稼働VMを特定し、その後更新

この期限はMicrosoft公式の期限ではなく、リスクに基づく運用上の目安です。特に、ゲスト内で任意のプログラムを実行できる利用者がいる環境では、通常の月例更新より優先度を上げるのが妥当です。

Hyper-Vホストの確認・更新手順

Hyper-Vの有効状態とOSビルドを確認する

Windows Serverでは、管理者権限のPowerShellで次を実行します。

Get-WindowsFeature -Name Hyper-V

クライアント版Windowsでは、次のコマンドを使用できます。

Get-WindowsOptionalFeature `
  -Online `
  -FeatureName Microsoft-Hyper-V-All

OSビルドは、リビジョン番号まで取得してください。

$os = Get-ItemProperty `
  'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'

[PSCustomObject]@{
    ProductName    = $os.ProductName
    DisplayVersion = $os.DisplayVersion
    Build          = "$($os.CurrentBuild).$($os.UBR)"
}

たとえばWindows Server 2022で20348.5256以上なら、2026年6月の修正を取り込んだビルドです。20348だけでは更新状況を判定できないため、ピリオド以降のリビジョン番号も必ず記録します。

稼働中のVMと退避先を確認する

更新前に、ホスト上の仮想マシンを確認します。

Get-VM |
  Select-Object Name, State, Status, ComputerName

フェールオーバークラスターでは、次の項目を事前に確認してください。

  • 退避先ノードにCPUとメモリの空きがあるか
  • ライブマイグレーションが正常に実行できるか
  • クラスター内の全ノードを同時に更新する計画になっていないか
  • 更新後の再起動が監視システムやバックアップ処理と重ならないか

ノードを一台ずつ処理する場合は、例として次のようにVMを退避します。

Suspend-ClusterNode -Name HV01 -Drain

更新と再起動が完了し、状態を確認した後にノードを復帰させます。

Resume-ClusterNode -Name HV01

単一ホスト構成ではライブマイグレーションによる退避ができません。VMの正常停止、バックアップの成否、業務停止時間を確認してから作業してください。

ホストOSへ累積更新プログラムを適用する

更新は、組織で利用している管理方式に合わせて配布します。

  • Windows Update
  • Windows Server Update Services(WSUS)
  • Microsoft Configuration Manager
  • Microsoft Update Catalog
  • Azure Update Managerなどの更新管理サービス

Hyper-V専用の修正パッケージを別に探す必要はありません。対象OSの2026年6月累積更新プログラム、またはそれ以降の累積更新プログラムをホストへ適用します。

再起動後に修正済みビルドを確認する

更新ファイルをインストールしただけで、再起動を保留している状態は対応完了ではありません。

再起動後に、次の項目を確認します。

  • OSビルドが修正済みの値以上になっている
  • Hyper-V関連サービスが正常に起動している
  • 仮想マシンを起動できる
  • 仮想スイッチとネットワーク通信が正常
  • クラスターのノードとリソースが正常
  • ライブマイグレーションを実行できる
  • バックアップやレプリケーションにエラーがない

最終確認では、更新前と同じPowerShellコマンドで完全なOSビルドを取得し、作業記録へ残してください。

設定・移行・料金・期限で確認すべきこと

項目今回の対応
設定通常はレジストリ変更や仮想スイッチの再作成は不要。ホストOSの更新が中心
更新2026年6月の累積更新、またはそれ以降をホストへ適用して再起動
VM移行脆弱性対応だけを目的としたVM形式の変換や構成バージョン更新は不要
ホスト移行サポート終了が近いOSでは、更新適用と並行して新しいWindows Serverへの移行を計画
料金サポート中のWindowsに対する単体の有料Hyper-Vパッチではない。OSライセンスやESUの条件は別途確認
期限Microsoftによる一律の適用期限はない。ゲストの信頼度と業務影響から社内期限を設定

Windows Server 2016は移行計画も始める

Windows Server 2016の延長サポートは2027年1月12日に終了予定です。2026年6月の修正を適用すれば今回のCVEには対応できますが、今後も長期間Hyper-Vホストとして使い続けるなら、Windows Server 2022またはWindows Server 2025などへの移行計画を並行して進める必要があります。

Windows Server 2019の延長サポート終了予定日は2029年1月9日です。移行の緊急度はServer 2016より低いものの、ハードウェア更新やゲストOSの要件と合わせてロードマップを作成しておくと、サポート終了直前の集中作業を避けられます。(Microsoft Learn)

Windows 10ホストではESUの加入状況を確認する

一般的なWindows 10環境は2025年10月14日にサポートを終了しています。2026年6月のセキュリティ更新を受け取るには、対象エディションのサポート状況やExtended Security Updates(ESU)への登録状況を確認する必要があります。(Microsoft Learn)

組織・企業向けWindows 10 ESUは、Microsoftの案内では初年度が1台あたり61米ドルで、価格は最長3年間、年ごとに倍増する仕組みです。実際の購入価格、税、契約条件、対象エディションは販売店やライセンス契約で確認してください。(Microsoft Learn)

Hyper-V更新で失敗しやすいポイント

ゲストOSだけを更新して完了と判断する

今回修正すべきなのはHyper-Vホスト側です。すべてのゲストOSが最新でも、ホストが古いビルドのままなら脆弱性は残ります。

資産管理表では、次の情報を分けて管理してください。

  • Hyper-VホストのOSとビルド
  • 各ゲストOSのバージョンと更新状態
  • VMの管理責任者
  • ホストの再起動日
  • 更新後の動作確認結果

KB番号だけで未適用と判定する

後続の累積更新プログラムを適用すると、2026年6月のKBが一覧に表示されない場合があります。

「KB5094128がないから未対応」と機械的に判断せず、Windows Server 2022なら20348.5256以上かどうかを確認してください。最新の累積更新へ進んでいれば、過去の修正も含まれます。

再起動を先送りする

Hyper-Vホストは停止影響が大きいため、更新のインストールだけを行い、再起動を長期間保留しがちです。しかし、更新されたHyper-Vコンポーネントが読み込まれるまでは、修正が有効にならない可能性があります。

更新の配布日と再起動完了日を別々に記録し、再起動待ちのホストを可視化してください。

クラスター全ノードを同時に更新する

複数ノードを同時に再起動すると、VMの退避先がなくなり、サービス全体が停止するおそれがあります。

原則として、次の順序で一台ずつ処理します。

  1. ノードを一時停止する
  2. VMを別ノードへ退避する
  3. 更新を適用する
  4. 再起動する
  5. ホストとVMの動作を確認する
  6. ノードをクラスターへ復帰させる
  7. 次のノードへ進む

チェックポイントをバックアップ代わりにする

Hyper-Vチェックポイントは、ホスト障害やストレージ障害に備える完全なバックアップではありません。更新前には、バックアップジョブの成功履歴と復元手順を確認してください。

よくある疑問

Hyper-Vを使っていないPCも更新すべきか

Hyper-Vを明示的に利用していない場合でも、月例累積更新にはHyper-V以外のセキュリティ修正も含まれます。Hyper-Vを使っていないことを理由に、Windowsのセキュリティ更新そのものを延期するべきではありません。

仮想マシン構成バージョンの更新は必要か

今回のRCE修正を適用するために、VMの構成バージョンを上げる必要はありません。構成バージョンの更新は、移行先ホストとの互換性や必要な機能を確認したうえで、別の変更作業として判断します。

VHDをVHDXへ変換する必要はあるか

脆弱性修正だけを目的としたディスク形式の変換は不要です。VHDからVHDXへの変換には別のメリットがありますが、今回のHyper-V RCE対応とは分けて計画してください。

仮想マシンを停止せずに更新できるか

フェールオーバークラスターでライブマイグレーションが利用できれば、VMを別ノードへ移動しながらホストを一台ずつ更新できます。

単一ホスト構成では、ホスト再起動中にVMを稼働させ続けることはできません。計画停止、別ホストへの移行、冗長化のいずれかが必要です。

2026年6月より新しい累積更新でもよいか

問題ありません。Windowsの月例更新は累積型であるため、2026年6月の修正を含む、より新しい累積更新プログラムを適用できます。古いKBを個別に探すより、現在提供されている最新のセキュリティ更新を適用する方が適切です。

まずホスト一覧とOSビルドを確認する

今回のHyper-V RCE修正で重要なのは、ゲストOSの更新状況ではなく、Hyper-Vホストが修正済みのOSビルドになっているかを確認することです。

最初に次の4点を実行してください。

  1. Hyper-VホストとクライアントHyper-V端末を一覧化する
  2. 完全なOSビルド番号を取得して修正済みビルドと比較する
  3. 検証用ホストから累積更新と再起動を実施する
  4. 本番クラスターを一台ずつ更新し、結果を記録する

特にWindows Server 2022とWindows Server 2025は3件すべての対象です。信頼できないゲストや、外部から侵害される可能性があるVMを収容するホストから優先してください。Windows Server 2016を使っている場合は、今回の更新を適用すると同時に、2027年1月のサポート終了を見据えた移行計画も具体化する必要があります。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次