VMware vCenter の CVSS 9.8 二連発 VMSA-2026-0006 - 認証バイパスとディレクトリトラバーサルRCEを読み解く

仮想基盤の「司令塔」に、未認証のまま入り込める穴が2つ同時に見つかった。Broadcomが2026年7月29日に公開したセキュリティアドバイザリVMSA-2026-0006は、そういう話です。

対象はVMware vCenter。VMware Directory Service(vmdir)の認証バイパスであるCVE-2026-59309と、vCenterのSyslogサーバに存在するディレクトリトラバーサルであるCVE-2026-59310は、どちらもCVSSv3.1の基本値が9.8で、いずれも「vCenterへネットワーク到達できる攻撃者」が前提条件を追加で必要とせずに悪用できるとされています。そして回避策(workaround)は提供されていません。

本記事では、Broadcom公式のアドバイザリとVMware公式リポジトリのQ&Aドキュメント、NVDのCVEレコード、CISA KEVカタログの実データという一次情報を基に、何が起きたのか、どのバージョンが対象なのか、そして運用者が今すぐ何をすべきかを整理します。攻撃コードや悪用手順は扱わず、防御と運用の観点に絞ります。

概要(まず結論)

vCenterに関わる2件だけを抜き出すと次の通りです。

ベクタを読むとAV:N/AC:L/PR:N/UI:N、つまりネットワーク越し、攻撃条件は低、権限不要、ユーザー操作不要という組み合わせです。さらにC:H/I:H/A:Hで機密性・完全性・可用性のすべてに高い影響が想定されています。CVSSの数値が同じ9.8でも、この2件は性質が異なるので、以下で分けて整理します。

何が起きたか(タイムライン)

確認できた範囲で時系列を並べます。

改訂で8.0 Update 2向けのパッチが追加された点は実務的に重要です。Broadcomは「vSphere 8ではUpdate 3が最良であり、新しいセキュリティ更新はその上に積まれる」としつつ、Update 3への移行が間に合わない環境のためにUpdate 2系のパッチも用意しました。ただしQ&AドキュメントにはUpdate 2向けのパッチはこのアドバイザリのCriticalなCVEのみを解決すると明記されており、それ以外の修正が必要なら8.0 Update 3k以降へ進む必要があります。

なお、CISA KEVへの登録がないことは「安全」を意味しません。KEVは悪用の証拠が確認されたものだけが載る仕組みであり、載っていない=攻撃されていない、ではありません。同じくKEV入りしていた事例との比較はCisco FMCのハードコード認証情報CVE-2026-20316の記事で整理しています。あちらは公開と同日にKEV入りし是正期限3日という異例の扱いでしたが、今回はまだその段階には至っていない、という違いです。

CVE-2026-59309: vmdir の認証バイパス

NVDに登録されている記述は簡潔です。「VMware vCenterはVMware Directory Serviceに認証バイパスの脆弱性を持つ。vCenterにネットワークアクセスできる悪意ある行為者は、これを悪用して認証を回避しシステムへ不正アクセスできる可能性がある」。

vmdir(VMware Directory Service)はvCenterの中核サービスの1つで、vCenter Single Sign-Onのアイデンティティ情報を保持するLDAPベースのディレクトリです。SSOのユーザーやグループ、ソリューションユーザー、証明書関連の情報など、「誰が何者であるか」を決めているコンポーネントがここに集約されています。認証を成立させる側のサービスに認証バイパスが存在するということは、その上に乗っているアクセス制御の前提が丸ごと崩れることを意味します。

割り当てられたCWE-303は「Incorrect Implementation of Authentication Algorithm(認証アルゴリズムの不正確な実装)」です。CWEの説明では、確立された認証アルゴリズムを使う仕様であるにもかかわらず実装に誤りがあり、その結果として認証が回避されうる、という弱点を指します。つまり「認証機構そのものを付け忘れた」のではなく、認証処理はあるが、その実装が仕様どおりに機能していないという分類です。

具体的にどのリクエスト経路で、どの検証がどう抜けるのかという技術的詳細は、本記事執筆時点で一次情報として公開されていません(未確認)。Broadcomもアドバイザリで詳細を開示していません。ここを推測で埋めると誤った緩和策につながるため、本記事では踏み込みません。

運用上、押さえておくべき点はQ&Aドキュメントに明示されています。

• Enhanced Linked Mode(ELM)を使っていなくても影響を受ける。問題はELMではなくvCenter自体にあります。
• Integrated Windows Authentication(IWA)やActive Directory連携の有無は無関係。5件のいずれもAD連携に起因するものではなく、アイデンティティソースの構成にかかわらず存在します。

「うちはAD連携していないから」「ELMを組んでいないから」という理由で対象外と判断するのは誤りです。

CVE-2026-59310: Syslog サーバのディレクトリトラバーサル

