トップ/記事一覧/VMware vCenterに乗っ取り被害、47カ国361件 CVE-2026-59310は8.0 U3kへ
vmware-vcenter-cve-cover-ja

VMware vCenterに乗っ取り被害、47カ国361件 CVE-2026-59310は8.0 U3kへ

仮想サーバーをまとめて管理するVMware vCenterに、ログイン不要で乗っ取られる脆弱性CVE-2026-59310が見つかり、修正公開から5日で攻撃が始まりました。世界47カ国361件で侵入を確認。米政府は8月21日を対応期限に設定しています。回避策はなく、8.0 U3k・9.0.2.0100・9.1.0.0300への更新と、侵入痕跡の確認が必要です。

ニュース2026年8月19日公開 本日更新
目次
この記事のポイント

仮想サーバーをまとめて管理するVMware vCenterに、ログイン不要で乗っ取られる脆弱性CVE-2026-59310が見つかり、修正公開から5日で攻撃が始まりました。世界47カ国361件で侵入を確認。米政府は8月21日を対応期限に設定しています。回避策はなく、8.0 U3k・9.0.2.0100・9.1.0.0300への更新と、侵入痕跡の確認が必要です。

社内の仮想サーバーをまとめて管理するVMware vCenter(ブイセンター)に、ログインなしでサーバーを乗っ取られる脆弱性CVE-2026-59310(危険度9.8)が見つかり、修正版の公開から5日後には実際の侵入が始まっていました。ドイツの調査会社QUIRSOが観測した被害は、8月7日までに47カ国・361件にのぼります。

米国の政府機関CISAは2026年8月18日、この欠陥を実際に攻撃されている脆弱性のリスト(KEV)に追加しました。連邦機関に与えられた猶予は2026年8月21日まで、わずか3日です。しかもこの枠に入った脆弱性は、直すだけでは足りません。すでに侵入されていないかを調べることまでが義務になっています。

回避策はありません。設定変更でしのぐ手はなく、Broadcom(ブロードコム、VMwareを買収した半導体・ソフトウェア企業)が配っている修正版へ上げるしかない状態です。この記事では、自分の環境が対象かの見分け方、上げるべきバージョン番号、すでに入られていないかを確かめる方法を先に整理します。

この記事の要点(3行)

  • vCenterのログ受け取り機能に穴があり、ログイン不要・利用者の操作不要で、管理者相当の権限でプログラムを動かされる。危険度は10点満点中9.8。
  • 7月29日の修正公開から5日で攻撃が始まり、8月7日までに47カ国361件で侵入を確認。攻撃者は自動実行の設定に細工して居座り、外向きの接続で操作を続ける。ESXi側へ広がった例もある。
  • 回避策なし。vCenter 8.0はU3k(またはU2f)、9.0系は9.0.2.0100、9.1系は9.1.0.0300へ。更新に加えて、7月29日までさかのぼった痕跡の確認が要る。

自分の環境は対象か、どのバージョンに上げるのか

対象は自社で運用しているvCenter Serverです。BroadcomのセキュリティアドバイザリVMSA-2026-0006(2026年7月29日公開、8月3日に改訂)が示す更新先は次のとおりです。番号を1文字でも取り違えると当たらないので、そのまま控えてください。

いま使っている版上げるべき版備考
vCenter 9.1系9.1.0.0300通常の更新で対応
vCenter 9.0系9.0.2.0100通常の更新で対応
vCenter 8.0系8.0 U3k
または 8.0 U2f
U2fは8月3日の
改訂で追加された
VMware Cloud
Foundation 5.x
8.0 U3k個別配布のパッチ
として適用する
vSphere 7.0標準の修正なし2025年10月に
サポート終了済み
回避策なし設定変更で
しのぐ手段はない

同じアドバイザリでは計5件が直っています。とくにCVE-2026-59309(危険度9.8)は、利用者情報を扱う内部サービスの認証を素通りできてしまう欠陥で、セキュリティ企業Rapid7の解説によればvCenterの管理側へ無断で入り込めます。こちらもすでに悪用が観測されているのに、KEVには入っていません。番号で優先度を決めていると取りこぼしかねない部分です。同じ更新で両方ふさがるので、片方だけ気にする意味はありません。

