VMwareの脆弱性とセキュリティ対策｜悪用済みCVE一覧とVMSAの確認・パッチ手順【2026年10月】

VMware製品のセキュリティで最初に守るべきなのは、仮想基盤の管理サーバーであるvCenterと、ハイパーバイザーのESXiです。vCenterはネットワークから届くだけで認証前にコードを実行される脆弱性が繰り返し見つかっており、ESXiは仮想マシンの中からホストへ抜け出す「VMエスケープ」とランサムウェアの標的になってきました。本記事は旧版で扱ったCVE-2024-38812を起点に、2026年10月時点で悪用が確認されているVMware脆弱性の一覧、Broadcomのセキュリティアドバイザリ（VMSA）の読み方、自社環境が対象かを判定する手順、パッチを当てるまでの防御をまとめた更新型のリファレンスです。

まとめ：VMware脆弱性への対応で押さえる5つの要点

• 一次情報はVMSA：Broadcomが公開するVMSAの「Response Matrix」にある修正版と、自社のビルド番号を突き合わせる。パッチは同じ製品・更新系列内では累積型なので、該当系列の修正版以降を選ぶ。
• 優先度はCVSSより悪用実績：CVSS 6.8（Moderate）のCVE-2024-37085もランサムウェアに悪用された。CISAのKEVとVMSAのNotes欄を必ず見る。
• VMSAは改訂される：CVE-2024-38812は初回パッチが不完全で約1か月後に差し替え、CVE-2024-37079は公開から約19か月後に「悪用あり」が追記された。改訂番号（.1、.2）を追う。
• パッチが届かない版がある：vSphere 7は2025年10月2日に一般サポートが終了し、パッチは延長サポート契約者向け。サポート切れの永続ライセンスで無償入手できるのはvSphere 8.xのCVSS 9.0以上だけ。
• パッチまでの間は管理面を閉じる：VMSAの回避策は「None」が多い。vCenterとESXiの管理インターフェイスを許可したネットワークだけに絞り、ロックダウンモードなどのハードニングで時間を稼ぐ。

以下、脆弱性の傾向、悪用済みCVEの一覧、VMSAの読み方、判定と適用の手順の順に説明します。

VMware製品が狙われる2つの攻撃経路と仮想基盤全体への影響

ここでは、仮想基盤全体への影響が大きいvCenterの認証前コード実行と、ESXiのVMエスケープという2つの攻撃経路を取り上げます。どちらの型かで、急ぐべき度合いと守る場所が変わります。

vCenter：ネットワークに届くだけで成立する認証前のコード実行

CVE-2024-38812、CVE-2024-37079、CVE-2023-34048はいずれもvCenterのDCERPCプロトコル実装の欠陥で、「vCenterにネットワーク到達できる攻撃者」が細工したパケットを送るだけでリモートコード実行に至ります（CVSS 9.8）。2026年7月公開のCVE-2026-59310もvCenterのSyslogサーバー部分のディレクトリトラバーサルで、同じく認証なしで任意コード実行が可能です。CVE-2023-34048については、MandiantとVMwareが、中国系のスパイ活動グループUNC3886が遅くとも2021年後半から悪用していたと公表しています。vCenterは全ESXiホストと仮想マシンを操作できるため、1台の侵害が基盤全体の掌握に直結します。

ESXi：仮想マシンからホストへ抜けるVMエスケープと暗号化被害

2025年3月のVMSA-2025-0004では、仮想マシン内の管理者権限を持つ攻撃者がホスト側のVMXプロセスでコードを実行し（CVE-2025-22224）、さらにカーネルへの任意書き込みでサンドボックスを抜ける（CVE-2025-22225）組み合わせが公表と同時に「悪用あり」とされました。報告者はMicrosoft Threat Intelligence Centerです。ESXiを乗っ取られると、ホスト上の全仮想マシンのディスクをまとめて暗号化できるため、ランサムウェアにとって効率のよい標的になります。

