CVE-2026-59310 vCenter 脆弱性｜影響確認と侵害調査

はじめに

VMware vCenter に、CVSS v3.1 で 9.8 と評価された脆弱性 CVE-2026-59310 が公表されています。Broadcom は 2026 年 7 月 29 日にセキュリティアドバイザリ VMSA-2026-0006 を公開しましたが、その後インシデントレスポンス調査で実際の悪用が確認され、2026 年 8 月 18 日には CISA の Known Exploited Vulnerabilities カタログ（KEV）にも追加されました。

要点を先に示します。CVE-2026-59310 は vCenter の Syslog server における directory traversal で、Broadcom は「vCenter へネットワーク到達できる攻撃者による任意コード実行」と説明しています。Broadcom は回避策を提示しておらず、修正版への更新が唯一の正式な対処です。さらに、アドバイザリ公開の数日後には侵害されたシステムから攻撃者インフラへの通信が観測されているため、現在すでに修正版へ更新済みであっても、脆弱な期間に vCenter へ到達できる経路があった環境では侵害痕跡の確認まで行う判断が必要になります。

CVE-2026-59310 で何が起きるのか

CVE-2026-59310 は、vCenter の Syslog server に存在する directory traversal（CWE-22）です。CVSS v3.1 のベーススコアは 9.8、ベクターは AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H で、PR:N（権限不要）かつ UI:N（ユーザー操作不要）であることから、vCenter へネットワーク到達できれば認証なしで悪用され得ます。

参考: VMSA-2026-0006.1（Broadcom）
“with network access to vCenter may exploit this issue to execute arbitrary code”
（vCenter へネットワークアクセスできる攻撃者が、任意コードを実行するためにこの問題を悪用する可能性があります）
https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017

Broadcom の Supplemental FAQ でも、この 2 件の vCenter の脆弱性は認証されていない攻撃者が悪用し得るものとして整理されています。

一方で、directory traversal がどのような経路で任意コード実行に至るのか、その内部メカニズムについて Broadcom と発見者は詳細を公開していません。本記事では一般的な path traversal の知識から推測して補完することはせず、ベンダーが確認している事実と、インシデントレスポンス調査で観測された攻撃後の挙動を分けて扱います。

なお本脆弱性は、Atredis Partners の Phil Brass 氏と Matt South 氏から Broadcom へ非公開で報告されたものです。

同じアドバイザリの CVE-2026-59309 との関係

VMSA-2026-0006.1 には、vCenter に関するもう 1 件の Critical な脆弱性 CVE-2026-59309 も含まれています。こちらは VMware Directory Service の authentication bypass で、CVSS v3.1 は同じく 9.8、ネットワーク到達できる攻撃者が認証を迂回して不正アクセスする可能性があるとされています。

実務上の押さえどころは次の 3 点です。

• 脆弱性の種類と影響は CVE-2026-59310 と異なる（認証迂回であり、任意コード実行ではない）
• 同じ vCenter 更新で両方が修正されるため、対応作業としては 1 回で済む
• 9.1 系では CVE-2026-59309 が 9.1.0.0200 で先に修正されているが、パッチは累積型のため現行の 9.1.0.0300 を適用すれば両方が含まれる

CVE-2026-59309 についても攻撃が観測されていますが、後述する調査では CVE-2026-59310 の活動と強く結び付けられておらず、別トラックの活動として扱われています。公開情報の範囲では、2 つの脆弱性が実際の攻撃でチェーンされたと断定することはできません。

公開から実悪用確認・KEV 追加までの経緯

この脆弱性は、アドバイザリ公開時点の情報と、その後に明らかになった実悪用の情報を分けて読む必要があります。時系列は次のとおりです。

実悪用の観測内容

ドイツの DFIR 企業である QUIRSO は、インシデントレスポンス業務を通じて本脆弱性の悪用キャンペーンを検出し、47 か国にわたる 361 件の被害 IP アドレスを特定したと報告しています。

参考: Active exploitation of CVE-2026-59310（QUIRSO GmbH）
“first connected to the attacker’s infrastructure only five calendar days later on 3 August”
（攻撃者のインフラへ最初に接続したのは、わずか 5 暦日後の 8 月 3 日でした）
https://medium.com/@quirso_de/active-exploitation-of-cve-2026-59310-361-victim-ips-across-47-countries-9783187cc6ff

ここで押さえておきたいのは、この 8 月 3 日という日付が 侵害されたシステムから攻撃者インフラへの通信が観測された時点であり、攻撃そのものの開始日時とは区別して読む必要があるという点です。侵害から通信の観測までには時間差が生じ得るため、調査範囲の起点をこの日付に固定することは避けるほうが安全です。

