VMware ESXのログ記録不備がKEV入り｜管理者権限の悪用と修正先を確認

CISAは2026年10月28日、VMware ESXのログ記録不備CVE-2026-41709を悪用確認済み脆弱性カタログ（KEV）へ追加しました。管理権限を持つ攻撃者が一部操作をログへ記録させずに実行できる問題です。インターネットから認証なしで侵入できる脆弱性ではありませんが、侵害後の調査に必要な記録へ影響するため、仮想基盤の管理者は修正適用状況を確認してください。

修正版は7月29日のBroadcom勧告ですでに案内されています。今回の新情報は修正版の新規公開ではなく、悪用確認を受けた優先順位の変化です。WebサーバーのゲストOSだけを更新してもESXホストの修正にはなりません。ホスティングや仮想基盤を委託している場合も、基盤担当へ対象ホストとビルド番号の確認を依頼する必要があります。

低いCVSSでも監査への影響を別に評価する

BroadcomのVMSA-2026-0006の3e節は、この問題をLow、CVSS v3の基本値2.7と評価しています。成立には悪意ある管理者が必要で、一部操作が記録されないことが影響です。同じ勧告には別の重大脆弱性も含まれますが、その最高値9.8をCVE-2026-41709の評価として使ってはいけません。

管理権限が必要であることは、ログの欠落を無視してよい理由にはなりません。正規の管理者による内部不正だけでなく、管理者アカウントを奪われた場合にも監査の前提が変わります。ただし、今回のKEVレコードから、特定の企業が管理者アカウントを奪われた、あるいは全操作のログが消えるとまでは判断できません。

Webサービスの運用担当者に関係するのは、ゲストの外側で何が行われたかを確認しにくくなる点です。ゲストOSのログが正常でも、仮想基盤側の操作まで無かったとは説明できません。反対に、ログの一部が欠けていることだけで本CVEの悪用を断定することもできません。ログ転送の停止、保存期間、権限、時刻のずれなどを分けて調査します。

KEV登録日と初回公表日を区別する

CISA公式JSONの確認版はcatalogVersionが2026.10.28、dateReleasedが2026年10月28日19:00:04 UTCです。対象レコードのdateAddedは10月28日、対応期限は11月11日です。提供元の指示に従った対策を求めています。期限は米国の制度上の対象組織に関係する指定で、日本のすべての利用者に同じ法的期限が課されるという意味ではありません。

ランサムウェア利用状況はUnknown、forensicTriageはNoです。Unknownは利用なしの証明ではなく、Noも自社で侵害調査が不要という安全判定ではありません。KEV掲載は悪用確認の根拠になりますが、攻撃件数や被害組織、実際に記録されなかった操作の詳細までは示していません。

Broadcomの勧告は初回公表日を7月29日、更新日を8月19日と表示しています。修正を当時適用済みの環境で、10月のKEV登録を理由に同じパッチを機械的に入れ直す必要はありません。記録した適用ビルドと現在の稼働ビルドを照合し、対象クラスタの一部や交換ホストが未対応でないかを再確認します。

自社の製品行から修正先を選ぶ

勧告の3e節の対応表では、Cloud FoundationまたはvSphere FoundationのESX 9.1系列にESXi-9.1.0.0-25370933、9.0系列にESXi-9.0.2.0100-25595025を示しています。VMware ESX 8.0の行はESXi80U3j-25429389です。Cloud Foundation 5.xは5.2.4、Telco系は製品別KBを参照する構成です。

これらは確認した対応表の修正先です。製品名が似ていても、vCenterの修正版や同じ勧告の別CVEの修正先を代用しないでください。例えば同じESX 8.0でも、ほかのCVEの行には異なる修正版が記載されています。最新の累積更新を採用する場合も、利用系列と本CVEの修正を含むことを提供元の対応情報で確かめます。

作業票には製品構成、ホスト名、クラスタ、現在の版とビルド、採用する更新、根拠となる対応表の行を記載することを提案します。Cloud Foundationのように製品全体の更新管理がある場合、ESXの番号だけを見て独立にパッチを当てるのではなく、その製品のライフサイクル管理と互換性条件に従ってください。

公式の本CVEの欄に回避策はありません。管理ネットワークの制限や管理者権限の棚卸しは露出低減には役立ちますが、記録不備を修正する代替にはなりません。管理画面を外部公開していないことだけで修正不要とも判断できません。管理権限を誰がどの経路で使えるかと、ホストが修正済みかを別々に確認します。

更新前にログの欠落と収集障害を切り分ける

ここからは本サイトの運用提案です。公式が示していない悪用検出コマンドやIOCを作るのではなく、現在保有する記録の範囲を明らかにします。まずホスト側、管理サーバー側、認証基盤側、外部ログ収集先について、取得できる期間、停止していた時間、時刻の基準、保存責任者を整理してください。

