VMware Fusion脆弱性CVE-2026-41702｜クラウド移行検証ラボの即時対応とAWS WorkSpaces代替設計

「Macで動かしているVMware Fusionに権限昇格の脆弱性が出たらしいが、うちは検証ラボにしか使っていない。それでもAWS WorkSpacesやAzure Virtual Desktopへの移行を検討する潮目なのか」
オンプレ仮想基盤を20年以上扱ってきた立場で言えば、TOCTOU系のローカル権限昇格はパッチを当てれば終わりです。しかし「Macローカルに仮想化基盤を持つ」という構成そのものが、クラウド移行の波の中で本当に必要かは別の論点です。本記事はCVE-2026-41702の即時対応と、クラウド側のDaaS／VDI／Dev Boxへの代替設計を並列で整理します。

この記事では2026年5月14日にBroadcomから公開されたVMware Fusion 25H2の権限昇格脆弱性（CVE-2026-41702、CVSS 7.8）について、ローカル仮想化運用への影響、緊急対応手順、クラウド側VDI／DaaSサービスへの移行検討、IaC（Terraform）でのクラウド仮想化リソース設計、コスト試算までを「クラウド移行検証ラボとしてのFusion」視点で解説します。Mac端末のエンドポイントセキュリティ視点はSecurityMasters.TOKYO側で別途扱います。

2026年5月、VMware Fusionで何が公表されたか（CVE-2026-41702の一次情報整理）

まずは伝聞を排し、Broadcom Security AdvisoryとJPCERT/CC週次レポートの一次情報を整理します。

JPCERT/CC週次レポート2026-05-20【5】では、VMware Fusionに権限昇格の脆弱性があるとの注意喚起がなされ、参照先としてBroadcomのSecurity Advisory VMSA-2026-0003が示されました。クラウド運用者として押さえるべきポイントは次のとおりです。
・CVE-2026-41702: VMware Fusion 25H2のSETUIDバイナリにおけるTOCTOU(Time-of-check Time-of-use)レースコンディション。CVSS v3.x 7.8(High)。
・影響対象: VMware Fusion 25H2(macOS)。Fusionをインストールした全Macユーザーが対象。
・修正版: VMware Fusion 26H1。
・攻撃要件: ローカル・非管理者の通常ユーザー権限のみ。
・影響: root権限取得。任意コード実行・永続化・機密ファイル改ざんが可能。
・ワークアラウンド: なし（パッチ適用のみ）。

TOCTOUは「権限チェックの瞬間」と「権限を使った操作の瞬間」の間のわずかな時間差を悪用するレースコンディションです。SETUIDバイナリは実行時に一時的にroot権限を持つため、チェック後・操作前の隙にシンボリックリンクなどでターゲットファイルを差し替えるとroot権限で任意のファイルを書き換えられます。報告者はMathieu Farrell氏(@coiffeur0x90)で、責任ある開示プロセスを経てBroadcomへ報告されました。

ローカル攻撃要件のためリモート侵害には直接つながりませんが、フィッシングやサプライチェーン経由で通常ユーザー権限を取得した攻撃者が、Mac端末でFusionをインストール済みであれば即座にrootへ昇格できる点が脅威の本質です。クラウド移行検証用にFusion VMを動かすMacは「開発機＋特権昇格踏み台」になり得ます。

クラウド移行検証ラボでFusionを使っている現場の緊急対応

クラウド移行案件では、本番環境を触る前にローカルMacでvSphereのネスト構成やRHEL／Ubuntu／Amazon Linux 2023を動かして検証するパターンが定番です。ターミナルから`vmware -v`で「VMware Fusion 13.x」または「VMware Fusion 14.x（25H2）」を確認したら、まず以下の3ステップを24時間以内に実施します。

第1にFusionのバージョン特定です。MacのFinderから「アプリケーション→VMware Fusion→VMware Fusionについて」を選択し、ビルド番号まで控えます。25H2は2025年第2四半期リリースのメジャー版で、修正版26H1は2026年第1四半期のメジャー版です。25H2系統のすべてのマイナーアップデートが影響対象のため、25H2.x.xは漏れなく対象と判断します。