なお、vSphere 6.5と6.7には修正が用意されておらず、Broadcomは新しい世代への移行を促しています。8.0 U3kを当てると新世代への移行経路が一時的に制限されるという注意事項もあり、セキュリティ修正が製品の乗り換え圧力とセットになっているのが今回の面倒なところです。

誰が、何のために狙うのか

今回動いているのは、長く居座って情報を取ることを目的にした、組織立った攻撃集団です。QUIRSOは、スクリプトに残った中国語の痕跡、使われている道具、稼働している時間帯(日本と同じ時間帯)、そして中国本土に被害が1件もないことから、中国語を話す集団による活動である可能性が高いと中程度の確度で評価しています。特定の名前は付けられていません。

彼らがやっているのは、乗っ取ったvCenterに、正規のVMwareサービスを装った「自動実行の予定表」を書き込んで住み着くことです。サーバーが定期的にプログラムを動かす仕組みに細工を加え、自分たちの管理下にある外部のサーバーへ、内側から接続を張らせます。外から入るのではなく中から出ていく通信なので、ファイアウォールの「外からの侵入を止める」という守りをすり抜けます。再起動しても設定は残ります。

そこから先が本番です。vCenterに保管されている認証情報を抜き、配下のESXi(実際に仮想サーバーを動かしている土台)へ横に広がり、仮想マシンのファイルを外へ持ち出す。少なくとも1件では、ESXi上のファイルが暗号化されて拡張子が書き換えられました。ただし研究者はこれを身代金目的ではなく、ログを潰して調査を妨害するための目くらましと見ています。

被害の形はこうなります。サービスを使う一般の人から見れば、ある朝から社内システムや取引先のサービスがつながらない、という形で現れます。運用している企業にとっては、業務停止、仮想マシンごとの情報流出、バックアップの破壊、そして「いつから入られていたのか分からない」という調査コストが同時に来ます。過去には仮想化基盤を止められて決算業務そのものが動かなくなった企業もあり、情報漏えいだけの話では終わりません。

vCenterとは何か、なぜ狙われ続けるのか

1台の物理サーバーの中に複数の「仮想的なサーバー」を作って動かす技術を仮想化と呼びます。VMwareはこの分野の代表的な製品群で、実際に仮想サーバーを動かす土台がESXi、それらを何十台・何百台とまとめて面倒を見る管理ソフトがvCenterです。管理者はvCenterの画面から、サーバーの起動・停止・複製・移動をまとめて行います。

つまりvCenterは社内インフラで最も権限が集中する「鍵束」です。1カ所落とすだけで数百台の実権が手に入るので、攻撃者にとっては効率のいい標的になります。今回の攻撃がvCenterからESXiへ素直に広がっているのも、この構造どおりの動きです。

狙われるのは初めてではありません。CISAのKEVリストには、VMware関連の脆弱性がこれまでに33件載っています。とくに2021年のCVE-2021-21972は、今回とまったく同じ「上の階層へ戻れてしまう」種類の欠陥で、危険度も同じ9.8、条件も同じくログイン不要でした。5年を隔てて、同じ型の穴でvCenterが二度KEV入りしたことになります。

番号場所危険度
CVE-2021-219722021管理画面の
拡張機能
9.8
CVE-2023-340482023内部通信の
処理
9.8
CVE-2024-388122024内部通信の
処理
9.8
CVE-2026-593102026ログ受け取り
機能
9.8

Broadcomによる買収以降のライセンス変更を受けて、他基盤への移行を検討する国内企業も増えています。日経クロステックは最大20倍の値上げ事例を報じ、公正取引委員会も2026年7月3日に審査結果を公表しました(違反は認定されず審査終了)。ただ移行には年単位かかります。「いずれ乗り換えるから」は、いま動いているvCenterを守らない理由になりません。当サイトでもVMware製ロードバランサーの脆弱性や、移行ツール側からvCenterの管理者情報が漏れる欠陥を扱ってきました。移行の途中こそ穴が増えます。