もう 1 点、361 件・47 か国という数字は QUIRSO の観測範囲であり、世界全体の被害件数ではありません。 QUIRSO 自身も、ホスティング事業者やクラウド、共用インフラのアドレスが含まれるため、IP アドレス数がそのまま被害組織数を意味するわけではないと注記しています。攻撃者については、中国語の痕跡や活動時間帯などから中国語話者による活動と中程度の確度で評価されていますが、特定の攻撃グループへの紐付けには至っていません。

情報源ごとの記載時点の違い

本脆弱性は、情報源によって記載されている内容の時点が異なります。実務では次の順で整理すると混乱しにくくなります。

Broadcom の Supplemental FAQ

本記事の執筆時点（2026 年 8 月 19 日）でも、in the wild での悪用を示す情報は把握していないという趣旨の記述が残っています

QUIRSO

2026 年 8 月 10 日および 15 日に公開した調査で、侵害の痕跡と攻撃後の挙動を報告しています

Shadowserver

2026 年 8 月 13 日から、QUIRSO の特定した被害システムに対する通知を開始しています

CISA

2026 年 8 月 18 日に KEV へ追加し、SSVC の Exploitation を active へ更新しています

つまり、FAQ には悪用情報なしの記述が残る一方で、その後 CISA KEV、QUIRSO、Shadowserver によって実悪用が確認された、という時系列になります。対応方針を検討する際は、より新しい情報源の内容もあわせて確認することをおすすめします。

CISA KEV での扱い

CISA は 2026 年 8 月 18 日に CVE-2026-59310 を KEV へ追加しました。Required Action では、2026 年 6 月 10 日発行の BOD 26-04（従来の BOD 22-01 を置き換えるもの）に基づく対応と、Forensics Triage Requirements への準拠が求められています。CISA が付与した SSVC 値は Exploitation: active、Automatable: yes、Technical Impact: total です。Due Date は 2026 年 8 月 21 日です。

この期限は米国連邦政府機関を対象とした拘束的運用指令に基づくもので、一般企業に同じ期限が義務付けられるものではありません。ただし、BOD 26-04 が修正の適用だけでなくフォレンジックトリアージまで求めている点は、対応方針を検討するうえで参考になります。

影響を受けるバージョンと自環境の確認方法

VMSA-2026-0006.1 の Response Matrix に基づく、vCenter の修正版は次のとおりです。パッチは累積型のため、記載の修正版またはそれ以降であれば本脆弱性は解消されています。

参考: VMware vCenter 8.0 Update 3k Release Notes（Broadcom）
“This release resolves CVE-2026-59309 and CVE-2026-59310.”
（このリリースは CVE-2026-59309 と CVE-2026-59310 を解決します）
https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/vcenter-server-update-and-patch-release-notes/vsphere-vcenter-server-80u3k-release-notes.html

ここで見落としやすい点があります。修正版はいずれも 2026 年 7 月 29 日以降のリリースです。 つまり、それ以前から対象ブランチの vCenter を運用していた環境には、程度の差はあれ脆弱な期間が存在したことになります。現在の Version / Build が修正版以上であることは、過去に脆弱な期間がなかったことを意味しません。

Version / Build の確認方法

Broadcom の FAQ では、vCenter の Build 情報は vSphere Client の Summary タブで確認できるほか、PowerCLI からも取得できると案内されています。Connect-VIServerで接続したあと、次の変数を参照します。

Connect-VIServer -Server <vCenter の FQDN>

$global:DefaultVIServer.Version
$global:DefaultVIServer.Build

参考として、ESX ホスト側の Version / Build は次のコマンドで一覧できます。ただし CVE-2026-59310 は vCenter の脆弱性であり、ESX ホストの更新では解消しない点にご注意ください。

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

参考: VMSA-2026-0006 Questions & Answers（Broadcom / VMware 公式リポジトリ）
“virtual machine and container workloads will continue to run”
（仮想マシンおよびコンテナのワークロードは動作し続けます）
https://github.com/vmware/vcf-security-and-compliance-guidelines/blob/main/security-advisories/vmsa-2026-0006/README.md

Enhanced Linked Mode や IWA の利用有無は判定に使えない

構成条件で対象外になるかどうかを気にされる方が多い部分ですが、Broadcom は FAQ で明確に否定しています。Enhanced Linked Mode（ELM）を使っていなくても、Integrated Windows Authentication（IWA）を使っていなくても、脆弱性は vCenter 自体に存在するため影響を受けます。 認証ソースの構成にかかわらず、修正版への更新が対処になります。

サポート終了バージョンの扱い