第2に修正版26H1への即時アップグレードです。Broadcomのダウンロードポータル(support.broadcom.com)からFusion 26H1のdmgを取得し、稼働中VMをサスペンドしてからアプリケーションを差し替えます。Fusionは個人利用無償化されているためライセンス再認証は基本不要ですが、商用ライセンスの場合はBroadcom Software Account経由で更新を確認します。

第3にメンテナンス窓が即時取れない場合の暫定緩和です。本CVEはローカル非管理者攻撃のため、対策効果は限定的ですが「VMware Fusion未使用時のアプリ起動禁止」「不審なローカルプロセス検知のためのosqueryまたはmacOS統合ログ監視導入」が現実的です。ただし「ワークアラウンドなし」とBroadcomが明示しているとおり、根本対策はパッチ適用しかありません。

検証ラボとはいえrootシェル取得は致命傷です。本番環境のIAMキー・SSH秘密鍵・kubeconfigが同一Mac上にあれば、それらがすべて漏洩リスク下に置かれます。インフラエンジニアのローカル端末は実質「本番アクセス権の集約点」のため、優先度は本番サーバーへのパッチと同等以上で扱う必要があります。

vSphereとの関係整理とクラウド移行潮目としての位置づけ

ここで一度、VMware Fusionとクラウド側仮想化の位置関係を整理します。多くの現場で「VMwareと言えばvSphere」というイメージがありますが、Fusionはまったく別系列の製品です。

VMware Fusionはmacポータブル向けType-2ハイパーバイザー（ホストOS上で動作）、対するVMware ESXi/vSphereはサーバー向けType-1ハイパーバイザー（ベアメタル直接動作）です。両者はコードベース・運用形態・ライセンス体系がすべて異なります。今回のCVE-2026-41702はFusionのSETUIDバイナリ固有のもので、ESXi／vSphere／Workstation Proには波及しません。逆に過去のESXi系CVE（例:VMSA-2025-XXXX系のvCenter／ESXi脆弱性）はFusionと無関係です。

そのうえで、クラウド移行検討層にとって本CVEが意味するのは次の点です。
・Macローカル仮想化は「個人検証ラボ」止まりにすべきで、本番に近い検証はクラウド側の正規環境で実施する流れが加速。
・Broadcom買収後のVMware製品全体の価格改定により、vSphere本番資産のクラウド移行（VMware Cloud on AWS／Azure VMware Solution／Google Cloud VMware Engine）検討は2026年通年で活発。
・「ローカルMacでVM動かす」運用は権限昇格リスクを開発者個人が抱え込む形になり、組織のセキュリティガバナンス上は集中管理のクラウドVDI／DaaSへ移行する方向が望ましい。

つまり今回のCVEは「Fusionを26H1へ上げて終わり」ではなく、「そもそもMacローカル仮想化を業務クリティカルなルートに置く設計をやめる」契機として活用できます。20年以上現場を見てきた経験から言えば、「個人端末の特権管理が組織横断で破綻している現場」が圧倒的に多いため、組織として中央集約方針へ舵を切る材料に本CVEを使うのは現実的な戦略です。Linuxサーバー側のローカル権限昇格対策の考え方は姉妹サイトLinuxMaster.JPで別途解説しています。

代替クラウドVDI／DaaSサービスの比較（コスト試算と選定基準）

ローカル仮想化の代替として現実的なクラウドサービスは大きく4種類です。それぞれの位置づけとコスト感をまとめます。

選定基準は「ネスト仮想化が必要か」「常時稼働か業務時間のみか」「macOSゲスト利用が要件か」の3点です。

ネスト仮想化が必要な場合（クラウド側VM上でさらにKVM／ESXiを動かしたいケース）は、AWS EC2 c5n.metal／i3.metalなどのベアメタルインスタンスを直接借りる方が確実です。WorkSpacesやAzure VDのデスクトップ系サービスはネスト仮想化非対応が原則のため、Fusionで動かしていた「VM内で別VM」用途は代替できません。

