【VMSA-2026-0006】VMware vCenter / ESXに緊急脆弱性(CVSS 9.8・認証不要・回避策なし)— 影響範囲と今すぐやるべき対処法

公開日:2026年7月31日 ／ 最終更新:2026年7月31日 ／ オレンジソフトウェア

この記事でわかること(TL;DR)

• 2026年7月29日、BroadcomがVMware製品の緊急アドバイザリ VMSA-2026-0006 を公開
• 修正されたのは5件の脆弱性。うち3件がCritical(緊急)、最高スコアは CVSSv3.1 9.8
• 特にvCenterの2件は「認証不要・ネットワーク到達だけで攻撃成立・公式ワークアラウンドなし」の三重苦
• 実環境での悪用は未確認(2026年7月31日時点)。悪用が始まる前の早急な対応が推奨される
• 結論:原則vCenterを最優先に、定例メンテを待たず緊急変更としてパッチ適用

【重要】本記事の位置づけについて(必ずお読みください) 本記事は、2026年7月31日時点で一般に公開されている情報をもとに、弊社が整理・要約したものです。正確性・完全性・最新性を保証するものではなく、記載内容には誤り・解釈の相違・その後の更新による陳腐化が含まれる可能性があります。バージョン番号・ビルド番号・適用手順などの実作業に関わる情報は、必ず下記の一次情報(Broadcom公式アドバイザリ)でご確認ください。 本記事の情報に基づく判断・作業によって生じたいかなる損害についても、弊社は責任を負いかねます。

一次情報は必ずこちらで確認してください:

• VMSA-2026-0006(Broadcom公式アドバイザリ)
• VMSA-2026-0006 Q&A(VMware公式GitHub)

こんにちはオレンジソフトウェアです。 脆弱性が見つかって、世界的に大変なことになってるので、今日はこの記事を書こうと思います。

非エンジニア向け:3分でわかる今回の脆弱性

何が起きたのか?

VMwareという、多くの企業が「サーバーの土台」として使っているソフトウェアに、深刻なセキュリティ上の欠陥が見つかりました。開発元のBroadcom社が2026年7月29日に修正プログラム(パッチ)を公開しています。

たとえ話で言うと

会社のサーバー環境を「マンション」にたとえると、こうなります。

• vCenter は、マンション全体の鍵を管理する「管理人室」
• ESX(ESXi) は、各部屋を仕切る「壁と床」
• VM(仮想マシン) は、入居者が住む「各部屋」

今回見つかった問題のうち、最も深刻な2件は「管理人室のドアが、鍵を持っていない人でも開けられてしまう」というものです。管理人室に入られると、全部屋の合鍵が手に入り、マンション全体が乗っ取られます。

もう1件の深刻な問題は「ある部屋の住人が、壁を破って建物全体の配線に触れられてしまう」というもの(専門用語で「VMエスケープ」)です。

flowchart LR
    A["攻撃者<br>(鍵を持っていない)"] -->|欠陥を悪用| B["管理人室<br>(vCenter)"]
    B -->|全部屋の合鍵| C["部屋1<br>(VM)"]
    B -->|全部屋の合鍵| D["部屋2<br>(VM)"]
    B -->|全部屋の合鍵| E["部屋3<br>(VM)"]
    style A fill:#ffcccc
    style B fill:#fff3cd

どのくらい危険なのか?

セキュリティの世界では、危険度を10点満点の「CVSSスコア」で表します。今回の最高スコアは 9.8/10 。ほぼ満点です。さらに悪いことに、

1. パスワードや事前の権限が不要(vCenterへネットワーク到達できる攻撃者なら、認証なしで悪用できる可能性がある)
2. ネットワークで届きさえすれば攻撃できる
3. パッチ以外の回避策が存在しない

という3条件が揃っています。この組み合わせは、そう頻繁には出てきません。

これは「AIが見つけた脆弱性」なの?