悪用が確認されたVMware脆弱性の一覧（CISA KEV掲載分）

米CISAの「悪用が確認された脆弱性カタログ（KEV）」2026年10月1日版には、VMware製品（Spring系とBrocadeを除く）の脆弱性が28件載っており、うち10件はランサムウェアでの悪用が「既知」とされています。ESXiとvCenterに限っても18件（ランサムウェア既知8件）です。件数は、公開JSONのうち提供元または製品名に「VMware」を含む行を数えたものです。2023年以降の主なものを新しい順に並べます。CVSSはVMSAでのBroadcom評価で、対象版と最新の悪用状況はCISA KEVと各VMSAで確認してください。

表中のToolsはVMware Toolsの略記です。

CVSSと悪用状況が一致しない点に注意してください。CVE-2024-37085はBroadcom評価6.8（Moderate）ですが、ランサムウェアでの悪用が既知です。ESXiをActive Directoryに参加させると、既定で「ESX Admins」というADグループに管理者権限が自動で付与されます。そのため、AD側でこのグループを作り直せる権限を持つ攻撃者は、ESXiを丸ごと掌握することが可能です。Microsoftは2024年7月、この手法がAkiraやBlack Bastaといったランサムウェアの展開につながった事例を報告しています。スコアの見方はCVSSの深刻度スコアの見方、CVE番号の仕組みはCVE（共通脆弱性識別子）の解説を参照してください。

VMSAの修正版・回避策の確認項目と改訂時の対応優先度の再評価

VMSAはBroadcomのVMware Security Advisoriesページからログインなしに閲覧でき、同ページの「Sign up for security alerts」からメール通知を購読できます。掲載場所は2024年5月6日に旧来のvmware.comからBroadcom Support Portalへ移り、vmware.com側の一覧はVMSA-2024-0008を最後に更新されていません。

Response Matrixの対象版別の修正版・回避策の確認項目

各CVEの節にある「Response Matrix」で見るのは4列です。「Version」で自社の版の行を選び、「Fixed Version」の修正版（ESXiはビルド番号付き。例：ESXi80U3k-25595708）、「Workarounds」の回避策の有無、「Additional Documentation」のFAQやKBを確認します。回避策は「None」の場合が多く、VMSA-2024-0019では「製品内の回避策は検討したが実用的でないと判断」と明記されています。パッチは累積型のため、途中の版を順に当てる必要はありません。

VMSA改訂の代表例と修正の差し替え・悪用情報に応じた対応の見直し

VMSAは公開後に「VMSA-2024-0019.3」のように番号が枝分かれして改訂されます。末尾のChange Logでは、修正の差し替え、悪用情報の追記、対象版のパッチ追加などを確認できます。

改訂表の対応関係は、VMSA-2024-0019.2がCVE-2024-38812、VMSA-2024-0019.3がCVE-2024-38812・CVE-2024-38813、VMSA-2024-0012.1がCVE-2024-37079です。VMSA-2026-0006.1は8.0 U2、.2は7.0向けのパッチ追加に対応します。

CVE-2024-38812は2024年9月17日の初回パッチでは修正しきれておらず、10月21日に修正版（vCenter 8.0 U3d／8.0 U2e／7.0 U3t）が出し直されました。9月の初回パッチだけを適用した環境では、10月の修正版を適用するまでCVE-2024-38812への対処が不完全な状態でした。CVE-2024-37079は2024年6月の公開から2026年1月23日に「悪用を示す情報がある」と追記され、同日KEVにも追加されています。初版を読んで対応を終えるのではなく、自社で使う製品のVMSAは改訂の通知まで追う運用が必要です。

VMSAとKEVの悪用情報の差異と緊急対応の判断に必要な照合項目

