JPCERT/CCは2026年8月19日付のWeekly Reportで、Broadcomが7月29日に公表したVMware製品の脆弱性が実際に悪用されていることを取り上げ、影響を受ける製品を使っている組織に対して速やかな侵害調査と対策を推奨した。ドイツのインシデント対応事業者QUIRSO GmbHの分析によれば、8月3日以降、仮想化基盤の管理サーバーであるvCenterが次々と侵害され、バックドアが設置されている。パッチ公表から攻撃開始までの猶予は、わずか5日間だった。
認証なしで乗っ取れる二つの穴
Broadcomが2026年7月29日に公表したセキュリティアドバイザリVMSA-2026-0006（その後VMSA-2026-0006.1に改訂）には、vCenterに関する二つの重大な脆弱性が含まれている。
一つはCVE-2026-59310。vCenterのSyslog（ログ収集）サーバーに存在するディレクトリトラバーサル（パス指定を細工され、本来アクセスできない範囲のファイルに到達される）の脆弱性で、QUIRSOはBroadcomの記述を引きながら、vCenterにネットワークアクセスできる攻撃者が任意のコードを実行できる可能性があり、脆弱性の深刻度を示す指標であるCVSSスコアは9.8に達するとしている。もう一つはCVE-2026-59309で、vCenterのディレクトリサービスにおける認証バイパス（正規のログイン手続きを迂回される）の脆弱性だ。こちらも報道によると同じく9.8と評価されている。
深刻なのは、どちらも事前の認証を必要としない点だ。加えてBroadcomは、CVE-2026-59310について回避策がないと明言している。設定変更で凌ぐ余地がなく、パッチ適用だけが対処になる。修正済みのvCenterリリースは、9.1系が9.1.0.0300、9.0系が9.0.2.0100、8.0系は導入しているブランチに応じて8.0 U3kまたは8.0 U2fとされている。
5日、そして3日で広がった
QUIRSOが8月10日に公表した分析は、攻撃の広がる速度を具体的な数字で示している。
同社が確認した被害システムが攻撃者のインフラへ最初に接続したのは、アドバイザリ公表から5日後の8月3日だった。翌8月4日には151件の被害IPアドレスが新たに観測され、8月5日までに全体の約95％にあたる343件が出そろった。最終的に確認された被害IPアドレスは47カ国の361件にのぼる。上位5カ国はドイツ、米国、トルコ、イラン、フランスで、この5カ国だけで185件、全体の半数強を占めた。
QUIRSOは、攻撃者が脆弱性を事前に把握していた可能性は否定しないとしつつ、公表時期と悪用時期の強い相関から、アドバイザリの公表そのものがこのキャンペーンの起点になったとみている。同社は攻撃者について、高度で持続的な脅威（APT）グループとみられると評価し、続報では中国系とみられる攻撃者との関連を指摘している。
侵入後に置かれた「裏口」
侵害後、攻撃者は永続的なアクセス手段としてreverse_sshを設置していた。これはSSHをベースにしたオープンソースのリバースシェル基盤で、本来はペネトレーションテスト用のツールだ。自動的な接続の折り返し、SSHポートフォワーディング、ファイル転送、リモートシェル管理といった機能を備える。
攻撃者にとっての利点は、侵害したシステムから外向きに制御チャネルを張れることにある。多くの組織のセキュリティ対策は、外から中への予期しない接続を止めることに主眼が置かれている。内側から外へ出ていく通信は、その網をすり抜けやすい。
QUIRSOは、reverse_sshが存在すること自体を悪性の証拠と扱うべきではないと注意を促している。正規の用途でも使われるツールだからだ。ただし、許可のないインストール、想定外の外向き通信、脆弱なvCenterアプライアンス上での実行といった状況と組み合わさった場合には、優先度の高い調査対象になるとしている。同社は検出を支援するため、reverse_sshのプログラムを検出するための汎用パターン（YARAルール）をGitHubで公開している。
一方、JPCERT/CCは別の攻撃者によるとみられる活動として、CVE-2026-59309が悪用され管理者アカウントが作成された可能性にも触れている。一つの脆弱性公表が、複数の攻撃者を同時に動かした形とみられる。
数字の読み方には注意がいる
361件という数字は、そのまま361の被害組織を意味しない。QUIRSO自身が、IPアドレスは必ずしも一つの企業や物理システムに対応するわけではなく、ホスティング事業者やクラウドネットワーク、共用インフラのアドレスも含まれると断っている。
逆に言えば、共用インフラ上の一つのアドレスの背後に複数の組織が並んでいる可能性もある。実際の影響範囲は、この数字より大きいことも小さいこともありうる。確かなのは、インターネットから到達できるvCenterが世界中で狙われ、短期間に相当数が侵害されたという事実のほうだ。
パッチを当てて終わりにできない理由
vCenterは、仮想マシンを束ねる管理サーバーである。ここを取られるということは、その配下で動いているすべての仮想サーバーに手が届く位置を攻撃者に明け渡すことに等しい。基幹システムも、ファイルサーバーも、場合によっては認証基盤も、同じ物理基盤の上に載っている。一台の侵害が一台で終わらないのが仮想化基盤の怖さだ。
そして今回の事案が突きつけるのは、パッチ適用が「済ませたかどうか」だけの話ではなくなっている、という点である。8月3日から5日にかけて攻撃が集中していたということは、その時点で更新が終わっていなかった環境は、すでに侵害されている可能性を前提に考える必要がある。今からパッチを当てても、設置済みのバックドアは消えない。JPCERT/CCが「対策」と並べて「侵害調査」を推奨しているのは、そういう意味だ。
やるべきことは三つに整理できる。まず、Broadcomのアドバイザリの対応表で自環境のバージョンを確認し、修正版へ更新すること。次に、7月29日以降のvCenterのログや外向きの通信履歴を精査し、想定外の接続や見覚えのないアカウントが作られていないかを調べること。そして、そもそもvCenterの管理インターフェースをインターネットから直接到達できる状態に置く必要があるのかを、この機会に問い直すことだ。
公表から悪用まで5日。この間隔は、今後さらに縮まっていくと考えたほうがいい。
同じ手口に、自社は備えられていますか？