最近は「AIがソフトウェアの欠陥を自動発見した」というニュースが増えていますが、今回の5件はAIによる発見とは公表されていません。Broadcom公式アドバイザリの謝辞(Acknowledgments)には、Atredis Partners、STARLabs SG(ハッキングコンテスト「Pwn2Own」経由)、CrowdStrikeなど、いずれも人間のセキュリティ研究者・セキュリティ企業の名前が明記されています。つまり今回は「善意の専門家が先に見つけて、こっそりメーカーに報告してくれた」という、脆弱性対応としては最も望ましいパターンです。だからこそ、攻撃者より先にパッチを当てられる今のうちに対処することが重要です。

経営層・管理職として知っておくべきこと

• 現時点(2026年7月31日)で、実際の攻撃被害は確認されていません。ただし、この製品は過去に攻撃者から繰り返し狙われた実績があるため、早急な対応が推奨されます。
• 対処は「修正プログラムの適用」一択です。作業にはサーバーの再起動を伴う場合があり、一時的なシステム停止の調整が必要になることがあります。
• 情報システム部門から「緊急メンテナンスをしたい」と相談が来たら、定例スケジュールを待たせず、優先して承認してください。それが今回の一番のリスク削減になります。

エンジニア向け:5件の脆弱性の技術詳細

一覧表

発見の経緯 — AIによる発見なのか?

結論:AIによる発見であるとは公表されていません。 VMSA-2026-0006の各Acknowledgmentsには、上表のとおり実名の研究者・企業のみがクレジットされており、AIツールやAIエージェントによる発見であるとの記載はBroadcom・報告元のいずれからも出ていません。

• vCenterの2件(59309 / 59310)は、ペネトレーションテスト企業 Atredis Partners の研究者2名による報告。
• VMエスケープ(47876)は、Zero Day Initiative(ZDI)主催のハッキングコンテスト「Pwn2Own」 で実証され、STARLabs SGの研究者からBroadcomへ報告されたもの。Pwn2Ownは人間の研究者が実機デモで脆弱性を実証する形式のコンテストです。
• 残る2件も、独立研究者およびCrowdStrikeの研究者による報告です。

近年、AIを活用した脆弱性発見(Google Project ZeroのBig Sleepなど)が実際にCVE取得に至る事例は出てきていますが、今回のVMSA-2026-0006はそのカテゴリではなく、従来型の人間の研究者による責任ある開示(coordinated disclosure) です。5件すべてが非公開でBroadcomへ報告され、パッチ公開と同時に開示された点も含め、脆弱性ハンドリングとしては教科書どおりの流れと言えます。なお、報告者が調査の過程で内部的にAIツールを併用したかどうかまでは公表されていないため、その可能性を完全に否定するものではありません。

攻撃経路の全体像

flowchart TD
    subgraph 経路A["経路A:外部からの直接侵入(第1段階)"]
        A1["攻撃者<br>ネットワーク到達性のみ"] -->|CVE-2026-59309<br>認証バイパス| VC["vCenter<br>管理プレーン掌握"]
        A1 -->|CVE-2026-59310<br>ディレクトリトラバーサル→RCE| VC
    end
    subgraph 経路B["経路B:侵害済みVMからの拡大(第2段階)"]
        B1["ゲストVM内で<br>ローカル管理者権限を保持"] -->|CVE-2026-47876<br>VMXNET3 OOB Write| ESX["ESXホストで<br>任意コード実行<br>(VMエスケープ)"]
    end
    VC -->|全ESXiホストの<br>管理権限を取得| ESX
    ESX --> ALL["同一ホスト上の<br>全ワークロードが危殆化"]
    style A1 fill:#ffcccc
    style B1 fill:#ffe0cc
    style VC fill:#fff3cd
    style ESX fill:#fff3cd
    style ALL fill:#f8d7da

注意: CVE-2026-59309と59310は独立した脆弱性であり、Broadcomは両者を連鎖させる攻撃シーケンスを公表していません。ただし、どちらも「vCenterへのネットワーク到達」だけが前提条件である点で、リスクの性質は同じです。

