「メタルギアオンライン」でロビー参加だけでPCを乗っ取られる恐れ、任意コード実行につながる脆弱性が判明
PC版「メタルギアオンライン」のバージョン1.1.2.8に、悪意あるホストが用意したロビーへ参加するだけでプレイヤーのPC上で任意のコードを実行される可能性がある脆弱(ぜいじゃく)性が存在していたことをCERT Coordination Center(CERT/CC)が2026年8月24日に明らかにしました。脆弱性は「CVE-2026-19874」として登録されており、バージョン1.1.2.9で修正済みとされています。
VU#728712 - Konami's Metal Gear Online 3 contains a heap-based buffer overflow https://kb.cert.org/vuls/id/728712
「メタルギアオンライン」は「METAL GEAR SOLID V: THE PHANTOM PAIN」に収録されているオンライン対戦モード。PC版では最大16人による8対8の対戦に対応しており、Steam Matchmakingを使ってロビーや対戦を管理しています。プレイヤーは自動マッチングのほか、ほかのユーザーが作成したマッチを選んで参加することも可能です。 オンライン対戦では必要に応じてプレイヤーをロビーから除外する仕組みが用意されています。メタルギアオンラインでは除外されたプレイヤーを判別するため、除外対象の人数を示す「kick_num」と、対象となったSteam IDを記録する「kicked_id_%i」という情報をロビー側で管理しています。プレイヤーがロビーへ入る際には自分のSteam IDが除外リストに含まれていないかをゲーム側が確認し、該当する場合はマッチへの参加を拒否する仕組みです。
CERT/CCによると、「kick_num」に入れられた数値をゲーム側が十分に確認していなかった点が問題になったとのこと。想定より大きな値を指定すると、除外対象のSteam IDを保存するために確保されたメモリ領域を越えてデータを書き込めてしまう「ヒープベースのバッファオーバーフロー」が発生していました。バッファオーバーフローが起きると確保済みのメモリ領域からはみ出してデータが書き込まれ、場合によってはプログラムの動作を書き換えられる可能性があります。 今回の場合、書き込み先のすぐ近くにはSteamworksがロビー情報の変更やメッセージを処理するときに使うコールバック用のデータが配置されていました。コールバックには次に実行する処理の場所を示す情報も含まれているため、攻撃者が細工したロビー情報を送り込むことで次に実行する処理の場所を書き換え、ゲームを動かしているPC上で任意のコードを実行できる可能性があったとのこと。被害者側でファイルを開いたりリンクをクリックしたりする追加操作は必要なく、攻撃者が管理するロビーへ参加しただけで攻撃が成立可能でした。
CERT/CCによると、メタルギアオンラインで使用されている改ざん防止技術「Denuvo」のために用意された特殊なメモリ領域が攻撃を成立させやすくしていた要因だったとのこと。このメモリ領域はデータの読み取り・書き込み・プログラム実行のすべてが許可された「RWX」と呼ばれる領域となっており、攻撃者がコードを実行することに悪用可能でした。また、対戦中にホストが退出すると別の参加者へホスト権限が自動的に移動するため、攻撃者が途中からホスト権限を取得して接続中の複数プレイヤーへ悪意あるロビー情報を送信することも可能だったとのこと。 脆弱性は「mgsvmgo.exe」のバージョン1.1.2.9で修正されています。修正に合わせてサーバーのバージョン番号は15から16、ロビーのバージョン番号は150から160へ変更され、脆弱な旧バージョンからオンラインサービスへ接続できないようになりました。
脆弱性を報告したのはセキュリティ研究者のアリーチェ・チェケット氏で、CERT/CCによるとKONAMIには2026年7月15日に問題が通知されています。記事作成時点でKONAMIはCVE-2026-19874について個別のパッチノートやセキュリティ情報を公開しておらず、CERT/CCもKONAMIから声明を受け取っていないとしています。
・関連記事 Cursorに「リポジトリを開くだけ」で任意コードが実行される脆弱性、報告から7カ月たっても修正されず研究者が全容公開 - GIGAZINE
老舗圧縮解凍ソフト「WinRAR」でファイルを開くだけで任意コード実行を可能にする脆弱性が発見される、すでに修正版が配布済み - GIGAZINE
GitHubのアクセストークンが「リンクを1回クリックしただけ」で盗まれる脆弱性が報告される - GIGAZINE
AIエージェントに「安全なコマンド」を許可しただけで任意コード実行、Dockerが解説するコマンド承認の落とし穴 - GIGAZINE