CVE-2026-41709 VMware ESX｜ログ回避の影響と対策

はじめに

2026 年 10 月 28 日、CISA は VMware ESX のログ記録不備である CVE-2026-41709 を KEV（Known Exploited Vulnerabilities）カタログに追加しました。同日、CrowdStrike は中国に関連する攻撃グループ WARP PANDA が、この脆弱性をゼロデイとして悪用していたと報告しています。

CVE-2026-41709 の CVSS 3.1 は 2.7（Low）で、2026 年 7 月に公開された VMSA-2026-0006 では、同時に修正された Critical の脆弱性と比べて優先度を低く判断されやすい項目でした。しかし、仮想基盤の管理者権限を得た攻撃者が操作の痕跡を減らす手段として使われていたことが報告され、対応の優先度と、過去の操作をどう調査するかを改めて検討する必要があります。

結論として、CVE-2026-41709 の修正版は ESXi 8.0 系が ESXi80U3j-25429389、ESX 9.0 系が ESXi-9.0.2.0100-25595025、ESX 9.1 系が ESXi-9.1.0.0-25370933、VMware Cloud Foundation 5.x が 5.2.4 です。ESXi 8.0 Update 2 向けの更新（8.0 U2f）は本 CVE を修正しないため、Update 3 系への更新が必要です。修正版の適用で防げるのは今後の記録漏れであり、過去に記録されなかった操作は残らないため、ログ以外の記録と突き合わせた調査を推奨します。

CVE-2026-41709 とは何か｜CVSS 2.7 でも優先度が上がる理由

CVE-2026-41709 は、ESX の管理者権限を持つ人物が一部の操作をログに残さず実行できる脆弱性です。侵入の手段ではなく、侵入後の痕跡を減らす手段になり得る点が、CVSS の数値と実際のリスクの差を生んでいます。

管理者権限が前提のログ記録不備

Broadcom の VMSA-2026-0006 によると、VMware ESX にはログ記録が不十分な脆弱性（CWE-778）があり、悪意のある管理者が特定の操作をログに記録させずに実行できます。公式の回避策（Workaround）はなく、修正版の適用が対策です。

参考: Broadcom VMSA-2026-0006
“perform certain operations without them being logged”
（特定の操作を、ログに記録されることなく実行できる）
https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017

どの操作が記録されないのかは、VMSA と公式 FAQ では公開されていません。CrowdStrike はこの脆弱性を「ESXi のコマンドログ記録の回避」と表現していますが、対象となる操作の範囲は公式には示されていないため、ESX のログが一切残らなくなる問題とは区別して扱う必要があります。

初期侵入に使われる脆弱性との違い

同じ VMSA には、ネットワーク経由で認証を回避できる vCenter の脆弱性（CVE-2026-59309、CVSS 9.8）も含まれています。VMSA 全体の最高スコア 9.8 はこの vCenter の CVE の評価であり、CVE-2026-41709 の評価ではありません。両者は攻撃の段階が異なります。

CVE-2026-41709 単体で、認証の回避やリモートからのコード実行が成立するものではありません。攻撃者は何らかの方法で ESX の管理者権限を得ていることが前提です。

CVSS 2.7 と実際の対応優先度

VMSA が示す CVSS ベクターは AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N です。高い権限が必要で、影響は完全性（Integrity）の「低」のみと評価されているため、スコアは 2.7 にとどまります。

CVSS の基本値は脆弱性単体の技術的な深刻度を示す指標であり、侵入後の攻撃の流れの中での利用価値や、実際の悪用状況は反映されません。ESX の管理者権限を持つ攻撃者は多数の仮想マシンを操作できる立場にあり、その操作の記録が欠けると、侵害の範囲を確定する調査が難しくなります。MY TECH BLOG では、CVSS の数値だけでなく、KEV 登録による実悪用の事実と、仮想基盤の調査可能性への影響を優先度の判断に加えることを推奨します。

WARP PANDA による悪用と CISA KEV 登録

本 CVE は 2026 年 7 月に修正が公開され、10 月に実際の悪用が報告されました。修正版の公開時点と悪用報告の時点で、得られている情報が異なる点に注意が必要です。

CrowdStrike の報告内容

CrowdStrike は、2026 年 10 月 28 日に公開した「CrowdStrike 2026 Legal Threat Landscape Report」の紹介記事で、WARP PANDA が法律関連組織を含む米国の複数組織に侵入し、被害組織の VMware vCenter 環境に複数種類のマルウェアを展開したと報告しています。そのうち複数の事例で、2026 年初めの時点まで CVE-2026-41709 をゼロデイとして悪用していたとしています。