CVE-2026-59309 — vCenterの認証バイパス(CVSS 9.8)

vCenterがID基盤として使用する VMware Directory Service に存在する認証バイパスです。vCenterにネットワーク到達できる攻撃者が、認証を経ずに管理システムへ不正アクセスできます。事前の認証情報もユーザー操作も不要です。

vCenterは全ESXiホスト・全VM・データストア・ネットワーク構成を束ねる単一の管理面です。ここが抜かれるということは、配下の仮想基盤全体の管理権限が渡るのとほぼ同義と考えるべきです。

Broadcomはバイパスの具体的な内部メカニズム(脆弱なエンドポイント・プロトコル等)を非公開としています。IoCベースの検知に頼らず、まずパッチで塞ぐという判断が必要です。

CVE-2026-59310 — vCenter Syslogサーバのディレクトリトラバーサル(CVSS 9.8)

vCenterのSyslogサーバにおけるディレクトリトラバーサルで、ネットワークアクセスのみで任意コード実行に至ります。これも認証不要です。

CVE-2026-47876 — ESXのVMエスケープ(CVSS 9.3)

VMXNET3仮想NIC の実装における境界外書き込みです。ゲストVM内でローカル管理者権限を持つ攻撃者が、ESXホスト上で任意コードを実行できます。Broadcomはこれを明確に「VMエスケープ」と表現しています。本件はPwn2Own(ZDI)経由でSTARLabs SGの研究者から報告されたものです。

運用者として押さえるべき点は2つ:

• VMXNET3以外の仮想アダプタ(E1000/E1000E等)は影響を受けません。 影響範囲の切り分けに使えます。
• ゲスト内のVMware Toolsを更新しても対策になりません。 脆弱なコードはESX側にあり、ハイパーバイザ本体の更新が唯一の解決策です。

VMXNET3は準仮想化ドライバとして事実上の標準であり、「うちは使っていない」というケースは稀です。弊社が把握する範囲でも、テンプレート展開したLinux/Windows VMはほぼ全数がVMXNET3でした。

CVE-2026-41703 — 境界外読み取り(ESX: CVSS 7.6 / Workstation・Fusion: CVSS 2.7)

VM展開権限を持つ攻撃者が悪用でき、ESXでは情報漏えいまたはDoS(より可能性が高いのはホストプロセスのDoS)につながり、CVSS 7.6(Important)と評価されています。一方、Workstation / Fusionでは影響が情報漏えいに限定されるため、公式のResponse MatrixではCVSS 2.7(Low)と別評価になっています。「41703 = 7.6」と一律に扱わず、製品ごとにリスク評価を分けてください。

CVE-2026-41709 — ログ記録の不備(CVSS 2.7)

悪意ある管理者が特定の操作をログに残さず実行できます。スコアは低いものの、インシデント調査時の証跡を毀損するタイプの問題であり、監査ログを前提に運用設計している環境ではスコア以上の意味を持ちます。

影響を受けるバージョンと修正版

「うちは関係ない」はほぼ成立しない

VMSA-2026-0006の影響対象は、修正版より前の ESX / vCenter / Workstation / Fusion 全バージョンです。さらに、これらを内包する以下の製品もすべて影響を受けます。

• VMware Cloud Foundation(5.x / 9.0.x.x / 9.1.x.x)
• VMware vSphere Foundation
• VMware Telco Cloud Platform / Telco Cloud Infrastructure

Broadcom自身が「影響を受けるか疑問がある場合、おそらく影響を受けている。直ちに対処すべき」と明記しています。この書き方をするアドバイザリは多くありません。

命名についての補足: 今後、現行サポート対象のハイパーバイザを指す用語として「ESX」と「ESXi」は同義に使われます。ただしパッチ名・ビルド識別子は引き続き ESXi プレフィックスを保持するため、アドバイザリ本文とビルド番号で表記が揺れて見えます。

vCenter(CVE-2026-59309 / CVE-2026-59310)