何が起きるのか、仕組みを分解する

問題があるのは、vCenterに組み込まれているログ受け取り機能(Syslogサーバー)です。社内の機器から送られてくる動作記録を受け取って保存する部品で、外部から通信を受け付ける口として常に開いています。

ここにディレクトリトラバーサルと呼ばれる欠陥がありました。保存先のファイル名を組み立てるときに「ひとつ上の階層へ戻る」という指定を弾いておらず、本来書き込んではいけない場所へファイルを置けてしまいます。書き込み先を選べるということは、システムが読み込む設定ファイルを差し替えられるということで、結果として任意のプログラムの実行につながります。QUIRSOの調査によれば、実行される権限は管理者相当(root)です。

危険度が9.8まで上がる理由は、条件の少なさです。事前のアカウントもいらず、誰かにリンクを踏ませる必要もなく、vCenterに通信が届く位置にいるだけで成立します。社内ネットワークに入り込んだ攻撃者はもちろん、管理画面をインターネット側にさらしている環境なら外部から直接届きます。

攻撃の流れは、ログ機能へ細工した通信を送る → 管理者権限でプログラムを実行 → 正規サービスを装った自動実行を仕込む → 公開ツールreverse_sshで外部の指令サーバーへ接続を張る → 認証情報を抜いてESXiへ広がるという順番です。目立つ独自ツールをほとんど使わず、サーバーに元からあるコマンドで済ませているのが特徴で、その分だけ気づきにくくなっています。

日本語訳

攻撃者はVMware vCenterの脆弱性を悪用したあと、reverse_sshを実行する自動タスクを仕込んで居座り続けている。被害は47カ国361のIPアドレスにおよぶ。

公表から侵入まで5日、その後の広がり方

今回とくに重いのは、修正が出てから攻撃が始まるまでの間隔です。BleepingComputerが伝えたQUIRSOの観測Shadowserverの特別レポートを時系列に並べると、次のようになります。

日付起きたこと
7月29日Broadcomが修正版と
アドバイザリを公表
8月1日もう1件の脆弱性を狙う
動きを観測
8月3日乗っ取られたサーバーが
攻撃者側へ通信を開始
8月4日新たに151件の
被害IPを観測
8月5日累計343件
(最終値の約95%)
8月7日累計361件・47カ国
8月13日Shadowserverが被害組織へ
通知を配信開始
8月18日米CISAがKEVへ追加
期限は8月21日

被害が確認された361件のIPアドレスは47カ国に散らばっており、ドイツ55件、米国41件、トルコ38件、イラン26件、フランス25件の5カ国で過半数を占めます。日本国内の件数は公表されていません。またQUIRSO自身が「IPの数と被害組織の数は一致しない」と注記しており、レンタルサーバーなどで1つのIPに複数の利用者がいる場合があります。この数字は1社が調査の過程で観測した範囲であって、世界の総数ではありません

注目すべきは、Rapid7が7月29日の解説時点で「悪用やスキャンの兆候は確認されていない」と書いていたことです。公表時点で静かだったからといって安全ではありませんでした。実証コードが世に出るより先に、修正の差分から攻撃手法を組み立てる作業が終わっていた、ということです。

そしてもうひとつ引っかかる点があります。Broadcom自身は現時点でも「悪用が起きていることを示す情報はない」という説明を変えていません。CISA、Shadowserver、QUIRSO、そして日本のJPCERT/CCが揃って侵害を報告しているのに、製品ベンダーの案内だけが違う温度のままです。ベンダーの記述だけを見て判断すると、対応が遅れます。

期限3日の意味は「直せ」ではなく「直して調べろ」

KEVに追加された脆弱性には、米国の連邦機関に対する修正期限が付きます。今回の3日という短さは、CISAが運用を切り替えたBOD 26-04という指令によるものです。インターネットに露出しているか、実際に攻撃されているか、自動化できるか、システムを丸ごと奪われるか。この4つの条件で優先度を決め、すべて当てはまるものが最短の枠に入ります。