参考: CrowdStrike 2026 Legal Threat Landscape Report
“exploited ESXi command logging bypass vulnerability CVE-2026-41709 as a zero-day”
（ESXi のコマンドログ記録回避の脆弱性 CVE-2026-41709 をゼロデイとして悪用した）
https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-legal-threat-landscape-report/

攻撃者の帰属、標的、活動内容は、いずれも CrowdStrike の報告に基づくものです。初期侵入の方法や、具体的にどの操作を記録から外したかは、確認できる公開情報には記載されていません。なお、VMSA の謝辞では、CrowdStrike の Ian Barton 氏が本件の報告者とされています。

修正公開から実悪用報告までの時系列

VMSA が 9.1 系と 8.0 系の修正版として示す ESX 9.1.0.0 と ESXi 8.0 Update 3j は、VMSA の公開より前にリリースされたビルドです。また、8.0 Update 3j のリリースノートには CVE 番号が記載されていません。リリースノートの CVE 欄だけで判断すると修正の有無を見落とすため、VMSA の Response Matrix を基準に確認してください。

一方、VMSA-2026-0006.2 を反映した公式 FAQ は、実際の悪用を示す情報はないとしています。これは 10 月の CrowdStrike と CISA の発表より前の時点の情報であり、現在の悪用状況とは区別して扱う必要があります。

KEV の対応期限の適用範囲

CISA は、実際の悪用の証拠に基づいて CVE-2026-41709 を KEV に追加しました。KEV の対応期限である 2026 年 11 月 11 日は、米国連邦政府機関に対する運用指令に基づく期限です。日本国内の企業に法的な対応義務を課すものではありません。

参考: CISA Alert（2026 年 10 月 28 日）
“based on evidence of active exploitation”
（実際の悪用の証拠に基づく）
https://www.cisa.gov/news-events/alerts/2026/10/28/cisa-adds-two-known-exploited-vulnerabilities-catalog

日本の企業では、KEV の期限を直接の義務として扱うのではなく、「実悪用が確認された脆弱性」として社内の緊急変更の基準に照らして対応時期を判断することをおすすめします。

影響を受ける VMware ESXi / ESX のバージョンと修正版

VMSA-2026-0006.2 の Response Matrix が示す CVE-2026-41709 の修正版は次のとおりです。公式 FAQ によるとパッチは累積型のため、表のビルドより新しいリリースにも修正が含まれます。

VMSA 全体を考慮した更新先の選び方

同じ VMSA に含まれる ESX 向けの CVE-2026-47876（CVSS 9.3）と CVE-2026-41703（CVSS 7.6）は、CVE-2026-41709 と修正版が異なります。たとえば 8.0 系を U3j、9.1 系を 9.1.0.0 に更新しただけでは、CVE-2026-41709 は修正されても CVE-2026-47876 が未修正のまま残ります。

実運用では、8.0 系は ESXi 8.0 Update 3k 以降、9.1 系は 9.1.0.0200 以降、9.0 系は 9.0.2.0100 以降を更新先とし、VMSA の ESX 向け CVE をまとめて解消することを推奨します。vCenter の CVE は ESX とは別に、vCenter の修正版で対応します。

ESXi 8.0 Update 2 / ESXi 7.0 / VCF 5.x の注意点

ESXi 8.0 Update 2

VMSA-2026-0006.1 で追加された ESXi80U2f-25626445 は、この VMSA の Critical の CVE だけを修正する更新です。CVE-2026-41709 の Response Matrix には 8.0 Update 2 系の修正版がないため、本 CVE に対応するには Update 3j 以降への更新が必要です。

ESXi 8.0 Update 3 のセキュリティ専用イメージ

VMSA が修正版として示すのは ESXi80U3j-25429389 です。同時に提供されたセキュリティ専用イメージ（ESXi80U3sj-25410958）は、本 CVE の修正有無を公式資料で確認できませんでした。

ESXi 7.0 以前

vSphere 7 は 2025 年 10 月 2 日に一般サポートを終了しています。VMSA-2026-0006.2 で追加された 7.0 向けの案内は Critical の CVE が対象で、CVE-2026-41709 の Response Matrix に 7.0 の行はありません。公式 FAQ は、VMSA に記載のない旧バージョンは影響を受けると想定するよう求め、VCF 9.1 への移行を推奨しています。延長サポート契約がある場合は、その契約のプロセスで本 CVE の扱いを確認してください。

VMware Cloud Foundation 5.x

修正版は VCF 5.2.4 です。VMSA では、ESX コンポーネントの非同期パッチ適用手順として KB 88287 が参照先に示されています。

サードパーティの統合システム

Dell VxRail や HPE SimpliVity などの統合システムでは、公式 FAQ がベンダーのパッチ提供と手順に従うよう案内しています。VMSA のビルドを直接適用せず、各ベンダーの情報を確認してください。