ログ収集先にイベントがない場合は、元のホストにもないのか、ホストにはあるが転送されていないのかを分けます。容量不足、転送先の到達性、検索条件、タイムゾーンの違いでも見え方が変わります。これらの確認で収集障害を見つけても、本CVEの影響を自動的に否定できるわけではありません。修正前期間の不確実性として残します。

次に、承認済み変更の記録と管理者の認証履歴を照合します。誰のアカウントか、接続時刻、作業申請、実際の構成差分を対応させます。管理者のログインが成功していることと、本人が承認された作業をしたことは同じではありません。共有アカウントなら、実作業者を特定できる補助記録があるかも確認します。

ログを補う資料には、構成管理の履歴、変更申請、バックアップシステムの実行記録、監視の状態変化などが考えられます。それぞれ取得元が異なるため、同じ操作が常に残ると仮定せず、何を確認できる資料かを明記します。今回の資料には具体的に欠落する操作の一覧がないので、特定イベントだけを探せば十分という検出手順は示しません。

修正適用と過去の侵害調査を二つの作業にする

更新計画では、仮想マシンの配置、停止できない業務、移動先の余力、バックアップ、管理系への接続経路を確認します。ホストを保守状態へ移す操作や再起動の要否は、採用する更新と製品構成の正式手順に従ってください。単にゲストを再起動しただけでは、ホスト側のソフトウェアを置き換えたことにはなりません。

適用後はホストごとに版とビルドを採取し、作業前の台帳と比較します。「クラスタ更新済み」という一行では、一台だけ保守から戻らなかった場合や、別のホストへ移動した場合の漏れを見落とします。分母となる対象台数、完了台数、例外と理由を残し、交換機や災害復旧側も対象に含めるかを決めます。

過去に管理者アクセスの悪用が疑われるなら、パッチ適用とは別に封じ込めと調査を進めます。管理者アカウント、既存セッション、外部連携、追加された権限など、利用中の構成で失効が必要な経路を確認します。調査前にログや構成を一括削除したり、根拠なく全環境の再構築を始めたりせず、組織のインシデント対応担当と判断してください。

修正後にログが出るようになっても、修正前に記録されなかった操作が遡って復元されるとは限りません。更新完了の記録と、過去の調査で残る未確認範囲を同じ完了欄にまとめないことが大切です。問題がなかったと説明できる範囲と、記録不足で判断できない範囲を区別して引き継ぎます。

正常な管理操作で収集経路を確認する

検証は許可された検証環境で、影響が小さい通常の管理操作を一つ選び、実施者と時刻を記録して行うことを提案します。目的は本脆弱性の攻撃実証ではなく、運用で依存するログ収集経路が機能しているかの確認です。どの記録に残る想定なのかを、製品のログ仕様と自社の収集設定から先に決めます。

操作後はホスト側の記録と外部収集先の両方を見て、イベントの内容、転送の遅延、検索に必要な識別子を確認します。見えなければ、操作の種類、ログ設定、転送、保存、検索の順に切り分けます。検証の成功は選んだ操作と時点での収集を確認するもので、すべての操作が網羅されることや未侵害を保証するものではありません。

外部ログ収集も、発生元が記録しなかった情報を自動で生成する仕組みではありません。保存先をホストの外へ出すこと、保存済み記録の改変を抑えること、必要なイベントが発生元で生成されることは役割が異なります。今回の修正と、収集先の保持期間やアクセス権の点検を併せて進めてください。

委託先への確認はビルドと対象範囲で受け取る

仮想基盤を自分で管理しないWeb運営者は、ホスティング事業者へCVE番号、対象サービス、確認したいホスト範囲を伝えます。回答は「対策済み」だけでなく、対象版への該当有無、修正適用の完了時点、稼働ビルドを確認したか、例外が残るかを必要な範囲で受け取ることを提案します。管理者用の秘密情報を受け取る必要はありません。

本件の判断軸は、管理権限という成立条件、悪用確認という優先度、ログ欠落という調査上の限界の三つです。CVSSの低さだけで後回しにせず、公式対応表に沿って修正し、過去の記録の信頼範囲を整理してください。7月の修正を適用済みなら、その事実を全対象ホストの稼働情報で確認することが今回の最初の作業になります。

対応票を閉じる際は、修正済みホストの一覧と確認時刻を保存し、調査記録の保管先へアクセスできる担当者を定めます。保守担当の交代後も、どの期間のログが利用できるかを説明できる状態にしておくと、後日の注意喚起や問い合わせに対応しやすくなります。

関連記事

緊急パッチを安全に適用する実務ランブックでは、更新前の保全、段階反映、稼働実体の確認を扱っています。本記事の製品別対応表と併せて参照してください。