VMware vCenterのSyslogパストラバーサルCVE-2026-59310。修正公開から5日で始まった侵害と仮想基盤全体への波及

Broadcomが2026年7月29日に公開したVMware Security AdvisoryのVMSA-2026-0006には、vCenterに関する二つのCVSS 9.8の脆弱性が含まれていました。そのうちの一つ、SyslogサーバのディレクトリトラバーサルであるCVE-2026-59310は、修正の公開から5日後の8月3日に悪用が始まり、8月上旬のうちに47か国で侵害が観測されました。CISAは2026年8月18日にこの脆弱性をKnown Exploited Vulnerabilities(KEV)カタログへ追加しています。

ゼロデイではありませんでした。CVE-2026-59310は非公開で報告され、修正が先に公開された脆弱性です。それでも公表から5日後には悪用が観測され、更新を適用していない環境の侵害が短期間で広がりました。侵害された先はvCenterという、仮想基盤全体の管理権限が集まる場所です。

この記事は、vSphere環境を運用するインフラ担当とSOCの担当者に向けて、BroadcomのアドバイザリとCISAのKEVカタログ、JPCERT/CCの週次レポート、そしてインシデント対応にあたったQUIRSOの報告を紹介した各社の記事という情報源をもとに、事実関係と実務の対応を整理します。攻撃を再現する手順や動作するコードは扱いません。記述は執筆時点(2026年8月25日)に確認できた範囲に限ります。

vCenterを取られると何が起きるのか#

vCenter Serverは、複数のESXiホストと、その上で動く仮想マシン、データストア、仮想ネットワークをまとめて管理するための基盤です。vSphere環境の運用者は日々vCenterへログインし、仮想マシンの作成や移行、スナップショット、権限の割り当てを行います。裏を返すと、vCenterの管理権限は、その配下にある仮想マシン群すべてに手が届く権限とほぼ同じ意味を持ちます。

この位置づけが、vCenterの脆弱性を特別扱いすべき理由です。一台のWebサーバの脆弱性であれば、影響はそのサーバとそこに置かれたデータに限られます。vCenterの場合は、業務システム、ファイルサーバ、データベース、Active Directoryの各仮想マシンが同じ管理面の下にぶら下がっています。攻撃者から見れば、個別のゲストOSを一つずつ攻略するより、管理面を一度取るほうがはるかに効率が良いという構図になります。

さらに、vCenterは外部公開を意図した装置ではないにもかかわらず、実際にはインターネットから到達できる状態で運用されている例が少なくありません。リモート運用のために管理セグメントへVPNを張らずに直接公開したり、検証環境のvCenterを閉じ忘れたりといった形です。今回の事案で世界中の環境が短期間に踏まれた背景にも、この到達性があります。

管理インターフェースを境界の外に置かないという設計の考え方は、次の記事で扱っています。

Syslogサーバのパストラバーサルがコード実行になる機構#

CVE-2026-59310の分類はCWE-22、ディレクトリトラバーサルです。パス名を組み立てる処理が、入力に含まれる ../ のような上位ディレクトリへの参照を正しく制限できず、本来アクセスさせるつもりのないディレクトリへ読み書きが届いてしまう欠陥を指します。Broadcomのアドバイザリは、この欠陥がvCenterのSyslogサーバに存在し、vCenterへネットワーク到達できる攻撃者が任意のコードを実行しうると記載しています。

ここで問われるのは、なぜファイルの置き場所がずれるだけでコードの実行になるのかという点です。答えは、書き込み先のディレクトリの中に、OSが定期的に読み込んで実行する場所があるからです。Linuxでは /etc/cron.d に置かれたファイルがcronの設定として読み込まれ、記述されたコマンドが指定の時刻に実行されます。ログを受け取って所定のパスへ書き出すという処理が、パスの検証を欠いたまま外部からの入力でパスを決めていれば、攻撃者は書き出し先を /etc/cron.d へずらせます。あとは、ログとして送り込む内容をcronの設定として解釈できる形に整えるだけです。