業務時間のみ利用なら、AWS WorkSpacesの「AutoStop」課金（時間課金：Standard 0.41USD/時＋月額固定6USD）が最安です。1日8時間×20営業日=160時間なら月額約72USDで、常時稼働Power Bundleの44USDより高くなるためAutoStopは「週数回利用」「複数人で席数より少ない常時利用人数」のケースで真価を発揮します。

macOSゲスト要件がある場合（iOSアプリ開発用Xcode検証など）は、AWS EC2 Mac1／Mac2インスタンス（Apple Silicon搭載）の専用ホスト一択です。月額1,000USD超と高額ですが、ライセンス上Macハードウェア以外でmacOSを動かす選択肢はなく、Fusionのネスト構成も同様にApple Silicon Macのみで合法的に運用できます。

書籍で体系的に学ぶなら、クラウドインフラ全体の仕組みを掴むのに『絵で見てわかるクラウドインフラとAPIの仕組み』(翔泳社)（PR）が定評があります。クラウドサービス選定の判断軸を持つうえで一冊手元に置いて損はありません。

IaC（Terraform）でFusion依存テスト環境をクラウド化する設計

Fusionからクラウド側VDIへ移行する際、最も再現性高く設計できるのがTerraformによるIaC化です。「個人Macに散在するVM」を「Terraformコードで誰でも同じ環境を構築」できる形に集約します。

最小構成として、開発者一人ひとりに専用のWorkSpacesディレクトリを払い出し、AWS Simple ADまたはAWS Managed Microsoft ADと連携してログイン管理する形が定番です。Terraformコード例の骨子は次のとおりです。

# AWS WorkSpaces (Standard Bundle, AutoStop) サンプル
resource "aws_workspaces_directory" "lab" {
  directory_id = aws_directory_service_directory.lab.id
  subnet_ids   = [aws_subnet.lab_a.id, aws_subnet.lab_c.id]
}

resource "aws_workspaces_workspace" "engineer01" {
  directory_id = aws_workspaces_directory.lab.id
  bundle_id    = "wsb-bh8rsxt14"  # Standard with Amazon Linux 2
  user_name    = "engineer01"

  workspace_properties {
    running_mode                              = "AUTO_STOP"
    running_mode_auto_stop_timeout_in_minutes = 60
    root_volume_size_gib                      = 80
    user_volume_size_gib                      = 50
  }
}

このコードでバンドル指定、AutoStop時間、ボリュームサイズをすべてコード管理できます。Fusionの場合は各エンジニアが個別にゲストOSを構築・パッチ・スナップショット管理していましたが、Terraform管理ならStateで全員の環境を一元把握でき、棚卸し・コスト集計・退職時クリーンアップも自動化できます。

Azure側はAzure Virtual Desktopのホストプール・セッションホストをTerraformで構築します。`azurerm_virtual_desktop_host_pool`／`azurerm_virtual_desktop_application_group`を中心に、FSLogixプロファイルをAzure Filesに格納する構成が標準です。

IaC設計時の落とし穴として「セッションホストOSのパッチ管理をTerraformに含めない」という分離原則があります。Terraformはインフラ作成までを担当し、OSパッチ管理はAWS Systems Manager Patch ManagerまたはAzure Update Managerに委ねる形が現場標準です。Fusion VMでrootシェル取得脆弱性が出てから「個別パッチを当てる手間」を考えれば、中央集約パッチ管理に移行する経済合理性は明確です。

Terraform実務の体系的なベストプラクティスは『Terraform実践ガイド 第2版』（PR）が定番です。State管理・モジュール設計・CI/CD統合まで一冊で網羅されているので、クラウドVDI移行プロジェクトの設計フェーズで参考になります。

よくある質問（FAQ）

Q1. 26H1へアップグレードしたら稼働中のWindows／Linux VMはそのまま使えますか？
A. 基本的にVMファイル(.vmx／.vmdk)は互換性があり、サスペンド→Fusion本体差し替え→再開で使えます。ただし仮想ハードウェアバージョンを最新に上げると古いFusionには戻せなくなるため、25H2へのロールバック可能性を残したい場合はハードウェアバージョン更新を見送ります。