※ CVE-2026-59309は9.1.0.0200で最初に修正されましたが、パッチは累積的であるため、現時点の最新版 9.1.0.0300 の適用が推奨されます。

8.0系ユーザーへの注意: vCenter 8.0 U3kから9.1.0系への直接アップグレードは現時点で非サポートです(9.1.xへのアップグレードパスは将来のリリースで提供予定)。近々9.1系への移行を計画している場合は、リリースノートでアップグレードパスを確認してから適用順序を決めてください。

ESX / Workstation / Fusion

パッチは累積的なので、5件それぞれに個別対応する必要はありません。8.0系であれば ESXi80U3k-25595708 まで上げれば上表3件すべてがカバーされます。Telco Cloud製品はBroadcom KB449886に従ってください。

バージョン・ビルド番号の最終確認は必ずVMSA本文で行ってください。 ブログや二次情報(本記事を含む)の転記ミスで違うビルドを適用するのが、この手の作業で一番ありがちな事故です。VMSAが唯一の正(Source of Truth)です。

悪用状況(2026年7月31日時点)

• Broadcomは、5件いずれについても実環境での悪用を確認していないとしています。
• Rapid7も7月30日時点で、59309 / 59310について実環境での悪用・スキャン活動の痕跡は確認されておらず、公開されたPoCコードも存在しないと報告しています。
• 5件はいずれもBroadcomへ非公開で報告(coordinated disclosure) されたものです。

とはいえ、これを「猶予がある」と読むのは危険です。vCenterは過去にCISAのKEV(既知の悪用脆弱性)カタログに10回掲載されており、攻撃者がこの製品の重大な脆弱性を継続的に狙ってきた実績は明確です。CVSS 9.8・認証不要・ワークアラウンドなしという条件が揃っている以上、PoCの公開や悪用の確認を待たず、早急にパッチ適用へ動くことが推奨されます。

運用現場での適用手順と落とし穴

ここからは、複数ホスト・複数クラスタを実際に回している立場からの話です。

優先順位は「原則vCenterが先」

原則としてvCenterを最優先とすべきです。理由は攻撃の前提条件の差です。

• CVE-2026-47876(VMエスケープ) は、攻撃者が「すでにゲストVM内でローカル管理者権限を取得している」ことが前提。つまり侵害の第2段階。
• CVE-2026-59309 / 59310 は、ネットワーク到達性だけが前提。侵害の入口そのものになり得ます。

しかもvCenterが陥落すれば配下のESXiホストへの管理権限が手に入るため、ゲストVMを起点にしなくてもハイパーバイザ制御に到達する経路が成立します。入口を先に閉じるのが合理的です。

ただし、vCenter先行は絶対のルールではありません。 公式Q&AもvCenter先行をあくまで対応例の一つとして示しており、環境によってはESXを先行または並行して更新する判断も認められています。停止可能時間(メンテナンスウィンドウ)の制約や、ESX Live Patchの対応状況、マルチテナントホストのリスク評価に応じて、vCenterとESXの並行対応も含めて自環境に合った順序を計画してください。

flowchart LR
    P1["1. vCenter<br>緊急変更として即時"] --> P2["2. ESX<br>マルチテナント/共有ホスト優先"] --> P3["3. Workstation / Fusion<br>端末管理の枠で展開"]
    style P1 fill:#f8d7da
    style P2 fill:#fff3cd
    style P3 fill:#d4edda

ESXパッチ適用のワークフロー

CVE-2026-47876の修正適用には、ESXホストの再起動が必要になる場合があります。Broadcom推奨の流れは次のとおりです。

flowchart TD
    S1["vMotion不可VMの棚卸し<br>(パススルー/vGPU/EVC外/ISO放置)"] --> S2{"ESX Live Patch<br>対象ブランチ?"}
    S2 -->|対象| S3["Live Patchで適用<br>(停止時間を最小化)"]
    S2 -->|対象外| S4["vMotionでワークロード退避"]
    S4 --> S5["ローリングリブートで<br>クラスタを順次パッチ"]
    S5 --> S6["移行不可VMは<br>再起動中のみ計画停止"]
    S3 --> S7["ビルド番号をVMSA本文と突合<br>→ 完了確認"]
    S6 --> S7