QUIRSOの報告を紹介した記事によれば、侵害されたvCenterでは実際に /etc/cron.d の中に、CVE番号を含む名前の不正なcronファイルが残されていました。そして、それらのコマンドはrootとして実行されており、対応する認証イベントは記録されていませんでした。認証を伴わずにroot権限のコマンドが動いたという痕跡の組み合わせが、この脆弱性の性質をよく表しています。

Syslogの受信処理はログを書き出すことが仕事であり、攻撃を受け付ける窓口として設計されたものではありません。だからこそ、そこに書き込み先を選べる余地が残っていると、認証の壁を通らずにファイルシステムへ手が届いてしまいます。パストラバーサルが単なる情報漏えいで終わらず任意コード実行まで進むのは、書き込みが許される場合に多く見られる帰結です。

NVDに登録されたCVSS v3.1のベクトルは AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H で、ベーススコアは9.8です。ネットワーク経由(AV:N)で、攻撃条件は低く(AC:L)、権限も利用者の操作も不要(PR:N、UI:N)、機密性と完全性と可用性のすべてに高い影響が出るという読み方になります。前提条件がほとんど要らない脆弱性であり、到達性さえあれば成立します。

パストラバーサルがどこで生まれ、どう塞ぐかという原理は、次の記事で整理しています。

BroadcomのVMSA-2026-0006は、CVE-2026-59310をvCenterのSyslogサーバに存在するディレクトリトラバーサルの脆弱性とし、深刻度をCriticalの範囲、CVSSv3のベーススコアの最大値を9.8としています。既知の攻撃経路として、vCenterへネットワークアクセスできる悪意ある行為者が任意のコードを実行しうると記載し、回避策はNoneとしています。同アドバイザリはCVE-2026-59309、CVE-2026-59310、CVE-2026-47876、CVE-2026-41703、CVE-2026-41709の5件を扱い、初回公開日は2026年7月29日、執筆時点で参照できる版はVMSA-2026-0006.2(2026年8月19日更新)です。CVE-2026-59309とCVE-2026-59310は、Atredis PartnersのPhil Brass氏とMatt South氏による非公開の報告と謝辞に記されています。

同時に公表された認証バイパスCVE-2026-59309#

VMSA-2026-0006には、vCenterに関するもう一つのCVSS 9.8が含まれます。CVE-2026-59309は、VMware Directory Serviceの認証バイパスです。Broadcomは、vCenterへネットワーク到達できる攻撃者が認証を迂回してシステムへ不正にアクセスしうると記載しています。VMware Directory Serviceは、vCenter Single Sign-Onの利用者やグループ、サービス主体の情報を保持する役割を担う部品です。ここで認証を迂回されるということは、正規の資格情報を持たない相手にシステムへのアクセスを許すことを意味します。

二つの脆弱性は経路が違います。CVE-2026-59310はSyslogの処理を通ってOSのファイルシステムへ届く経路、CVE-2026-59309は認証の判定そのものを迂回して管理面へ入る経路です。報告された攻撃では、この二つが別の攻撃者によって使われた可能性が示されています。QUIRSOの報告を伝えるJPCERT/CCの週次レポートも、CVE-2026-59310を悪用したとみられる攻撃によるvCenterの侵害とバックドアの設置に加えて、別の攻撃者によるものとみられる活動でCVE-2026-59309が悪用され管理者アカウントが作成された可能性があるとしています。

修正はどちらも同じ版に含まれるため、適用の判断を分ける必要はありません。ただし侵害調査の観点では、痕跡の出方が異なります。CVE-2026-59310の痕跡はファイルシステムとcron、サービスの側に現れ、CVE-2026-59309の痕跡は見覚えのない管理者アカウントの追加として現れます。どちらか一方だけを探して安心しないことが要点です。