Response Matrix には vSphere 7.0 以前の行がありません。ここを「対象外」と読むのは適切ではありません。Broadcom は FAQ で次のように整理しています。

vSphere 7.0 は影響を受ける

2025 年 10 月 2 日に End of General Support に到達しており、延長サポート契約があればそのプロセスを通じてパッチを要求する

vSphere 6.5 / 6.7 は影響を受けるものとして扱う

Broadcom は End of General Support を過ぎた製品をアドバイザリの評価対象としておらず、記載のない旧バージョンは影響を受けると想定するよう案内している

古い vSphere 環境を運用している場合、Response Matrix に載っていないことは安全の根拠になりません。到達性の制限や移行計画とあわせて、影響を受ける前提でリスクを評価することをおすすめします。

修正版への更新と作業時の注意点

稼働中の仮想マシンへの影響

運用担当者から最も多く挙がる疑問が「vCenter を更新すると仮想マシンも停止するのか」という点です。Broadcom の FAQ では、vCenter は vSphere 環境の管理インターフェースであり、更新中は vSphere Client をはじめとする管理手段が一時的に利用できなくなるものの、仮想マシンとコンテナのワークロードは動作し続けると説明されています。前掲の引用がその該当箇所です。

一方、同じアドバイザリに含まれる ESX 側の脆弱性（CVE-2026-47876 など）に対応する場合はホスト再起動が伴います。vMotion によるローリング更新や ESX Live Patch の利用を検討することになります。

Quick Patch と back in time 制約

作業計画に影響する制約が 2 つあります。

Quick Patch は利用できません

Broadcom は今回の vCenter 更新について Quick Patch の対象外としており、従来の vCenter パッチ適用手順、または構成済みであれば Reduced Downtime Upgrade（RDU）を使うことになります。vCenter 9.1.0.0300 と 8.0 U2f のリリースノートでも、Quick Patch は No と明記されています

back in time のアップグレード制約が発生します

vCenter 8.0 U3k のリリースノートには、8.0 U3k から 9.1.0 系へのアップグレードは現時点でサポートされず、将来の 9.1.x リリースで対応予定と記載されています。VCF 9.x へのアップグレードを計画中の環境では、適用タイミングを検討する余地があります

更新自体は VAMI を含む標準の更新機構で適用できます。VCF 環境では VCF Operations 経由での適用が案内されています。vCenter と ESX の適用順については、Broadcom Product Interoperability Matrix で組み合わせの互換性を確認したうえで判断することをおすすめします。

ネットワーク到達性の確認と、回避策がないことの意味

Broadcom の表現は「network access to vCenter」であり、インターネット公開の有無だけで影響を判断することはできません。実際には次のような経路からも vCenter へ到達できます。

• 管理ネットワーク
• VPN 経由のリモートアクセス
• 踏み台サーバー
• 侵害された内部端末やサーバー
• バックアップ、監視、構成管理といった他の管理基盤

ネットワーク分離や Firewall によるアクセス制限は攻撃面を縮小する compensating control になり得ます。ただし Broadcom は Workaround を None としており、これらの制御を正式な修正の代替として扱うことはできません。適用可能な緩和策は更新までの露出を減らすためのものであり、更新の代わりにはならないという整理が適切です。

更新だけで終わらせない侵害有無の確認

実悪用が確認されている脆弱性では、修正版へ更新しても、更新前にすでに侵害されていた可能性は解消されません。対応は次の 2 つの軸に分けて判定することをおすすめします。

軸 1: 現在の修正状態

現在の Version / Build が修正版未満かどうか。未満であれば更新の対象になる

軸 2: 過去の脆弱期間と到達性

修正版未満だった期間があり、その期間に到達可能な経路が存在したかどうか。存在したのであれば侵害確認の対象になる

この 2 つは独立しています。 すでに修正版へ更新済みの環境であっても、軸 2 に該当すれば侵害確認の対象です。前述のとおり修正版はいずれも 2026 年 7 月 29 日以降のリリースであるため、それ以前から運用している対象ブランチの vCenter は、軸 1 で対象外であっても軸 2 の検討が残ります。

軸 2 を整理するときの起点

まず、次の 2 点を書き出します。

1. vCenter が修正版未満だった期間はいつからいつまでか
2. その期間に、どのネットワークから vCenter へ到達できたか

観測されている最初の通信は 2026 年 8 月 3 日ですが、これは特定の調査における観測時点であり、攻撃の開始日時ではありません。調査範囲を安全側に取るなら、アドバイザリ公開日である 7 月 29 日、あるいは組織として説明できる最も古い露出時点まで遡る方法も検討に値します。

影響判定フロー

2 つの軸を図にすると次のようになります。