ESX Live Patch が使える環境では停止時間を削減できますが、ソースビルドとターゲットビルドの組み合わせでサポート可否が製品ブランチごとに異なります。該当ブランチのリリースノートで必ず事前確認してください。確認せずに計画を立て、当日「Live Patch対象外でした」となるのが一番痛いパターンです。

移行できないVMの棚卸しが実は一番の作業量

弊社の経験上、ローリング適用で工数が読めなくなるのはパッチそのものではなく「vMotionできないVMの洗い出し」です。典型的には以下が引っかかります。

• 物理デバイス/USBドングルをパススルーしているVM(ライセンスサーバに多い)
• CPU互換性の都合でEVCモードから外れているVM
• vGPU / DirectPath I/O を使用しているVM
• ISOやローカルデータストアをマウントしたまま放置されているVM

パッチ計画に入る前にまずこのリストを作れば、必要な計画停止の範囲と顧客への調整事項がほぼ決まります。

事後の調査範囲は「そのVMだけ」では足りない

万一CVE-2026-47876の悪用が疑われた場合、調査を起点のゲストVMだけに閉じてはいけません。ホストへのコード実行が成立している前提で、ESXホスト本体・同一ホスト上の他ワークロード・vCenterの操作履歴・特権アカウント・基盤系の認証情報まで範囲を広げる必要があります。

CVE-2026-59309側の調査では、vmdirdのログディレクトリ配下のVMware Directory Serviceログ、Web SSO・トークン関連ログ、VCSAの監査/サービスヘルスログ、IdP・MFAイベント、VPNや踏み台のログ、ファイアウォールのフローログなどを相関させて見る必要があります。単体で判定できる公式なIoC文字列は公開されていません。

ネットワーク露出の見直しを同時に

パッチと並行して、vCenterのネットワーク露出を必ず点検してください。vCenterがインターネットから到達可能であってはなりません。 管理トラフィックはVPN配下または管理用VLANに隔離し、既知の管理元IPからのみ到達できるようファイアウォールで制限するのが基本です。

今回の2件はワークアラウンドがないため、パッチ適用までの時間を稼ぐ手段は「到達性を減らすこと」しかありません。即日パッチが難しい環境では、まずここを絞ってください。

サポート終了バージョンを使っている場合

vSphere 7 は 2025年10月2日に一般サポート終了。6.5 / 6.7 も当然サポート外です。これらを運用している場合は影響を受けているものとして扱い、サポート対象の修正済みリリースへの移行を最優先で計画してください。オフラインパッチの適用可否はBroadcomサポートポータルで個別確認が必要です。

よくある質問(FAQ)

Q. 実際に攻撃は発生していますか? A. 2026年7月31日時点で、Broadcom・Rapid7ともに実環境での悪用・スキャン活動・公開PoCは確認していません。ただしvCenterは過去にCISAのKEVカタログへ10回掲載された「狙われ続けている製品」であり、猶予があるとは考えないでください。

Q. パッチを当てる以外の回避策はありますか? A. vCenterの2件(CVE-2026-59309 / 59310)には公式ワークアラウンドがありません。パッチ適用までの間は、vCenterへのネットワーク到達性をVPN・管理VLAN・ファイアウォールで最小化することが唯一の時間稼ぎです。

Q. VMware Toolsを更新すればVMエスケープ(CVE-2026-47876)は防げますか? A. 防げません。 脆弱なコードはESX側にあり、ハイパーバイザ本体の更新が唯一の対策です。

Q. E1000など、VMXNET3以外のNICを使っているVMは安全ですか? A. CVE-2026-47876に関しては、VMXNET3以外の仮想アダプタは影響を受けません。ただしvCenter側の2件はNICの種類と無関係に影響するため、パッチ適用は必要です。