こちらのNVD記述は「VMware vCenterはSyslogサーバにディレクトリトラバーサルの脆弱性を持つ。vCenterにネットワークアクセスできる悪意ある行為者は、これを悪用して任意コードを実行できる可能性がある」です。CWE-22、すなわち「Improper Limitation of a Pathname to a Restricted Directory(制限されたディレクトリへのパス名の不適切な制限)」に分類されています。

ディレクトリトラバーサル自体は古典的な脆弱性クラスです。外部から与えられた文字列をファイルパスの一部として組み立てる際に、../のような親ディレクトリ参照や絶対パスの指定を十分に正規化・検証しないと、想定した基準ディレクトリの外側を読み書きできてしまう、というものです。

読み取り方向であれば情報漏えいにとどまりますが、書き込み方向でトラバーサルが成立すると、任意コード実行に化けることがあります。ログ収集のように「受け取ったデータをファイルとして保存する」処理は、その性質上どうしても書き込みを伴います。ファイル名やパス要素の一部が入力側の情報から決まる設計であれば、保存先を意図しない場所に向けられる余地が生まれます。BroadcomがこのCVEに「任意コード実行」という結果を記載しているのは、そうした書き込み経路が成立しうるという評価と読めます。

ただし、実際にどのパラメータがパスに使われ、どの経路で実行に至るのかは公開されていません(未確認)。またPoCの公開についても、Rapid7が2026年7月30日時点で「公開されたPoCはない」としているのが確認できる最新の情報です。それ以降の状況は本記事執筆時点では追跡できていません。

Syslogという機能の性質上、注意しておきたいのはログ収集ポートは「業務では使わないから閉じておく」という判断がされにくいことです。監視基盤との連携のために内部ネットワークへ広く開けられている構成は珍しくありません。vCenterがどのポートで何を待ち受けているかは、Broadcomが公開しているVMware Ports and Protocolsのツールで製品・バージョンごとに確認できます。今回の対応にあわせて、自環境の待ち受け状況を実測で確認しておくことをおすすめします。

VMSA-2026-0006 に含まれる残り3件

vCenterの2件が目立ちますが、同じアドバイザリにはESX側の3件が含まれています。vCenterだけ直して終わりにしないために、こちらも把握しておく必要があります。

CVE-2026-47876はQ&Aドキュメントが明確にVMエスケープに該当すると認めています。VMXNET3仮想ネットワークアダプタを使うVM内でローカル管理者権限を握った攻撃者が、ESXホスト上でコードを実行しうるという内容です。他の仮想NICを使うVMは影響を受けないとされていますが、Broadcomは「だからe1000へ切り替えよう」という発想は不適切だと釘を刺しています。理由は2つで、非準仮想化デバイスのドライバにも過去に脆弱性があったこと、そして準仮想化ドライバの性能上の利点を失うことです。仮想ハードウェアを変えるのではなくESXを更新せよ、というのが公式の指示です。

CVE-2026-41709は基本値2.7と低く見えますが、性質としては見過ごしたくないタイプです。「悪意ある管理者が、記録を残さずに操作できる」というのは、単体では被害を生まないものの、侵害後の追跡可能性を削る欠陥です。認証情報が奪われて管理者として振る舞われた場合、後から何をされたのかを再構成する手がかりが減ります。スコアの低さと運用上の重要度は必ずしも一致しません。

なお、VMware Toolsの更新は必要ないとQ&Aに明記されています。VMXNET3にはゲスト内ドライバがありますが、CVE-2026-47876はESX側の問題であり、ESXの更新で解決します。仮想ハードウェアバージョンの引き上げも不要です。

影響範囲と修正バージョン

Q&Aドキュメントの記述は非常に強い表現です。「VMSAに記載された修正版より前のバージョンのVMware ESX、vCenter、Workstation、Fusionを動かしているなら、あなたは影響を受ける。影響を受けるかどうか疑問があるなら、おそらく影響を受けているので直ちに対処すべきである」。

vCenterの2件について、アドバイザリの応答マトリクスに記載されている修正版は次の通りです。

ESX側の主な修正ビルドは次の通りです。

Workstation 25H2とFusion 25H2はCVE-2026-41703の影響を受け、26H1で修正されています。

バージョン判定で迷いにくいポイントを2つ挙げておきます。

• パッチは累積的です。先に前提パッチを当てる必要はなく、対象バージョンより新しいものを適用すれば本アドバイザリの問題も解決します。CVEごとに個別パッチを当てる必要もありません。
• サポート終了バージョンは「影響あり」と見なすべきです。vSphere 7.0は2025年10月2日にEnd of General Supportを迎えており、拡張サポート契約があればそのプロセスでパッチを要求する形になります。6.5や6.7についてBroadcomは評価対象外としつつ、影響を受けるものと想定するよう案内しています。