参考: Broadcom VMSA-2026-0006 Questions & Answers
“only resolve the critical CVEs in this advisory”
（8.0 Update 2 向けの更新は、このアドバイザリの Critical の CVE のみを解決する）
https://github.com/vmware/vcf-security-and-compliance-guidelines/blob/main/security-advisories/vmsa-2026-0006/README.md

VMware ESXi のビルド番号を確認する方法

影響の判断は、製品系列・バージョン・ビルド番号を組み合わせて行います。同じバージョン系列でも、適用済みのパッチによって修正状況が異なるためです。たとえば ESXi 8.0 Update 3j と Update 3k はいずれも 8.0.3 系で、ビルド番号（25429389 と 25595708）で区別します。ビルド番号とリリースの対応は Broadcom KB 316595 で確認できます。

vSphere Client: インベントリでホストを選択し、サマリー タブ（ホスト名の行）に表示されるビルド番号を確認します。手順は公式 FAQ と Broadcom KB 345263 に記載されています。

ESXi Shell: ESXCLI リファレンスでは、esxcli system version get は製品名、バージョン、ビルド情報を表示するコマンドとされています。

esxcli system version get

ビルド番号と適用済みのアップデートは、次のコマンドでも確認できます（Broadcom KB 320235）

vmware -vl

PowerCLI: 複数のホストを管理している場合は、Connect-VIServer で vCenter に接続したうえで、公式 FAQ に記載のコマンドで全ホストのバージョンとビルドを一覧化できます。

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

一覧を取得したら、Version 列でホストの系列（8.0.3、9.0.2、9.1.0 など）を分け、系列ごとに前述の表の修正済みビルドと照合します。ビルド番号は系列をまたいで大小を比較できません。たとえば 9.0 系の修正版（25595025）は、9.1 系の修正版（25370933）より大きな番号です。ビルド番号順の並べ替えだけで修正状況を判断しないでください。

複数の vCenter で管理している環境、vCenter に登録していないスタンドアロンのホスト、切断状態のホストは、一覧から漏れることがあります。資産管理台帳と突き合わせ、すべての ESX ホストを確認対象に含めてください。

ログ調査の限界と複数の記録を使った確認

CVE-2026-41709 は、ログそのものの信頼性に関わる脆弱性です。未修正の期間に不正な操作がなかったかを確認する際は、単一のログに依存しない調査が必要です。

ログに痕跡がないことは安全の証明にならない

本 CVE は、管理者が特定の操作をログに残さず実行できる問題です。ESX ホストのログに不審な操作が見つからないことだけを根拠に、未修正期間に不正操作がなかったと判断することはできません。

修正版の適用で防げるのは、適用後の記録漏れです。適用前に記録されなかった操作が、更新によって後から記録されるわけではありません。また、CrowdStrike は WARP PANDA が vCenter 環境にマルウェアを展開したと報告しているため、侵害が疑われる環境では、vCenter 側の記録も改ざんや欠落の可能性を前提に扱うことを推奨します。

突き合わせる記録と確認の観点

CVE-2026-41709 で記録されなかった操作が、別の記録に必ず残っているとは限りません。それでも、記録源を増やすことで、欠落している時間帯や説明のつかない変化を見つけやすくなります。

ESX ホストの auth.log と shell.log

Broadcom KB 306962 によると、auth.log は ESXi Shell の認証の成否、shell.log は ESXi Shell の有効化・無効化と入力されたコマンドを記録します。KB 321910 では、両ログのプロセス ID（World ID）を照合して、誰がどのコマンドを実行したかを特定する方法が説明されています。CrowdStrike が「コマンドログ記録の回避」と表現している点から、shell.log の記録だけに依存しないことを推奨します。

ESX ホストの hostd.log

ホストと仮想マシンを管理・構成するエージェント（hostd）の情報が記録されます。Shell 以外の経路による管理操作を確認する際の記録源になります。

vCenter のタスクとイベント

vCenter 経由で行われた仮想マシンの作成、構成変更、権限変更などを、ESX ホストのログとは別の記録源として照合します。ただし、ESX ホストへ直接行われた操作や、本 CVE で記録されなかった操作が vCenter 側に残っているとは限りません。

外部の Syslog サーバー・SIEM

転送済みのログは、ホスト上のログを削除・改ざんされても独立して残ります。一方で、ホスト側で生成されなかったログは転送されないため、本 CVE による記録漏れを補うものではありません。

認証基盤・踏み台・ネットワークの記録

ID 基盤の認証履歴、踏み台サーバーの操作記録、管理ネットワークのファイアウォールやフローの記録は、ESX の外側にある記録です。管理者アカウントの利用が、作業申請や業務時間と一致しているかを確認します。

ホストと仮想マシンの現在の構成