Q. どの順番でパッチを当てるべきですか? A. 原則は「vCenter → ESX(マルチテナント/共有ホスト優先) → Workstation / Fusion」です。認証不要でネットワークから直接攻撃できるvCenterを最優先とするのが合理的です。ただしこれは絶対のルールではなく、停止可能時間やESX Live Patchの対応状況によっては、ESXの先行・並行対応も選択肢になります。自環境の条件に合わせてご判断ください。

Q. vSphere 7 / 6.x を使っています。どうすればいいですか? A. すでに一般サポートが終了しています。影響を受けているものとして扱い、サポート対象バージョンへの移行を最優先で計画してください。

Q. これはAIが発見した脆弱性ですか? A. いいえ、そのようには公表されていません。Broadcom公式アドバイザリの謝辞には、Atredis Partners(vCenterの2件)、STARLabs SG(Pwn2Own経由のVMエスケープ)、独立研究者、CrowdStrikeと、すべて人間の研究者・企業がクレジットされています。AIツールによる発見であるとの発表はどこからも出ていません。

もしVMware管理者だったとしたら?やることチェックリスト

• [ ] VMSA-2026-0006本文で、自環境のバージョン・ビルドを突き合わせる
• [ ] vCenterのインターネット露出/到達可能範囲を即時点検する
• [ ] vCenterを緊急変更としてパッチ適用する(定例メンテ枠に入れない)
• [ ] 8.0系の場合、9.1系への将来のアップグレードパス(現時点でU3k→9.1.0直接は非サポート)を確認する
• [ ] vMotion不可VMの棚卸しリストを作成する
• [ ] ESX Live Patchの対象可否をブランチごとのリリースノートで確認する
• [ ] マルチテナント/複数チームのワークロードが同居するホストからESXパッチを優先適用する
• [ ] サポート終了バージョンの有無を確認し、移行計画に着手する

CVSS 9.8・認証不要・ワークアラウンドなしという3条件が揃った脆弱性は、そう頻繁には出てきません。実環境での悪用が確認されていない段階だからこそ、慌てず、しかし先送りせずに計画を立てて対処することをおすすめします。

おわりに — 弊社の脆弱性情報への取り組み

オレンジソフトウェアでは、お客様環境を含む複数の仮想基盤を運用する立場から、主要ベンダーの脆弱性情報を可能な限り早期に確認し、影響範囲の評価と対応方針の検討を速やかに行うことを心がけています。

今回のVMSA-2026-0006のように、認証不要かつ回避策のない重大な脆弱性は、公開から対応までの時間がそのままリスクに直結します。弊社では、

• 主要ベンダーのセキュリティアドバイザリの継続的な確認
• 自社および運用受託環境への影響範囲の洗い出し
• 緊急度に応じた適用計画の立案とお客様へのご説明
• 適用後の稼働確認と記録

といった一連の流れを、日々の運用業務の一部として実施しています。

とはいえ、脆弱性への対応は一社だけで完結するものではありません。本記事のような情報整理が、同じように仮想基盤を預かる方々の判断材料として少しでもお役に立てば幸いです。自社環境の対応方針の検討や、パッチ適用作業のご相談がありましたら、お気軽にお問い合わせください。

なお、本記事の内容に誤りや補足すべき点を見つけられた場合も、ぜひご指摘いただけますと幸いです。いただいたご指摘は確認のうえ記事に反映し、更新履歴に記載いたします。

参考情報源(Sources)

一次情報(必ずここで最終確認を)