パッチ適用で先に知っておくべき落とし穴

このアドバイザリの更新は、単に「最新を当てる」だけでは済まない要素をいくつか含んでいます。作業計画を立てる前に確認してください。

Q&Aドキュメントは明確に「はい」と答えています。今回のvSphere 8.0および9.0向けの更新(VCF 5.xへの非同期パッチ適用を含む)を当てると、VMware Cloud Foundation 9.xへのアップグレードがブロックされ、back-in-timeエラーが報告されるようになります。互換性は後続リリースで回復するとされていますが、9.xへの移行プロジェクトの最中にいる組織は、適用のタイミングと計画への影響を天秤にかける必要があります。詳細はKB 67077に整理されています。

今回のvCenter更新はQuick Patchの対象外です。従来のvCenterパッチ方式か、構成済みであればReduced Downtime Upgrade(RDU)を使うことになります。一方でESX側の更新はLive Patchと互換性があるとされており、環境が対応していればホスト更新は大幅に速くなる可能性があります。ただしLive PatchもQuick Patchも、そのメジャーバージョンの直前の更新(N-1)を適用済みであることが条件です。

従来は「vCenterを先に」が定石でしたが、Q&Aでは近年の版では逆順でも問題が出ないことが多いと説明されています。判断材料はVMware Product Interoperability Matrixで、対象のvCenterバージョンとESXバージョンの組み合わせを確認します。vSANを使っているならvSANも含めて確認します。

• vCenterの更新は稼働中のワークロードを止めません。更新中にvSphere Clientなど管理手段が一時的に使えなくなるだけで、VMやコンテナは動き続けます。
• ESXの更新はホスト再起動を伴います。vMotionでVMを退避しながらローリング再起動するのが基本で、vMotionできないVMは停止が必要です。

vCenter が落ちると何が起きるか

CVSS 9.8という数字以上に、この2件の怖さはvCenterというコンポーネントの位置づけから来ます。vCenterはESXホスト群を束ねる管理面であり、そこを掌握されるということは、配下のVM、データストア、ネットワーク構成、権限設定へのアクセスを一括で渡すことに近い意味を持ちます。

仮想基盤の管理面が実際に狙われてきたことは、CISA KEVカタログの履歴を見れば裏付けられます。筆者が2026年8月3日版のKEVデータで確認した範囲では、VMware関連で次のようなエントリが登録済みです。

CVE-2021-21972とCVE-2024-37085にはKEV上で「ランサムウェアキャンペーンでの利用が既知」と記録されています。仮想基盤の管理面はランサムウェアの実行者にとって実績のある入口だということです。ハイパーバイザ層を押さえられると、ゲストOS内のエンドポイント防御を迂回して大量のVMを一度に暗号化できてしまうため、攻撃者側の効率が段違いに良くなります。

そしてCVE-2023-34048は、今回と同じくvCenterの内部サービスに存在するメモリ破壊系の欠陥でした。vCenterの内部サービスが未認証で到達可能な状態にあることのリスクは、今回が初めて指摘されたわけではありません。過去の事例で管理面の露出を絞れていたかどうかが、今回の暴露面の広さをそのまま決めています。

2026年に入ってからの他の事案も含めた全体傾向は2026年の主要セキュリティインシデントまとめ、月次のパッチ量の推移は2026年7月のPatch Tuesdayの記録的なCVE数で振り返れます。管理コンソールの認証バイパスという同型の問題としてはCheck Point SmartConsoleの認証バイパスCVE-2026-16232も参考になります。

運用者が今すぐやること

• 組織内のvCenterとESXの台数、バージョン、ビルド番号を洗い出します。vCenterのビルドはvSphere ClientのSummaryタブで確認できるほか、PowerCLIでConnect-VIServerした後に$global:DefaultVIServer.Buildと$global:DefaultVIServer.Versionから取得できます。
• ESX側はPowerCLIで一括取得できます。

Get-VMHost | Select-Object Name,Version,Build

• vCenterの管理インターフェースやSyslogの待ち受けポートが、意図しない範囲から到達可能になっていないかを外部および内部から実測で確認します。

• 該当する修正版を適用します。VAMIやvSphere Lifecycle Managerなど標準の更新機構が使えます。ESXの新バージョンがLifecycle Managerに出てこない場合は、定期同期を待たずにvCenterでデポの同期を手動実行します。
• 8.0系で当面Update 3へ上げられない場合は8.0 U2fという選択肢がありますが、解決されるのはこのアドバイザリのCriticalなCVEのみである点を理解した上で選びます。
• 適用前にバックアップとロールバック手順を確認します。back-in-time制限がアップグレード計画に影響しないかも先に確認します。

Broadcomは実悪用を示す情報はないとしていますが、露出していた環境では確認しておく価値があります。ただし公式なIoC(侵害指標)は本記事執筆時点で公開されていません(未確認)。したがって以下は一般的な観点であり、確定的な検知手順ではありません。