公開情報で報告されている侵害後の挙動

QUIRSO が公開した調査結果では、侵害後に次のような活動が観測されています。これらは特定のインシデントレスポンス案件での観測であり、すべての侵害で同じ痕跡が残るとは限りません。 確認の出発点として利用し、該当がないことをもって安全と判断することは避けるのが適切です。

cron を利用した実行と永続化

/etc/cron.d配下に不審なファイルが置かれ、crond のログに不正な cron 定義に関するエラーが記録されていた

VMware のサービス名を模した cron ジョブ

vmware-vpxd-stats-*、vmware-perf-collect-*、vmware-perf-sync-*といった名前で多数登録され、日常の目視確認では気付きにくい形になっていた

reverse_sshによる外向きの常時接続

オープンソースのリバース SSH ツールが導入され、侵害された側から外部へ接続を張ることで、受信方向の遮断を主眼とした防御を迂回していた

SSH の有効化と公開鍵の追加

SSH デーモンを有効化し、root のauthorized_keysへ攻撃者の公開鍵を追加する動作が繰り返し実行されていた

Web アプリケーション領域への webshell 配置と sudo 設定の変更

perfcharts の Web アプリケーションディレクトリへ JSP が置かれ、/etc/sudoers.d配下の追加によって権限昇格経路が用意されていた

管理アカウントの追加

vmdir の資格情報を取得したうえで vSphere SSO に管理者アカウントが作成され、Administrators グループへ追加されていた

ESXi 側への波及

ESXi ホストにローカルアカウントが作成され、データストア経由で実行ファイルが配置されたうえ、Babuk 派生のランサムウェアによる暗号化と vSphere HA エージェントの削除まで到達した事例が報告されている

Shadowserver は QUIRSO から提供されたデータをもとに Special Report として被害通知を行っており、報告対象については侵害されたものとして扱うべきとしています。

参考: VMware vCenter CVE-2026-59310 Exploitation Victim Special Report（The Shadowserver Foundation）
“the persistence mechanism has been deployed by the attackers on all victims reported”
（報告対象のすべての被害システムで、攻撃者により永続化機構が導入されています）
https://www.shadowserver.org/what-we-do/network-reporting/vmware-vcenter-cve-2026-59310-exploitation-victim-special-report/

各国の CERT やネットワーク事業者経由で Shadowserver の通知を受け取っている場合は、その時点で調査対象として扱うことをおすすめします。

確認時に注意したい 3 点

reverse_ssh単体を悪性判断の根拠にしない

QUIRSO も明記しているとおり、これは正規のペネトレーションテスト用途を持つデュアルユースツールです。検出は調査の起点として扱い、導入経緯、実行コンテキスト、想定外の外向き通信といった他の要素と突き合わせて判断します

痕跡が消されている前提で確認する

報告された事例では、役目を終えたスクリプトや cron 定義が削除され、ESXi のログは暗号化によって失われていました。ホスト上の痕跡が見つからないことは、侵害がなかったことの証明にはなりません。Firewall やプロキシ、フロー情報といった周辺機器の通信記録を併用する方法が有効です

ネガティブ所見も記録として残す

「どのログを、いつからいつまで、どの観点で確認したか」を残しておくと、後日の再調査や説明の際に判断の根拠になります。「既知の IoC と一致しなかったから安全」という書き方は避けるのが適切です

侵害が疑われる場合は、vCenter のマシンアカウント、SSO 上のアカウント、ESXi のローカルアカウントに加えて、vCenter へ接続する周辺製品が保持する資格情報の棚卸しも検討対象になります。監視やバックアップの製品が vCenter 資格情報を保持している構成については、関連記事『Veeam ONE の脆弱性で問われた資格情報の棚卸し』でも整理しています。

まとめ

CVE-2026-59310 は vCenter の Syslog server における directory traversal で、ネットワーク到達できる攻撃者による任意コード実行につながります。Broadcom は回避策を提示しておらず、修正版への更新が唯一の正式な対処です。アドバイザリ公開の数日後には侵害システムからの通信が観測されているため、更新の完了だけを対応の終点としない判断が求められます。

• CVSS v3.1 で 9.8、認証もユーザー操作も不要な脆弱性
• 修正版は 9.1.0.0300、9.0.2.0100、8.0 U3k、8.0 U2f
• Response Matrix に記載のない vSphere 7.0 以前も影響を受ける扱い
• ELM や IWA を使っていない環境も対象
• vCenter 更新中も仮想マシンのワークロードは継続
• Quick Patch 非対応と back in time 制約に注意
• 現在の修正状態と過去の脆弱期間は別軸での判定が必要

以上、最後までお読みいただきありがとうございました。