CVE-2026-59310は、2026年8月18日にKEVに追加され、ランサムウェアでの悪用も「既知」とされました。一方、VMSA-2026-0006の該当節のNotesは「None」で、Broadcomの補足FAQ（2026年8月28日更新）は「悪用を示す情報はない」と記載したままです（2026年9月26日確認。10月2日時点でもVMSA本文のNotesは「None」、最終改訂は8月19日の0006.2）。どちらか一方だけでは悪用の有無を見誤るため、VMSAとKEVの両方を確認し、どちらかに悪用の記載があれば緊急対応として扱ってください。複数の情報源から露出を管理する考え方はCTEMと脆弱性管理の違いで詳しく扱っています。

自社環境が対象か判定する手順（ビルド番号と攻撃成立条件の確認）

対象判定では、製品・バージョン・ビルド番号に加え、各CVEの攻撃成立条件に関係する設定も確認の対象です。たとえばCVE-2024-37085はESXiをActive Directoryに参加させている場合、CVE-2026-47876はVMXNET3の仮想NICを使う仮想マシンがある場合に成立します。バージョンとビルド番号はvSphere Clientの各オブジェクトの「サマリ」タブに表示され、台数が多い場合はPowerCLIでまとめて取得できます。

# vCenterに接続（接続先は自社の環境に置き換える）
Connect-VIServer -Server vcenter.example.local

# vCenterのバージョンとビルド番号
$global:DefaultVIServer | Select-Object Name,Version,Build

# 全ESXiホストのバージョンとビルド番号
Get-VMHost | Select-Object Name,Version,Build | Sort-Object Build

ESXiホストに直接ログインできる場合は、ESXi Shellの次のコマンドでも確認できます。

esxcli system version get
vmware -vl

取得したビルド番号を、VMSAのFixed Versionと、BroadcomのKB 316595（ESXiのビルド番号一覧）で照合します。たとえばESXi 8.0 Update 3kはビルド25595708（2026年7月29日公開）で、これ未満の8.0系ホストはVMSA-2026-0006の対象です。VCF 9.0以降はハイパーバイザーの名称が「ESXi」から「ESX」に変わりましたが、パッチとビルドの識別子には引き続き「ESXi」が付きます。検索時は両方の名称で探してください。

vCenter・ESXiの互換性に基づくパッチ適用順序と停止影響

vCenterの更新中はvSphere Clientなどの管理操作が一時的に使えなくなりますが、稼働中の仮想マシンは止まりません。ESXiの更新はホストの再起動が必要なため、vMotionで仮想マシンを別ホストへ逃がしながら1台ずつ再起動するのが基本です。ESXi 8.0.3以降のLive Patchや、VCF 9.1で入ったvCenterのQuick Patchを使うと停止を減らせますが、使えるのは直前の更新（N-1）からの場合で、対象になるかはリリースノートで確認します。なお、VMSA-2026-0006のvCenter更新はQuick Patchの対象外です。

• 順序：従来はvCenterが先。現在はESXiを先に更新できる組み合わせも多く、VMware Product Interoperability Matrixで互換を確かめて決める。
• 入手：support.broadcom.comからダウンロードするか、vSphere Lifecycle Managerのオンラインデポから適用する。新しい版が見えなければ、定期同期を待たずにデポを手動で同期する。
• アップグレード計画中の注意：VMSA-2026-0006の8.0／9.0向けパッチを当てると、ビルド番号の逆転（back-in-time）によりVCF 9.xへのアップグレードが一時的にブロックされる（KB 67077）。
• HCI製品：VxRailなど他社の統合製品は、そのベンダーの指示に従う。

パッチが入手できない2つのケースとサポート契約・移行判断の条件

VMSAに修正版が載っていても、自社がそれを受け取れるとは限りません。次の2つは、パッチ適用ではなく移行の判断が必要になるケースです。

vSphere 7以前のサポート終了と延長契約によるパッチ提供条件