• vCenter SSOのユーザーおよびグループに、身に覚えのないアカウントや権限付与が増えていないかを確認します。
• vCenterのグローバル権限、ロール割り当て、ソリューションユーザーの構成に意図しない変更がないかを点検します。
• vCenterおよびESXのログを、可能な限り外部のログ基盤へ転送済みの状態で確認します。侵害された機器の中のログだけを根拠にすると、改ざんの可能性を排除できません。
• ログの保全を優先します。再構築や初期化を急ぐと、何が起きたのかを後から追えなくなります。

• vCenterの管理インターフェースをインターネットから直接到達できない位置に置きます。管理面はVPNや踏み台経由に限定するのが原則です。
• 管理系ネットワークを業務ネットワークからセグメント分離し、到達元を明示的に絞ります。
• 管理面へのアクセス経路そのものを固く保つ設計はSSHのハンドシェイクと鍵認証の解説が参考になります。通信経路の保護についてはTLS 1.3のハンドシェイク解説もあわせてどうぞ。
• VMware Security Advisoryのメーリングリストを購読し、次のVMSAを能動的に受け取れる状態にします。

設計上の教訓

自分たちがVMwareのコードを書くわけではありませんが、今回の構図は一般的なシステム設計にそのまま当てはまります。

vmdirのようにアイデンティティ情報を集約するサービスは、可用性の面でも、セキュリティの面でも単一障害点です。CWE-303が示すとおり、認証の実装に1つ誤りがあるだけで、その上に積み上げた認可の階層が丸ごと意味を失います。認証処理は自前で書き足すのではなく、実績のある方式に寄せ、変更時は必ず境界ケースを含めてテストする。当たり前ですが、これを守り続けるのが難しいことを示す事例です。

Syslogのようなログ収集機構は「受け取るだけ」に見えますが、実際にはファイルシステムへの書き込みを伴います。外部由来の文字列がパス組み立てに関与する設計は、それだけで攻撃面になります。パスは必ず正規化した上で基準ディレクトリ配下であることを検証し、可能なら入力由来の文字列をパス要素に使わない設計へ寄せる。これはvCenterに限らず、自作のアップローダやログ収集APIでも同じです。

回避策のない9.8の脆弱性が出たとき、被害の大小を分けるのは「そのサービスにどこから到達できたか」です。管理面を業務ネットワークから分離し、到達元を絞っていた環境は、パッチ適用までの時間を稼げます。逆にインターネットへ露出していた環境には猶予がありません。ネットワーク設計は脆弱性を消しませんが、脆弱性が公表されてから対応するまでの時間を買うという意味で、繰り返し効いてきます。

まとめ

VMSA-2026-0006は、VMware vCenterに存在する2件のCVSS 9.8脆弱性を中心に、ESX側の3件を含めた計5件を修正するアドバイザリです。

• CVE-2026-59309: VMware Directory Serviceの認証バイパス(CWE-303)。未認証・ネットワーク越しに認証を回避されうる。
• CVE-2026-59310: Syslogサーバのディレクトリトラバーサル(CWE-22)。未認証・ネットワーク越しに任意コード実行につながりうる。
• 回避策なし。vCenterは9.1.0.0300 / 9.0.2.0100 / 8.0 U3k(または8.0 U2f)へ更新する。
• ESXも対象。VMXNET3のVMエスケープCVE-2026-47876(9.3)を含む3件があり、vCenterだけ直しても終わりではない。
• 適用前に確認。back-in-time制限でVCF 9.xへのアップグレードがブロックされる。vCenterのQuick Patchは使えない。

実悪用の有無、公式IoC、脆弱なコードパスの詳細、PoCの公開状況といった項目は、一次情報で確定できなかったため本文で「未確認」と明示しました。判断の根拠は必ずBroadcomのアドバイザリ本体とCVEレコードでご確認ください。

参考リンク

• VMware Security Advisory VMSA-2026-0006(Broadcom Support Portal)
• VMSA-2026-0006 Questions & Answers(vmware/vcf-security-and-compliance-guidelines)
• CVE Record: CVE-2026-59309
• CVE Record: CVE-2026-59310
• CWE-303: Incorrect Implementation of Authentication Algorithm
• CWE-22: Improper Limitation of a Pathname to a Restricted Directory
• CISA: Known Exploited Vulnerabilities Catalog
• Rapid7: Critical VMware vCenter Vulnerabilities Allow Authentication Bypass and Remote Code Execution
• VMware Telco Cloud response to VMSA-2026-0006(KB 449886)
• Asynchronous Patching Guide(KB 88287)
• Back-in-time upgrade restrictions(KB 67077)
• VMware Product Interoperability Matrix
• VMware Ports and Protocols
• VMware Security Advisory Mailing List