1. VMSA-2026-0006 — Broadcom公式セキュリティアドバイザリ 2026年7月29日公開。影響製品・修正バージョン・CVSSベクトル・報告者謝辞の唯一の正。
2. VMSA-2026-0006 補足Q&A(VMware公式GitHubリポジトリ) 影響判定と運用対応の補足FAQ。短縮URLはbrcm.tech/vmsa-2026-0006。
3. VMware vCenter 8.0 Update 3k リリースノート(Broadcom Techdocs) 8.0系の修正版詳細と、8.0 U3kから9.1.0への直接アップグレードが非サポートである旨の注記。
4. VMware ESXi 8.0 U3k リリースノート(Broadcom Techdocs) ESXi80U3k-25595708 のビルド詳細。
5. Broadcom KB88287 — VMware Cloud Foundation 非同期パッチ適用ガイド VCF 5.x環境で8.0 U3kへ非同期パッチを適用する場合の手順。
6. Broadcom KB449886 — Telco Cloud Platform / Infrastructure 向け対応手順 Telco Cloud製品を利用している場合の修正版と適用方法。
7. MITRE CVE辞書:CVE-2026-59309 CVE-2026-59310 / 47876 / 41703 / 41709 も同サイトで参照できます。

二次情報(悪用状況・分析)

8. Rapid7 Emergent Threat Response:vCenterの認証バイパスとRCEに関する分析 2026年7月30日公開。悪用・スキャン活動・公開PoCの有無、vCenterのCISA KEV掲載歴(過去10回)に関する分析。
9. VMware Security Blog VMSAの公開告知一覧。今後の追加アドバイザリはここで確認できます。
10. CISA Known Exploited Vulnerabilities (KEV) Catalog 実悪用が確認された場合の掲載先。継続的な監視を推奨します。

免責事項

本記事(以下「本記事」)は、2026年7月31日時点でインターネット上に公開されていた情報(Broadcom社の公式セキュリティアドバイザリ、各ベンダーのリリースノート、セキュリティ企業の公開分析等)をもとに、弊社が独自に整理・要約・翻訳したものです。ご利用にあたり、以下の点をご了承ください。

1. 正確性・完全性の非保証 本記事の作成にあたっては可能な限りの確認を行っていますが、内容の正確性・完全性・有用性を保証するものではありません。原文の解釈相違、転記・翻訳の誤り、記載漏れが含まれる可能性があります。

2. 情報の陳腐化について 脆弱性に関する情報(悪用状況、修正バージョン、推奨される対応方針等)は日々更新されます。本記事は執筆時点の情報に基づいており、閲覧時点ではすでに状況が変化している可能性があります。特に「実環境での悪用は未確認」との記載は2026年7月31日時点のものであり、その後の悪用開始やPoC公開の有無は別途ご確認ください。

3. 一次情報の優先 バージョン番号、ビルド番号、影響範囲、適用手順など、実際のパッチ適用作業に直結する情報については、Broadcom社の公式アドバイザリ(VMSA-2026-0006)およびBroadcomサポートポータルの記載を唯一の正(Source of Truth)としてください。 本記事の記載と一次情報に相違がある場合は、一次情報が優先されます。

4. 個別環境への非適用 本記事に記載した優先順位、適用手順、注意点は一般的な考え方を示したものであり、すべての環境に当てはまるものではありません。実際の対応方針は、各組織の構成・要件・リスク評価に基づき、自組織の責任においてご判断ください。 必要に応じてBroadcom社のサポートまたは専門のセキュリティベンダーへご相談ください。

5. 免責 本記事の情報を利用したことにより生じた、いかなる損害(直接的・間接的を問わず、システム障害、データ損失、事業機会の損失等を含みます)についても、弊社は一切の責任を負いかねます。

6. 商標等 VMware、vCenter、ESX、ESXi、vSphere、Workstation、Fusion等は、Broadcom Inc. またはその関連会社の商標または登録商標です。本記事は同社と提携・協賛関係にあるものではありません。

7. 訂正のご連絡 記載内容に誤りを発見された場合は、お手数ですがお問い合わせフォームよりご連絡いただけますと幸いです。確認のうえ速やかに訂正し、更新履歴に記載いたします。

更新履歴

最終更新:2026年7月31日 ／ 修正バージョン・ビルド番号の最終確認は必ず一次情報であるBroadcom公式アドバイザリ(VMSA-2026-0006)で行ってください。