vSphere 7は2025年10月2日に一般サポートが終了しました。VMSA-2026-0006でもvCenter 7.0とESXi 7.0の修正版欄は「延長サポート契約があればBroadcomサポートへ問い合わせ」となっており、誰でもダウンロードできる状態ではありません。vSphere 6.5／6.7はVMSAの評価対象外で、Broadcomは「記載がない旧版も影響を受けると想定すること」としています。VMSA-2024-0013でも、CVE-2024-37085のESXi 7.0向けは「No Patch Planned」で、回避策（KB 369707）だけが示されました。

永続ライセンスのサポート失効後のパッチ提供条件と深刻度による制限

BroadcomのKB 314603は、サポート切れの永続ライセンス利用者にも「ゼロデイ」パッチを提供するとしています。ただし対象は現行のサポート対象であるvSphere 8.xで、CVSS 9.0以上の重大（Critical）なものに限られます。CVSS 6.8のCVE-2024-37085のように、9.0未満でも悪用される脆弱性は対象外です。また対象となるパッチは、VMSAの公開より後にリリースされます。サポート契約の更新をしないまま基盤を使い続けるなら、外部からの脆弱性診断・セキュリティ診断で管理面の露出を定期的に確かめつつ、Proxmox VEやKVMなどへの移行計画を並行して立てるべきです。ハイパーバイザー選定の観点はハイパーバイザーのType1・Type2の違いにまとめています。

パッチまでの間を守るハードニング（vSphere 8 SCGの主要項目）

Broadcomは「vSphere Security Configuration & Hardening Guide（SCG）」をGitHubで公開しており、vSphere 8版（803-20260612-01）は156項目の設定基準と、PowerCLIの監査・修正スクリプトを含みます。インストール時の既定値のままでは基準を満たさない項目のうち、脆弱性の悪用を難しくする効果が大きいものを挙げます。

表中で略記したSCG IDの正式表記は、ESXi接続元制限が「esxi-8.firewall-restrict-access」、vCenter接続元制限が「vcenter-8.vami-firewall-restrict-access」、VIB署名制限が「esxi-8.vib-trusted-binaries」です。

vCenterの認証前RCEは「vCenterにネットワーク到達できること」が前提なので、接続元の制限は回避策が「None」の脆弱性にも効く数少ない手段です。VMkernel.Boot.execInstalledOnly（署名済みVIB以外の実行禁止）は、攻撃者が持ち込んだツールをESXi上で動かしにくくします。ただし、VIB経由でインストールされていない実行ファイルも制限されるため、有効化前に棚卸しが必要です。インタープリター経由で実行する未署名スクリプトまで防げる設定ではありません。

AD連携を使うESXiでは、CVE-2024-37085の回避策としてKB 369707の3つの詳細設定を見直します。修正はESXi 8.0 U3で入っており、それより前の版（パッチ予定のない7.0を含む）ではこの設定変更が公式の回避策です。

# ESX Adminsグループへの自動付与を止め、グループ名を空にする（KB 369707）
$h = Get-VMHost -Name esxi01.example.local
Get-AdvancedSetting -Entity $h -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroupAutoAdd | Set-AdvancedSetting -Value $false -Confirm:$false
Get-AdvancedSetting -Entity $h -Name Config.HostAgent.plugins.vimsvc.authValidateInterval | Set-AdvancedSetting -Value 90 -Confirm:$false
Get-AdvancedSetting -Entity $h -Name Config.HostAgent.plugins.hostsvc.esxAdminsGroup | Set-AdvancedSetting -Value "" -Confirm:$false

AD参加済みのホストでは、設定変更の後にESXi Shellで権限一覧を確認し、残っている「ESX Admins」グループのAdmin権限を外します（Host Clientの画面からも削除できます）。グループ名は自社のドメインに置き換えてください。

esxcli system permission list
esxcli system permission unset -i 'yourdomain\esx^admins' --group