JPCERT/CCのWeekly Report(2026年8月19日号)は「複数のVMware製品に脆弱性」として、Broadcomが2026年7月29日に公表した脆弱性についてQUIRSO GmbHがCVE-2026-59309およびCVE-2026-59310の悪用に関する情報を公表したことを伝えています。同社によると、8月3日以降にCVE-2026-59310を悪用したとみられる攻撃によりvCenterが侵害されバックドアなどが設置されたこと、別の攻撃者によるものとみられる活動ではCVE-2026-59309が悪用され管理者アカウントが作成された可能性があることが記載され、影響を受ける製品を使用している場合はBroadcomおよびQUIRSO GmbHの情報を参照のうえ速やかに侵害調査および対策を実施することを推奨しています。

修正公開から5日で始まった悪用の時系列#

この事案の特徴は、悪用の立ち上がりの速さです。ドイツのインシデント対応企業QUIRSOは、あるvCenterの侵害調査から世界規模の攻撃活動を発見し、その内容を8月10日に公表しました。各社の報道が伝える同社の観測は次のとおりです。

観測された被害は361件のIPアドレスで、47か国に分布していました。上位はドイツが55件、米国が41件、トルコが38件、イランが26件、フランスが25件で、この5か国だけで185件と全体の半数を超えます。ただしIPアドレスの件数は組織の数と一致しません。同社は、ホスティング事業者やクラウド、共用インフラのアドレスが含まれるため、IPの件数を被害組織の数として読むべきではないと注記しています。業種としては、技術やソフトウェアとセキュリティの分野、次いで高等教育と研究、通信とネットワークの分野に集中が見られたとされています。

この事案はゼロデイではありません。CVE-2026-59310は非公開で報告され、修正が先に公開されました。それにもかかわらず、公開の5日後には悪用が観測されています。修正の公開はそれ自体が攻撃者への情報提供でもあり、差分から欠陥の位置を特定して悪用コードを組み立てる作業は、条件がそろえば数日で終わります。攻撃者が公開前から脆弱性を把握していた可能性も否定できませんが、いずれにせよ、パッチ公開を安全の合図と受け取って定例の更新まで待つ運用は、この時間感覚と合いません。

修正が公開された脆弱性を後回しにしたときに何が起きるかは、次の記事で扱っています。

居座りの仕掛けからESXiのランサムウェアまで#

QUIRSOの報告を紹介した各社の記事によれば、詳細に調査された侵害環境では、動きが初期侵入だけで終わっていません。攻撃者は複数の手段で足場を固め、最終的に仮想基盤の上の仮想マシンを暗号化する段階まで進んでいました。以下は、その環境で報告された痕跡の整理です。361件のIPすべてで同じ段階まで進んだことを示すものではありません。

初期侵入では、前述のとおり /etc/cron.d に不正なcronファイルが書き込まれ、rootとしてコマンドが実行されました。続いて居座りの仕掛けが複数用意されます。バックドアを再起動させるシステムサービス、vCenterの正規の運用タスクに似せた名前を持つスケジュールタスク、rootの authorized_keys へ追加された攻撃者の公開鍵、Perfchartsのディレクトリへ置かれたJSPのウェブシェル、そしてPerfchartsのサービスアカウントにパスワードなしでrootを許す /etc/sudoers.d のファイルです。名前をvmware由来のものに似せる手口は、運用担当者がファイル一覧をざっと眺めたときに違和感を持たせないためのものです。

外部との通信には、リバースSSHの仕組みが使われました。攻撃者が用意したサーバへ、侵害した側から外向きにSSH接続を張り、その接続の上で遠隔操作を行う形です。この向きが選ばれる理由は、多くの環境で外から中への接続は厳しく制限される一方、中から外への接続は緩いままだからです。侵害されたvCenterから知らない宛先への持続的な外向き接続が出ていれば、それ自体が調査の起点になります。