大事なのは、この枠では修正の適用だけでなく、侵害されていないかを調べる作業まで求められることです。日本の民間企業に法的な拘束力はありませんが、「もう入られている前提で確認しろ」という判断が米政府から出ている、という事実の意味は同じです。8月3日から攻撃が始まっていた以上、8月上旬に更新した組織でも、更新前に入られていた可能性が残ります。

すでに入られていないかを確かめる

パッチを当てても、すでに仕込まれた自動実行の設定は消えません。更新と並行して、次の観点で確認してください。

まず、vCenterから外へ出ていく通信です。今回の攻撃はSSH(サーバーを遠隔操作する通信方式)の接続を内側から外へ張ります。vCenterが管理外のIPアドレスへ継続的に接続していないか、ファイアウォールやプロキシの記録を7月29日以降にさかのぼって見ます。管理サーバーが外部と自発的に喋り続けているのは、正常な状態ではありません。

次に、自動実行の設定です。覚えのないジョブが登録されていないか、登録日時が7月末以降のものがないかを確認します。今回の攻撃者は正規のVMwareサービスに似た名前を付けて紛れ込ませるので、名前が「それっぽい」ことは安全の根拠になりません。日時で洗うのが確実です。

3つめはログ受け取り機能まわりと、ESXi側の様子です。想定していない場所にファイルが作られていないか、ESXiのログが不自然に欠けていないか、覚えのない管理者アカウントが増えていないか。攻撃者はvCenterから認証情報を抜いてESXiへ広がるので、vCenterだけ見て終わりにはできません。

QUIRSOは、reverse_sshを見つけるための検出ルールをGitHubで公開しています。ただしreverse_sshは診断業務でも使われる正規のツールなので、これだけで判断せず、「vCenterの上に置かれている」「想定外の外向き通信を伴う」という組み合わせで見てください。判断に迷う場合は、自組織のセキュリティ担当や契約している調査会社に、CVE番号と7月29日という日付を添えて相談するのが早道です。