KB 369707によると、設定は1分以内に反映され、再起動は不要です。仮想NICの種類を変えるような回避策は勧められていません。VMSA-2026-0006のFAQは、VMXNET3の脆弱性（CVE-2026-47876）を避けるためにe1000へ替えることについて「e1000にも脆弱性の歴史があり、健全な戦略ではない」と明言し、ESXの更新を求めています。

Workstation・Fusionを使う個人・開発者のセキュリティ

デスクトップ向けのVMware WorkstationとFusionも、ESXiと同じVMSAで修正されることがあります。VMSA-2025-0004ではWorkstation 17.6.3とFusion 13.6.3が修正版で、VMSA-2026-0006では25H2が対象、26H1で修正されました（Workstation／Fusion上の深刻度はLow・CVSS 2.7）。2026年9月3日のVMSA-2026-0007はWorkstationとFusion専用で、VMXNET3の整数オーバーフロー（CVE-2026-59346・CVSS 9.3）により、仮想マシン内の管理者権限からホスト上でコードを実行される可能性があります。同じVMSAのHGFSのスタックバッファオーバーフロー（CVE-2026-59347・CVSS 8.1）も、ゲストの管理者権限からホスト上のVMXプロセスとしてコードを実行され得ます。2026年10月2日時点でVMSA-2026-0007が最新のVMSAで、2件のCVEはCVE.orgとNVDにまだレコードが公開されていません。25H2と26H1が対象で、修正版は26H1u1、回避策はありません。ゲストOSにマルウェアが入る前提の検証環境ほど、ホスト側のWorkstationとFusionを最新に保つ意味があります。

よくある質問

VMwareのセキュリティリスクで最も大きいものは何ですか？

vCenterの認証前リモートコード実行と、ESXiのVMエスケープです。前者はvCenterにネットワーク到達できれば成立し、後者は仮想マシン内の管理者権限からホスト全体へ広がります。どちらも基盤上の全仮想マシンに影響するため、管理ネットワークの分離とパッチ適用を最優先にします。

CVE-2024-38812とはどんな脆弱性ですか？

vCenterのDCERPCプロトコル実装のヒープオーバーフローで、CVSS 9.8のリモートコード実行の脆弱性です（VMSA-2024-0019）。2024年9月17日の初回パッチが不完全で、10月21日に出た vCenter 8.0 U3d／8.0 U2e／7.0 U3t が正しい修正版です。11月に悪用が確認され、KEVにも追加されました。

サポート契約が切れていてもセキュリティパッチは入手できますか？

vSphere 8.xの永続ライセンスで、CVSS 9.0以上の重大な脆弱性なら、support.broadcom.comの無償アカウントで入手できます（KB 314603）。vSphere 7以前や、CVSS 9.0未満の脆弱性は対象外です。

VMware Toolsを更新すれば脆弱性対策になりますか？

判断の基準は、修正対象として記載された製品です。VMSA-2026-0006のVMXNET3の脆弱性はESX側の問題で、FAQは「VMware Toolsの更新は不要、ESXの更新で解決する」としています。一方、CVE-2025-41244のようにVMware Tools自体が修正対象になるVMSAもあるため、対象製品欄で判断します。

VMwareの脆弱性情報を見逃さずに受け取るにはどうすればよいですか？

VMSAのページの「Sign up for security alerts」からメール通知を購読し、あわせてCISA KEVの更新を確認します。通知は初版だけでなく改訂でも届くため、改訂時にもChange Logを読み直してください。

関連記事

• Fortinet（FortiGate）の脆弱性まとめ｜代表的なCVE一覧と影響確認・パッチ・仮想パッチによる対策【2026年最新】
• CVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点を解説
• CTEMとは？脆弱性管理との違い・5つの段階と企業の導入判断を解説
• ハイパーバイザーとは？Type1・Type2の違いから仮想化基盤の選定まで実装者向けに解説
• Proxmox VEとは？できること・日本語化・推奨スペックまで実装目線で解説