ログではなく、現在の状態を変更管理の記録と比較します。ESXCLI リファレンスに記載された esxcli system account list（ローカルアカウント）、esxcli system permission list（権限）、esxcli system ssh key list（SSH の認証鍵）で、意図しないアカウントや権限、鍵が追加されていないかを確認します。あわせて、仮想マシンの一覧と構成も、把握している状態と一致するかを確認します。

これらの記録は、同じ時間軸に並べて照合すると効果的です。認証の記録があるのに操作の記録がない区間や、構成が変化しているのに対応するタスクが見つからない箇所は、追加調査の対象になります。照合の前提として、各機器の時刻が NTP で同期していたかも確認してください。

2026 年 10 月 29 日時点で、本 CVE の悪用を検知する方法や IoC は、確認できた公開情報では示されていません。今後の公式情報を確認し、侵害の兆候がある場合は、インシデント対応の専門チームへの相談を検討してください。

外部 Syslog と監査レコードは多層防御として設定する

ログをホストの外部へ転送しておくと、ホスト上のログが消去されても記録を保持できます。ESXCLI リファレンスでは、esxcli system syslog config set --loghost で転送先を設定し、esxcli system syslog reload で設定を反映します。現在の設定は次のコマンドで確認できます。

esxcli system syslog config get

監査レコード（Audit Record）をリモートの Syslog ホストへ送る場合は、esxcli system auditrecords remote enable を使用します。転送の設定手順とファイアウォールの設定は Broadcom KB 318939 を参照してください。

外部転送やログ保存期間の延長は、記録を守る多層防御として有益ですが、CVE-2026-41709 の根本的な修正ではありません。修正版の適用と組み合わせて実施してください。

更新時の注意点と適用手順

ESX の更新は、原則としてホストの再起動を伴います。公式 FAQ は、vMotion で仮想マシンを他のホストへ移動しながら順番に再起動する方法を推奨しており、vMotion できない仮想マシンは再起動中に停止が必要です。以下は一般的な流れであり、具体的な操作は製品・バージョンごとの公式ドキュメントで確認してください。

esxcli system syslog mark --message "Syslog Test Message"

Live Patch の利用条件と制限

公式 FAQ によると、この VMSA の ESX 向け更新の一部は、環境が対応していれば ESX Live Patch で適用できます。Live Patch を利用するには、同じメジャーバージョンの直前の更新（N-1）を実行している必要があり、それより古いホストは通常の更新方法で追いつく必要があります。Live Patch は ESX 8.0 Update 3 で導入され、TPM を使用するホストは VCF 9.1 から対象になりました。

ESX 9.0.2.0100 のリリースノートでは、このリリースは Live Patch の対象とされています。ただし、再起動せずに適用できるのは、更新元が N-1 の条件を満たし、ホスト構成が Live Patch に対応しているなど、利用条件を満たす場合に限られます。条件を満たさない 9.0 系ホストは、通常の更新と再起動が必要です。その他のビルドの対応可否は、各リリースノートで確認してください。vSAN ストレッチクラスターでは、Live Patch を無効にして監視ホスト（Witness）を更新し、その後に再度有効にする手順が FAQ から案内されています。なお、vCenter の Quick Patch は今回の vCenter 向け更新では利用できません。

back-in-time 制限と VCF 9.x への移行計画

公式 FAQ によると、今回の VMSA に含まれる一部の更新（vSphere 8.0 と 9.0 向け。VCF 5.x の非同期パッチを含む）を適用すると、VMware Cloud Foundation 9.x へのアップグレード時に「back-in-time」制限が発生する場合があります。更新後のビルドが移行先より新しくなるためで、互換性は今後のリリースで回復するとされています。

VCF 9.x への移行を計画している環境では、更新の適用と移行の日程を比較したうえで、更新元と移行先の組み合わせを VMware Product Interoperability Matrix で確認してください。制限の詳細は Broadcom KB 67077 で案内されています。

まとめ

CVE-2026-41709 は CVSS 2.7 の Low 評価ですが、管理者権限を得た攻撃者の痕跡を減らす手段としてゼロデイで悪用されていました。対応では、ビルド番号に基づく修正版の確認と、ログだけに依存しない過去の調査を組み合わせることが重要です。

• 管理者が一部の操作をログに残さず実行できる ESX の脆弱性
• 単体で初期侵入やリモートコード実行が成立するものではありません。
• CrowdStrike は WARP PANDA によるゼロデイ悪用を報告しています。
• 8.0 系の修正版は U3j で、U2f では修正されません。
• 同じ VMSA の他の CVE も考慮し、8.0 U3k 以降への更新を推奨します。
• ログに痕跡がないことは、不正操作がなかった証明になりません。
• 更新後もビルド、Syslog 転送、管理アクセスの状態を確認します。

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