✓ いま確定している事実

  • CVE-2026-59310は実際に悪用されている(CISA KEV、2026年8月18日追加JPCERT/CC Weekly Report
  • 回避策は存在せず、更新以外の対処はない(Broadcomのアドバイザリ)
  • 危険度9.8、ログイン不要・利用者の操作不要(NVD
  • 発見・報告はAtredis PartnersのPhil Brass氏とMatt South氏

? まだ確定していないこと

  • ?攻撃者の正体 ― 中国語話者と中程度の確度で評価されているが、集団名の特定はされていない
  • ?日本国内の被害件数 ― 47カ国の内訳に日本が含まれるかは公表されていない
  • ?身代金要求が目的かどうか ― 暗号化は確認されたが、調査妨害の目くらましという見方が示されている。CISAのKEVでも身代金との関連は「不明」扱い

日本の公的機関からは、まだ単独の注意喚起が出ていない

危険度9.8、悪用確認済み、回避策なし。それでも2026年8月19日時点で、JPCERT/CCの注意喚起、JVN、IPAの重要なセキュリティ情報のいずれにも、本件の単独ページは出ていません。JPCERT/CCは8月19日号のWeekly Reportで「8月3日以降、CVE-2026-59310を悪用したとみられる攻撃によりvCenterが侵害され、バックドアなどが設置された」と報告していますが、位置づけは週次のまとめの中の1項目です。

日本語の情報がないわけではありません。Security NEXTは7月29日に脆弱性そのものを、8月19日にKEV収載を報じており、@ITITmedia エンタープライズも8月上旬に取り上げています。ただし「自社が対象か、いつまでに何をするか」を判断する材料としては、公的機関からの明確な号令がまだ来ていない状態です。社内で対応を通すときに「JPCERTが出していないから」と止まらないよう、この記事の内容を根拠に使ってください。

同じ日に「攻撃されている」と認定された3件

2026年8月18日、CISAはvCenterを含めて4件をまとめてKEVへ追加しました。期限はいずれも8月21日です。残る3件も日本の職場で使われている製品ばかりなので触れておきます。全件の検索は当サイトのCISA KEV日本語ダッシュボードから行えます。

番号製品内容危険度
CVE-2026-59310VMware vCenterログ機能から
乗っ取り
9.8
CVE-2026-55040SharePoint Server利用者証明を
偽造してなりすまし
9.1
CVE-2026-33824Windows
(VPN関連機能)
メモリ処理の不具合から
遠隔でプログラム実行
9.8
CVE-2026-65400macOS画面共有に
パスワードなしで接続
9.8

SharePoint Server(社内ポータルや文書共有に使うMicrosoftの製品)のCVE-2026-55040は、利用者であることを示す電子的な引換券の検証がいくつも抜けていて、偽造した券で管理者になりすませるというものです。修正は2026年7月の月例更新に含まれています。Rapid7が8月11日に実証コードを公開した翌日、実際の攻撃が観測されました。自社運用のSharePointを持つ組織は、7月に相次いだSharePointの脆弱性をまとめた記事とあわせて更新状況を点検してください。

WindowsのCVE-2026-33824は、VPN通信の鍵交換を担う部品の不具合です。修正は2026年4月の月例更新に含まれており、Windows 10・11とWindows Serverの広い範囲が対象でした。Palo Alto Networksの調査部門Unit 42は、この欠陥がAIに攻撃手順を自動で組み立てさせるキャンペーンで使われていたと報告しています。月例更新をためている環境は、まずここから消化してください。

macOSのCVE-2026-65400は、Macの「画面共有」に正しいパスワードなしで接続できてしまうものです。同じネットワークにいる相手から、管理者権限でファイルを読み書きされます。修正版はmacOS Tahoe 26.6.1、Sequoia 15.7.9、Sonoma 14.8.9で、Appleが8月6日に公開しました。オランダの政府機関は、この穴を突いて管理者権限を取り、暗号通貨の採掘プログラムを置く攻撃を確認したと注意を呼びかけています。画面共有を使っていないなら、機能自体を切っておくのが安全です。

日本語訳

VMware vCenterの重大な脆弱性が47カ国で活発に悪用されている。回避策はなく、直ちに修正を適用すること。

いま何をすればいいのか

やることは3つです。

1つめは更新。8.0系ならU3kかU2f、9.0系なら9.0.2.0100、9.1系なら9.1.0.0300です。回避策がない以上、検証環境での確認を待つあいだも穴は開いたままだという前提で日程を組んでください。米政府が連邦機関に与えた猶予は、KEV追加からわずか3日です。

2つめは到達範囲を絞ること。vCenterの管理画面がインターネットから直接見える状態になっていないか、いま確認してください。管理系は業務ネットワークから分離し、到達できる端末を限定するのが本来の姿です。更新が終わったあとも、この設計は残ります。

3つめは侵入済みかどうかの確認。前の章の3点、外向き通信・自動実行の設定・ESXi側の様子を、7月29日までさかのぼって見ます。更新だけで終わらせると、すでに仕込まれた居座り用の設定が生き残ります。今回の期限の短さは、まさにここまでを求めるためのものです。

仮想化基盤は、止まったときの影響が事業全体に及びます。WebLogicのように長く狙われ続けてきた製品と同じで、vCenterも一度リストに載れば継続的に探索されます。今回の更新を、管理系サーバーの露出を見直す機会にするのが現実的です。

まとめ

VMware vCenterのCVE-2026-59310は、ログイン不要でサーバーを乗っ取れる危険度9.8の欠陥で、修正の公開から5日で実際の侵入が始まりました。8月7日までに47カ国361件で被害が確認され、米CISAは8月18日にこれを実際に攻撃されている脆弱性として認定し、期限を8月21日に設定しています。

回避策はありません。8.0 U3k(またはU2f)、9.0.2.0100、9.1.0.0300のいずれかへ更新することが唯一の対処です。そして、更新前に入られていた可能性を潰すため、外向きの通信と自動実行の設定を7月29日までさかのぼって確認してください。管理台帳を握られたまま「パッチは当てました」で終わるのが、いちばん危ない着地です。

参照元

avatar-m-1

堀川 慎

Backend Engineer / AWS / Django / Go