vCenterを押さえた攻撃者は、そこからESXiホストへ移りました。報告によれば、ESXiにローカルの管理者アカウントを作り、vSphereのデータストアブラウザ経由でランサムウェアの実行ファイルを配置し、補助のスクリプトで仮想マシンを停止させ、VMDKを暗号化し、高可用性の機能を無効化しています。暗号化されたファイルには .babyk の拡張子が付き、Babuk系統から派生した検体と関連づけられました。

この経路には防御側にとっての含意があります。ゲストOSの中で動くウイルス対策やEDRは、ハイパーバイザ側でVMDKごと暗号化されてしまえば手が出せません。仮想基盤の管理面を守ることが、その配下で動く仮想マシンを守ることに直結するのは、このためです。なおQUIRSOは、このランサムウェアの展開に副次的な効果があったとも述べています。ESXiのログファイルが他のデータと一緒に暗号化され、攻撃者の活動をたどるための記録が失われたという点です。

攻撃者の帰属について、QUIRSOは中国につながるとみられる攻撃者の関与を評価しています。根拠として、攻撃者が残したスクリプトに中国語のコメントがあること、被害の分布に中国本土が含まれないこと、活動時間帯がUTC+08:00の勤務時間と整合することを挙げています。帰属の判断は性質上つねに暫定的であり、対応の優先順位を決めるうえで必須の情報ではありません。

暗号化されたあとに何が復旧を左右するかは、次の記事で整理しています。

影響を受ける版と修正#

修正は2026年7月29日のVMSA-2026-0006で提供されています。回避策は用意されていないため、対応は更新の適用に限られます。Broadcomのレスポンスマトリクスに記載された、CVE-2026-59309とCVE-2026-59310に対する修正版は次のとおりです。

vCenter 7.0の行は、通常のサポート期間が終わっている系列に対する扱いです。延長サポート契約を結んでいない環境にはこのアドバイザリの修正が提供されないため、該当する場合は移行の計画そのものが対応策になります。

同じアドバイザリには、vCenter以外の3件も含まれます。CVE-2026-47876はESXのVMXNET3仮想ネットワークアダプタの境界外書き込みで、CVSSは9.3です。仮想マシン上でローカルの管理者権限を持つ攻撃者がホスト側でコードを実行しうるという、いわゆる仮想マシンからの脱出にあたります。Broadcomの謝辞によれば、Zero Day Initiativeが主催するPwn2Ownで報告されたものです。残るCVE-2026-41703は境界外読み取り(ESXで7.6、WorkstationとFusionで2.7)、CVE-2026-41709はESXのログ記録の不足(2.7)です。適用の順序を考えるなら、まず外部から到達しうるvCenterの2件、次にホスト脱出につながるCVE-2026-47876という並びになります。

NVDのCVE-2026-59310のページは、VMware vCenterのSyslogサーバにディレクトリトラバーサルの脆弱性が存在し、vCenterへネットワークアクセスできる悪意ある行為者が任意のコードを実行しうると記載しています。CVSS v3.1のベーススコアは9.8(VMwareによる評価)、ベクトルはCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H、弱点はCWE-22です。

KEV収録と是正期限の適用対象#

CISAのKEVカタログは、悪用が実際に確認された脆弱性を集めた一覧です。CVE-2026-59310は2026年8月18日に、同日追加された4件(Microsoft Internet Key Exchange Service ExtensionsのCVE-2026-33824、Microsoft SharePointのCVE-2026-55040、Apple macOSのCVE-2026-65400)の一つとして収録されました。カタログ上の是正期限は2026年8月21日です。ランサムウェアキャンペーンでの利用については、カタログの記載はUnknownとなっています。

この是正期限が拘束するのは、CISAのBOD 26-04(Prioritizing Security Updates Based on Risk)にもとづく米国の連邦文民行政機関(FCEB)です。日本の組織に、この日付までに対応する法的義務が直接生じるわけではありません。一方で、KEVに載っているという事実は、その脆弱性が理論上の危険ではなく現に悪用されている証拠です。数あるCVEの中でどれから手を付けるかを決めるとき、KEV収録は優先度を引き上げる強い根拠になります。