Q2. Apple Silicon Mac（M1～M4）と Intel Macで対応に差はありますか？
A. CVE-2026-41702はSETUIDバイナリのTOCTOUのためアーキテクチャに依存せず、両環境とも影響対象です。Apple Silicon版はARM64ゲストOSのみ動作、Intel版はx86_64ゲストOSが動作するという従来からの違いは継続します。

Q3. VMware Workstation Pro（Windows／Linux版）も影響を受けますか？
A. Broadcom VMSA-2026-0003ではFusionのみが影響対象と明示されています。Workstation ProはCVE-2026-41702の対象外ですが、過去個別にWorkstation Proの脆弱性が出ているため、別途VMSAを参照してください。

Q4. クラウド側VDIに移行すると、ネスト仮想化（VM内でさらにVMを動かす）はできなくなりますか？
A. AWS WorkSpaces／Azure VD／Microsoft Dev Boxは原則ネスト非対応です。ネストが必要なら、AWS EC2のベアメタルインスタンス（c5n.metal／i3.metal等）か、Azureの一部Dv3／Ev3シリーズ（Nested Virtualization対応）を選択します。

Q5. AWS WorkSpacesの料金は本当に上記試算のとおりですか？
A. 2026年5月時点の東京リージョン公式料金表の参考値です。最新はAWS WorkSpaces公式を確認してください。為替・リージョン・利用形態（AlwaysOn／AutoStop）で変動します。

Q6. Fusionの個人利用無償化は本CVE対応にも適用されますか？
A. はい。Fusion Player／Fusion Proともに個人利用は無償化されており、26H1のダウンロードも無償アカウントで可能です。商用利用ライセンスは継続して有償ですが、CVE対応のためのアップグレード自体に追加費用は発生しません。

Q7. Mac端末側のEDRやエンドポイントセキュリティ視点ではどう守るのが現実的ですか？
A. macOS統合ログ・osquery・MDM経由のアプリ制御で「Fusion未パッチ端末の検知と隔離」が現実的です。FortiGuard／CrowdStrike等のEDR運用については姉妹サイトSecurityMasters.TOKYO側で扱っています。

Q8. クラウド移行後、Macで残すべきツールは何ですか？
A. ブラウザ、SSH／RDPクライアント、VS Code、TerminalだけあればクラウドVDIへ接続できます。Docker DesktopはLinux on EC2のRemote Containers接続に置き換える設計が増えています。

本記事のまとめとクラウド移行チェックリスト

VMware Fusion 25H2のCVE-2026-41702はSETUID TOCTOUによるローカルroot権限昇格脆弱性で、CVSS 7.8、修正版26H1で対処済み、ワークアラウンドなし。検証ラボ用途とはいえローカルMacで動かしている全環境で即時アップグレードが必須です。同時に、Macローカル仮想化を業務クリティカルなルートに置く設計から、AWS WorkSpaces／Azure Virtual Desktop／Microsoft Dev Boxへの集中管理型への移行検討が「権限管理の経済合理性」観点で進めやすい潮目です。

クラウド移行検討時のチェックリストを以下に整理します。
・Fusionバージョン棚卸し: 組織内のMac全台でVMware Fusion 25H2.x.xを検出、26H1へ即時アップグレード
・稼働VMの台帳化: 各Macで動いているVMの用途・ゲストOS・依存サービスを棚卸し
・クラウド代替サービス選定: ネスト仮想化要件・稼働パターン・OSライセンス要件で4サービスから選定
・Terraform IaC化: 選定したクラウドVDIをTerraformでコード化し、開発者ごとの環境作成を自動化
・パッチ管理の中央集約: AWS Systems Manager Patch ManagerまたはAzure Update Managerでセッションホストの脆弱性管理を集中化

クラウド移行検討時のセキュリティ全体像は『AWSではじめるクラウドセキュリティ』(翔泳社)（PR）にIAM／VPC／鍵管理／パッチ管理まで体系的にまとまっています。Fusionローカル運用からクラウドVDIへの移行プロジェクトの設計レビューで一読の価値があります。

クラウド側に運用責任を寄せる設計は、本CVEのようなローカル端末固有の脆弱性リスクを組織から切り離す副次効果があります。「特権昇格は組織で守る、個人端末で抱えない」がクラウド時代のセキュリティ設計の現実解です。