VMwareをめぐっては、近年ESXiやvCenterの深刻な脆弱性が相次いで公表され、パッチ適用が追いつかないと感じている運用担当者も少なくありません。本記事では、まず何が起きているのかという脅威動向を整理し、実際に悪用された主要な脆弱性を具体的に解説します。そのうえで、自社環境のリスクを「可視化」し、対応の優先順位を付けるための脆弱性診断という実務的なアプローチまでを紹介いたします。
VMwareは、サーバ仮想化を支える代表的な製品群で、その中核がESXiとvCenterです。VMwareセキュリティの中心は、このハイパーバイザーと管理基盤の保護にあります。ハイパーバイザーとは、1台の物理サーバ上で複数の仮想マシン（VM）を動かす土台となるソフトウェアで、VMware製品ではESXiがこれにあたります。vCenter Serverは、複数のESXiホストを一元管理する司令塔のような役割を担うサーバです。
なお、VMwareは現在Broadcomの傘下にあり、製品は「VMware by Broadcom」として提供されています。セキュリティ情報（VMSA：VMware Security Advisory）やパッチも、Broadcomのサポートポータルで公開されます。
この2つが守りの要となる理由は、影響範囲の広さです。ESXi1台が侵害されれば、その上で稼働する数十のVMが一度に危険にさらされます。vCenterを乗っ取られれば、管理下のホスト群とVMを横断的に操作される恐れがあります。
つまりVMwareセキュリティは、個々のサーバOSの対策とは性質が異なる、ということです。基盤そのものを守ることが、業務システム全体を守ることに直結する、という前提で考える必要があります。
ハイパーバイザーとvCenterが攻撃者に好まれるのは、少ない侵害で大きな成果を得られるためです。攻撃者の視点では、VMを1台ずつ攻略するより、土台や管理基盤を一度押さえる方が効率的といえるでしょう。
理由はそれだけではありません。ESXiはハイパーバイザー専用のOSで、一般的なEDR（端末向けの防御製品）を導入しにくいため、攻撃者にとって監視が薄い格好の標的です。
具体的には、VMから土台へ抜け出す「VMエスケープ」や、vCenterの管理権限の奪取が狙われます。VMエスケープは、本来分離されているはずのVMの枠を越え、ホストや他のVMへ到達する攻撃です。これが成立すると、監視の網をすり抜けて基盤全体へ被害が拡大します。（※）
ただし、VMエスケープの多くは、いきなり外部から成立するわけではなく、まずVM内で一定の権限を得た攻撃者が、そこからホストへ抜ける形をとります。そのため、VM単体の防御に加えて、基盤の堅牢化とパッチ適用が欠かせません。
※参考：Broadcom│「VMware vSphere Security Configuration & Hardening Guide」
VMwareセキュリティが近年いっそう重要になっているのは、脅威環境そのものが構造的に変化しているためです。背景は大きく、脆弱性発見の加速、提供体制の変化、そして攻撃側の標的シフトの3点に大別されます。これらを理解すると、なぜ従来の対応では息切れするのかが見えてきます。
第一の背景は、AIによる脆弱性発見の急増です。VMwareの開発元であるBroadcomは、実稼働コードを対象とした最先端のAIセキュリティモデルのテストで、従来を大幅に上回る数の脆弱性が次々と見つかっていると説明しています（※1）。
注目すべきは「脆弱性の連鎖」という指摘です。これは、単体では深刻度が低い2〜3個の脆弱性を組み合わせ、ひとつの重大な攻撃経路を作り出す手法を指します。Broadcomは、この変化を一時的な現象ではなく新たな基準だと位置づけ、発見の加速に伴い修正対応も加速せざるを得ないとしています(※1)。発見のペースが上がるほど、適用すべきパッチの量と頻度も増える点が、運用現場の負担増に直結してしまうのです。
第二の背景は、提供体制の変化です。VMwareは2023年にBroadcomへ統合され、製品はサブスクリプション中心の提供へと移行しました。脆弱性情報は引き続き公式のセキュリティアドバイザリ（VMSA）で公開されており、一次情報源としての位置づけは変わっていません（※2）。
一方で、修正プログラムの入手にはサポート契約の維持が前提となる場面が増えました。契約や更新管理が滞ると、修正が出ているのに適用できないという状態に陥りかねません。これは技術というより運用・契約面のリスクであるため、計画的な管理が重要となるでしょう。
第三の背景は、攻撃側がVMware基盤を主要標的に定めたことです。2023年には「ESXiArgs」と呼ばれるランサムウェアがインターネット公開されたESXiを広範に侵害し、米CISA（サイバーセキュリティ・インフラセキュリティ庁）が復旧支援の情報を公開する事態となりました（※3）。
注意したいのは、ESXiArgsがゼロデイではなく、2021年にすでに修正パッチが公開されていた既知の脆弱性を突いた点です。パッチ未適用のままだったり、サポートが切れた（EOL）ままだったりしたESXiが、世界で3,800台超も狙われました。これは第二の背景と直結します。契約・更新管理が滞ってパッチを当てられないESXiこそが、ランサムウェアの格好の標的になるのです。
仮想基盤が暗号化されると、その上の多数のVMが同時に停止します。ひとつの侵害が事業全体の停止に直結する点が、攻撃者にとっての魅力であり、防御側にとっての最大の脅威です。
※1：VMware Japan Blog│「AIによるサイバーセキュリティ脅威の劇的変化 インフラ準備はできているか？」
※2：Broadcom│「VMware Security Advisories（VMSA）」
※3：CISA│「ESXiArgs Ransomware Virtual Machine Recovery Guidance」
抽象的な不安を具体的な判断に変えるには、実際に悪用された脆弱性を知ることが近道です。ここ1〜2年でESXi・vCenter・関連コンポーネントに、攻撃が確認された深刻な脆弱性が複数報告されています。まず全体像を表で確認し、その後で代表例をご紹介します。
| CVE番号 | 影響する主な製品 | CVSS（深刻度） | 攻撃の性質 | 悪用状況 |
|---|---|---|---|---|
| CVE-2025-22224 | ESXi, Workstation, Fusion ほか | 9.3（緊急） | TOCTOUによる境界外書き込み | ゼロデイ悪用が確認 |
| CVE-2025-22225 | ESXi ほか | 8.2（重要） | カーネル書き込みでサンドボックス回避 | 後にランサムでも悪用 |
| CVE-2025-22226 | ESXi, Workstation, Fusion | 7.1（重要） | 境界外読み出しによる情報漏えい | ゼロデイ悪用が確認 |
| CVE-2024-37079 | vCenter Server | 9.8（緊急） | リモートコード実行 | 悪用が確認 |
| CVE-2025-41244 | Aria Operations, VMware Tools | 7.8（重要） | ローカル権限昇格（root化） | 約1年前から悪用 |
※表のCVSS値は、Broadcomのアドバイザリ（VMSA）の評価に準拠しています。採点元（BroadcomとNVD）によって値が分かれる場合があります。
ESXiで2025年3月に公表された3件は、連鎖によるVMエスケープを成立させる点で特に危険でした。Broadcomのアドバイザリ「VMSA-2025-0004」は、CVE-2025-22224（CVSS 9.3）、CVE-2025-22225（8.2）、CVE-2025-22226（7.1）を扱っています（※4）。
3件を組み合わせると、攻撃者は侵害したVMからESXiハイパーバイザーへ抜け出し、他のVMや管理ネットワークへ到達しうるとされます（※5）。
ただし、これはいきなり外部から成立するものではなく、攻撃者がまずVM上で管理者やroot権限を得ていることが前提です。そのため、VM単体の防御と、基盤側のパッチ適用の両方が欠かせません。
一つひとつの深刻度だけを見ると見落としかねませんが、連鎖すれば重大な攻撃経路になる典型例です。これらはいずれも、公表時点で実際の悪用が確認されたゼロデイ（修正前に攻撃に使われる脆弱性）でした。
vCenterのCVE-2024-37079は、認証なしでの遠隔コード実行につながる深刻な脆弱性です。これはvCenter内部の通信処理におけるヒープオーバーフローに起因し、特別に細工した通信を送ることで悪用されうるとされています（※6）。CVSSは9.8（緊急）と評価されています。
注目すべきは、修正提供から時間を経た2026年1月、CISAがこの脆弱性を実際に悪用中として「悪用が確認された脆弱性カタログ（KEV）」に追加し、連邦機関に期限付きの対処を命じた点です（※7）。これは、パッチが出ていても適用が遅れれば、後から悪用が顕在化するリスクが残ることを示しています。
CVE-2025-41244は、未公表のまま長期間悪用されていた点で示唆に富みます。これはVMware ToolsおよびAria Operationsに関する権限昇格の脆弱性で、CVSSは7.8（重要）です（※8）。
特定条件下で、管理者でない利用者がVM上でroot権限へ昇格できる恐れがあります。報告によれば、この脆弱性は公表（2025年9月）より約1年前から実環境で悪用されていたとされ、後にCISAのKEVにも登録されました（※7、※8）。未知の高度な攻撃だけでなく、気づかれずに残った既知の弱点こそが現実的な脅威である、という教訓を含んでいます。
※4：Broadcom│「VMSA-2025-0004（CVE-2025-22224, CVE-2025-22225, CVE-2025-22226）」
※5：NIST National Vulnerability Database│「CVE-2025-22225 Detail」
※6：NIST National Vulnerability Database│「CVE-2024-37079 Detail」
※7：CISA│「Known Exploited Vulnerabilities Catalog」
※8：NIST National Vulnerability Database│「CVE-2025-41244 Detail」
脆弱性の放置は、システム障害にとどまらず経営リスクへ発展します。理由は、仮想基盤の侵害が事業継続・情報保護・法令対応という複数の領域に同時に波及するためです。
たとえばESXiが暗号化されれば、その上の業務システムが一斉に停止し、復旧まで事業が止まります。vCenterの権限を奪われれば、構成変更やデータ持ち出しを許し、顧客情報の漏えいにつながってしまうリスクもあります。
近年のランサムウェアは、暗号化による停止だけでなく、盗み出したデータを公開すると脅す「二重脅迫」が主流です。そのため、基盤の侵害ひとつで「事業停止」と「情報漏えい」が同時に起こりやすくなっています。
個人情報が漏えいした場合、国内では個人情報保護委員会への報告や本人への通知が必要になる場面があり、対応は技術部門だけでは完結しません（※9）。
このように、脆弱性対策は情シス内の作業ではなく、事業リスクの管理そのものです。だからこそ、後述する「どこにどれだけのリスクがあるか」の可視化が重要になります。
※9：個人情報保護委員会│「個人データの漏えい等が発生した場合の対応について」
対策の第一歩は、信頼できる情報を正確かつ迅速に集めることです。情報源を一次情報に絞り、深刻度を共通の物差しで評価できれば、過不足のない対応判断につながります。ここでは公式情報の確認、スコアの読み方、国内外機関の併用という順で解説します。
最も信頼できるのは、開発元が公開する一次情報です。VMware製品の脆弱性は「VMware Security Advisories（VMSA）」で、CVEの内容・影響範囲・修正バージョンが整理して公開されます（※10）。
実務上の必須事項は、このVMSAを定点観測することです。Broadcom Support Portalでは通知の受信設定ができ、公開時にいち早く把握できます。推奨事項として、対象製品とバージョンを台帳化しておくと、影響有無の判断が速くなります。
深刻度の判断には、共通の指標を使います。CVEは脆弱性に付与される共通の識別番号で、MITREが採番を管理しています（※11）。CVSSは深刻度を0.0〜10.0で数値化する評価方式で、策定はFIRSTが担っています（※12）。
CVSS v3.xでは、7.0以上がHigh、9.0以上がCriticalに区分されます（※3）。この4段階の区分（Low／Medium／High／Critical）は新版のv4.0でも同じで、変わったのは点数の算出方法です。v4.0（2023年11月公開）の主な変更点は次のとおりです。
実務上の要点は、同じ脆弱性でもv3.1とv4.0でスコアが変わりうること、そして多くのデータベースが依然v3.1を併用していることです。そのため、スコアがどのバージョンで算出されたかの確認が必要です。
また、NVDが提供するのは原則Baseスコアまでで、Threat（脅威）やEnvironmental（環境）はユーザー側で加味する必要があります。スコアは判断の出発点であり、自社環境での到達可能性と併せて優先度を決めるのが実務的です。
公式情報に加え、公的機関の発信を併用すると判断精度が上がります。国内ではIPA（情報処理推進機構）やJPCERT/CCが、確認された脆弱性や攻撃動向に関する注意喚起を発信しています（※13、※14）。
特に有用なのが、CISAのKEVカタログです。これは「実際に悪用が確認された」脆弱性の一覧で、悪用中か否かという優先度判断に直結する情報を提供しています（※6）。スコアが中程度でも悪用中なら優先、という判断ができます。
※10：Broadcom│「VMware Security Advisories（VMSA）」
※11：The MITRE Corporation│「CVE Program」
※12：FIRST│「Common Vulnerability Scoring System（CVSS）」
※13：情報処理推進機構（IPA）│「脆弱性対策情報」
※14：JPCERT コーディネーションセンター│「注意喚起」
※15：CISA│「Known Exploited Vulnerabilities Catalog」
相次ぐ脆弱性に対応し続けるには、パッチ適用だけに頼らず、自社リスクを可視化する仕組みが要ります。理由は、発見される脆弱性の量と速度が、手作業の適用能力を上回りつつあるためです。ここでは限界の正体を示したうえで、脆弱性診断による棚卸しと優先度付けという現実的な進め方を解説します。
パッチ適用が万能でない最大の理由は、量と作業負荷のミスマッチです。前述のとおり、AIによる発見の加速で、対応すべき脆弱性は増加傾向にあります（※16）。
一方で、ESXiやvCenterのパッチ適用は、業務影響の検証や保守時間の確保を伴い、すぐに全環境へ展開できるとは限りません。結果として「公開はされたが未適用」の期間が生まれ、その隙が狙われます。だからこそ、すべてに即対応するのではなく、危険なものから順に対応する優先度付けが欠かせません。その具体的な順序は、後述のトリアージで示します。
優先度付けの土台となるのが、プラットフォーム診断です。これは、サーバやネットワーク機器などの基盤（プラットフォーム）に既知の脆弱性や設定不備がないかを網羅的に調べる手法を指します。
診断で可視化できるのは、主に次の3点です。
これらを一覧化することで、感覚ではなく事実に基づいて危険箇所を特定できます。
診断で多数の脆弱性が見つかっても、すべてを同時には直せません。優先順位は、次の順序で見ていくと無理なく決められます。
まず最優先で直すのは、すでに実際の攻撃に使われたことが確認されている脆弱性です。被害の想定にかかわらず、現実に悪用されている以上、放置する時間は短いほど安全だからです。こうした「悪用が確認済みの脆弱性」は、政府機関などが一覧（KEVと呼ばれる公開リスト）として公開しており、検出結果と照らし合わせて確認できます（※16）。
KEVカタログの詳しい仕組みや活用方法は、別記事「KEVカタログとは？脆弱性診断の優先順位を決める活用ガイド」で詳しく解説しています。
次に、攻撃の確認がないものは、「悪用されたときの被害の大きさ」と「今後悪用されそうな度合い」の二つを重ねて見ます。被害の大きさは、前述のCVSS（攻撃のしやすさと影響度を組み合わせて数値化した指標）で判断でき、値が大きいほど攻撃のしやすさと影響度を組み合わせた深刻度の高さも大きいことを意味します。被害が大きく、かつ狙われやすいものから手を付けると、影響の大きいものを効率よくつぶせます。
その「今後悪用されそうな度合い」は、過去の攻撃傾向から悪用の可能性を見積もった数値（EPSSと呼ばれる指標）で表されます（※17）。大半の脆弱性はこの値が低いため、絶対的な基準で線を引くより、検出結果の中で相対的に高いものから対応すると判断しやすくなります。
最後に、本番環境で動いていない、または使っていない機能の脆弱性は、優先度を下げて経過を監視します。同じ深刻度でも、実際に動いていなければ攻撃の現実味は下がるためです。この「攻撃が確認済みのものを最優先 → 残りは被害の大きさと狙われやすさが高いものから → 動いていないものは後回し」という順序を持っておくと、件数が多くても迷わず優先順位を付けられます。
※16：CISA│「Known Exploited Vulnerabilities Catalog」
※17：FIRST│「Exploit Prediction Scoring System (EPSS)」
最後に注意すべきは、サポート終了（EOL）製品と変更管理です。EOL製品は修正プログラムの提供対象外となるため、既知の脆弱性が残り続けます。診断で古いバージョンを発見した場合は、アップグレードや基盤移行を計画的に検討する必要があります。
また、仮想環境ではひとつの変更が全体へ波及します。事前検証と適用順序を定めた変更管理を徹底することが、診断で見つけた弱点を確実に塞ぐ前提条件になります。
ESXi/vCenterを含むサーバ環境の脆弱性を一括して可視化するなら、専門サービスの活用が効率的です。
VMwareセキュリティの要点は、最新動向を踏まえ、自社リスクを可視化して優先度を付けることに尽きます。AIによる脆弱性発見の加速とランサムウェアの標的化により、パッチ追従だけでは守り切れない局面が増えました。深刻な脆弱性が相次ぐ状況では、すべてに即時対応するのではなく、危険なものから順に手を当てる発想が欠かせません。
本記事では、信頼できる一次情報の集め方、CVSSやKEVを用いた深刻度の見極め、そして脆弱性診断による棚卸しと優先度付けという一般的な流れをお伝えしました。着手自体は、一次情報の確認や資産の棚卸しといった社内でできることから始められます。そのうえで、診断の網羅性や継続性を高める段階では、専用ツールや外部の診断サービスを活用するのも有効な選択肢です。完璧な防御を一度に目指すよりも、可視化と優先度付けを運用として回し続けることが、相次ぐ脆弱性に向き合う確実な方法といえるでしょう。
ユービーセキュアでは、ESXiやvCenterといった仮想基盤を含むサーバ・ネットワーク機器の脆弱性を網羅的に診断するプラットフォーム診断サービスを提供しています。VMware環境のリスク可視化や、優先度付けの判断にお困りの場合は、お気軽にご相談ください。