今回のケースでは、KEV収録の時点(8月18日)より前に大規模な悪用(8月3日から)が進んでいました。KEVへの収録は悪用の観測に対して遅れて到着する情報であり、それだけを起動条件にすると出遅れます。CVSS 9.8で回避策がなく、管理面に位置する製品という条件がそろった時点で、KEVを待たずに緊急扱いへ切り替える判断が妥当でした。

KEVとEPSSを組み合わせて社内の適用順を決める考え方は、次の記事で扱っています。

CISAのKEVカタログは、CVE-2026-59310をBroadcom VMware vCenterのパストラバーサル脆弱性として収録し、vCenterへネットワークアクセスできる脅威アクターが任意のコードを実行しうると記載しています。追加日は2026年8月18日、Due Dateは2026年8月21日、CWEはCWE-22、ランサムウェアキャンペーンでの利用はUnknownです。求められる措置として、ベンダーの指示に従った緩和とBOD 26-04およびForensics Triage Requirementsへの準拠が示されています。この期限はBOD 26-04にもとづき米国の連邦文民行政機関へ課されるもので、それ以外の組織に対してはカタログを脆弱性管理の優先順位付けの入力として使うことが想定されています。

侵害調査で見るべき痕跡#

修正の適用は必要ですが、それだけでは足りません。8月3日から8月上旬にかけて広範な悪用が進んでいたため、更新前にインターネットから到達できる状態でvCenterを運用していた環境は、すでに踏まれている可能性を前提に確認する必要があります。パッチは新たな侵入を止めますが、すでに置かれたcronやSSHの鍵、ウェブシェルは残ったままです。

確認すべき観点を挙げます。いずれも公開された報告で示された痕跡の種類にもとづくもので、具体的な検体名やアドレスの照合はQUIRSOおよびBroadcomの公開情報を直接参照してください。

痕跡が見つかった場合は、復旧を急ぐ前に保全を優先します。仮想基盤の管理面が侵害されている状況では、影響範囲がゲスト全体に及ぶ可能性があり、どの仮想マシンにいつ触れられたかを後から確認できるかどうかが調査の成否を分けます。ログとディスクの状態を保全してから、封じ込めと再構築の手順に進みます。

侵害を検知したあとの初動の組み立ては、次の記事で整理しています。

組織がとるべき対応#

このうち優先度が高いのは、更新の適用と到達範囲の確認です。前者は脆弱性そのものを塞ぎ、後者は今回に限らず今後の同種の脆弱性に対する被害の上限を下げます。境界に置かれた機器や管理装置の脆弱性が繰り返し狙われる構造については、次の記事で扱っています。

まとめ#

CVE-2026-59310は、VMware vCenterのSyslogサーバに存在するディレクトリトラバーサルです。vCenterへネットワーク到達できる攻撃者が、認証なしでファイルの書き込み先をずらし、cronの設定として読み込まれる場所へ到達することで、root権限のコード実行に至ります。CVSSは9.8で、回避策はありません。

この事案が突きつけるのは、ゼロデイでなければ猶予があるという前提の危うさです。修正は2026年7月29日に公開されましたが、8月3日には最初の侵害が観測され、8月5日までに観測された被害の約95%が出そろいました。適用の判断を定例の更新まで待つ運用では間に合わない速度です。

そして詳細に調査された環境では、被害がvCenterの中で終わっていません。cronとリバースSSHで居座った攻撃者はESXiへ移り、データストア経由でランサムウェアを配置してVMDKを暗号化する段階まで進んでいました。仮想基盤の管理面は、その配下で動く仮想マシンの稼働と可用性をまとめて左右する場所です。更新の適用に加えて、管理インターフェースを外から触れない位置へ置くこと、そしてバックアップを管理面から切り離しておくことが、同じ構図の攻撃に対する現実的な備えになります。