vm2に乗っ取りの脆弱性8件、v3.11.4へ更新を CVE-2026-47131

ブログ/記事一覧/vm2に乗っ取りの脆弱性8件、v3.11.4へ更新を CVE-2026-47131

ニュース本日更新

堀川慎

Backend Engineer / AWS / Django / Go

2026.06.1311 min6 views

Share X Hatena LINE LinkedIn RSS

この記事のポイント

他人が書いたコードを安全に動かすNode.jsの定番部品「vm2」に、サーバーを乗っ取れる脆弱性が8件見つかりました。うち3件は危険度が最高の10.0です。修正版はvm2 3.11.4。ただしvm2は開発終了済みで、根本対策はisolated-vmなど別方式への移行です。npm ls vm2で依存を確認してください。

他人が書いたプログラムを「安全な檻の中」で実行するための定番部品vm2（ブイエムツー）に、檻を破ってサーバーを乗っ取れる脆弱性が一度に8件見つかり、修正版が公開されました。8件のうち3件は、危険度を示す国際スコアが最高の10.0です。vm2は、外部から受け取ったコードやAIが生成したコードを、本体に被害が及ばないよう隔離して動かすためのライブラリで、npm（ネットの部品置き場）から週130万回以上ダウンロードされています。

見つかった8件はすべて2026年6月12日に公開され、いずれもvm2 3.11.4で修正されています。最高スコアのCVE-2026-47131、CVE-2026-47137、CVE-2026-47140、CVE-2026-47208は、檻の中のコードからサーバー本体で任意のプログラムを実行できる「サンドボックス脱出」です。残るCVE-2026-47210（9.8）、CVE-2026-47135（8.7）、CVE-2026-47139（8.6）、CVE-2026-47209（8.6）も、隔離の壁を回避したり本体側のデータを書き換えたりする穴です。

そして今回いちばん重いのは、個々の穴の深さよりも前提のほうです。vm2はすでに開発が終了したライブラリで、作者自身が「これ以上の安全は保証できない」と表明しています。つまり3.11.4への更新は今回の8件をふさぐ応急処置にはなりますが、根本的な対処は「vm2を使うのをやめて別の隔離方式へ移ること」です。今のところ実際の攻撃に使われた報告はありませんが、後述するようにvm2は2026年に入って脆弱性が立て続けに出ており、放置するほど危険が積み上がります。

vm2とは何で、なぜ自分にも関係するのか

vm2は、JavaScript（ウェブやサーバーで動く言語）のプログラムの中で、信用できないコードを「サンドボックス」と呼ばれる隔離環境で動かすための部品です。サンドボックスとは、子どもを遊ばせる砂場のように、何をしても外（サーバー本体）には影響が出ない閉じた領域のことを指します。外部のユーザーが投稿した数式やスクリプトを評価する、プラグインやテンプレートを実行する、といった「他人のコードを自分のサーバーで動かす」場面で広く使われてきました。

やっかいなのは、自分が直接vm2を呼んでいなくても、取り込んでいる別の部品が内部でvm2を使っているケースが多いことです。これを「間接依存」と呼びます。テンプレート処理、ノーコードツール、オンラインのコード実行環境、設定ファイルの評価エンジンなどがvm2を内包していることがあり、「うちはvm2なんて使っていない」と思っていても依存関係をたどると奥で動いていることが珍しくありません。

2026年に入って急に関係者が増えたのが、AIエージェントの分野です。大規模言語モデルに生成させたコードをその場で実行する仕組みは、まさに「信用しきれないコードを安全に動かす」典型で、その隔離にvm2を使う実装が出回っています。セキュリティ企業のKodemは、この構図だとプロンプトインジェクション（AIへの不正な指示）からサーバー本体の乗っ取りまでが一直線につながると指摘しています。下の表のように、まずは自分の立場でどう関係するかを確認するのが出発点です。

立場・使い方	今回の関係	やること
外部のコードや数式を vm2で評価している	影響あり（最優先）	3.11.4へ更新し移行を検討
AIにコードを生成させ vm2内で実行している	影響あり（最優先）	即更新＋隔離方式の見直し
直接は使っていない（間接依存）	影響ありの可能性	依存関係を確認

逆に、vm2を信用できる自社コードの実行にしか使っていない（外部の入力を一切渡していない）場合は、今回の8件がそのまま攻撃に直結する可能性は低くなります。危険度は「誰が書いたか分からないコードをvm2に食わせているか」で大きく変わります。

8件の脆弱性の概要

8件はすべて「サンドボックスという隔離の壁」に関わる穴です。性質ごとに、サーバー本体での任意プログラム実行（乗っ取り）まで届くものと、壁の一部をすり抜けて通信や書き込みを許すものに分かれます。危険度の数字は、深刻さを0〜10で表す国際的な共通スコア「CVSS」です。まず一覧で全体像を押さえます。

番号	起きること	穴の正体	危険度
CVE-2026-47131	サーバー乗っ取り（脱出→任意実行）	本体側の型情報を奪って檻を破る	10.0
CVE-2026-47137	サーバー乗っ取り（脱出→任意実行）	過去の修正が条件指定で無効化	10.0
CVE-2026-47140	サーバー乗っ取り（脱出→任意実行）	遮断リストから危険機能が抜け	10.0
CVE-2026-47208	サーバー乗っ取り（脱出→コマンド実行）	Promiseの仕組み経由で脱出	10.0
CVE-2026-47210	サーバー乗っ取り（条件つき）	WebAssemblyの新機能経由で脱出	9.8
CVE-2026-47135	情報の流出など（壁の回避）	遮断すべき記号を取りこぼし	8.7
CVE-2026-47139	勝手な外部通信（壁の回避）	隠し名の通信機能が素通り	8.6
CVE-2026-47209	本体データの改ざん（壁の回避）	書き込み先の確認をしない	8.6

いずれも、攻撃の前提は「サンドボックスの中で攻撃者の用意したコードが動くこと」です。つまり、外部から受け取った文字列をvm2でそのまま実行している作りであれば、ログインなどの認証を経ずに、その入力経路から穴を突けます。8件のうち最高スコアの4件は、檻の中から本体側で何でも実行できる状態（乗っ取り）に直結します。

檻が破られると、何が誰の手に渡るのか

「サンドボックス脱出」という言葉は技術用語すぎて自分の損害が想像しづらいので、最高スコア10.0が現実に何を意味するかを攻撃者の側から見ておきます。vm2はそもそも「信用できないコードを動かす場所」なので、そこを破られるということは、最初から悪意あるコードを送り込める入口が用意されているのと同じです。

狙ってくるのは、採点サイトやコード実行サービスに偽の課題を投げる愉快犯、社内の自動化基盤に紛れ込もうとする産業スパイ、AIエージェントを言葉巧みに操って裏口を開かせる詐欺グループ、そして乗っ取ったサーバーへの入口を闇市場で売るアクセスブローカーです。彼らが持ち去るのは、サーバーに保存された顧客のメールアドレスやパスワード、クラウドの認証キー、データベースの中身、APIの秘密鍵、そして社内ネットワークへの足がかりです。今回のCVE-2026-47131やCVE-2026-47208を踏ませた瞬間、隔離されていたはずの檻の壁は消え、サーバー本体で攻撃者の好きなコマンドがそのまま走り出します。

特に2026年的な怖さは、AIエージェントを通した経路にあります。利用者が入力した文章をもとにAIがコードを書き、それをvm2の中で実行する設計では、攻撃者は直接コードを書く必要すらありません。チャット欄に細工した依頼文を入れてAIに危険なコードを生成させ、それがvm2で実行された瞬間に脱出が成立する、という流れです。コードを書く専門知識がなくても、言葉だけでサーバーの内側に手が届いてしまう点が、従来のサンドボックス脱出と決定的に違います。

そして被害の責任は、vm2の作者ではなく、それを組み込んだサービスの運営会社に返ってきます。顧客の個人情報が漏れれば個人情報保護委員会への報告と本人への通知が義務づけられ、規模次第で損害賠償と信用の失墜がのしかかります。CVSS 10.0という数字に、漏えい後の謝罪・調査・補償のコストは一切含まれていません。修正版が出ている今、依存関係を確認して手を打てるかどうかが、その分かれ目です。

サーバー乗っ取りに直結する4件（CVSS 10.0）

最高スコアの4件は、いずれも檻の中から本体側のプログラムを呼び出せてしまう「サンドボックス脱出」です。仕組みは少しずつ違いますが、共通しているのは「隔離のための壁に、ほんの一か所だけ本体側の機能が漏れ出す経路が残っていた」という点です。

CVE-2026-47131: 本体側の型情報を奪って脱出

JavaScriptには、値の種類が想定と違うときに出るエラー（型エラー）を作る仕組みがあります。CVE-2026-47131は、檻の中のコードがNode.js本体のエラー生成処理をうまく刺激することで、本来は触れないはずの本体側の部品（エラーを作るためのコンストラクタ）を手に入れ、それを足がかりに脱出します。スコアは満点の10.0で、成立すれば本体で任意のプログラムを実行できます。

CVE-2026-47137: 過去の修正がオプション指定の抜けで無効化

CVE-2026-47137は、2023年に直したはずの古い脆弱性（CVE-2023-37903）の修正が不完全だったために蘇った穴です。当時の修正は、ある設定項目が「きっかりfalseと書かれているか」を厳密に確認する作りでした。ところが、その項目自体を指定しなければ判定をすり抜けられるため、設定を一つ省くだけで脱出が成立します。一度直した穴が条件のわずかな抜けで再び開く、修正の難しさを示す典型例です。

CVE-2026-47140: 危険な機能の遮断リストに漏れ

vm2は、サンドボックスの中から触らせてはいけない危険な機能を「遮断リスト」で塞いでいます。CVE-2026-47140は、そのリストからプロセス操作機能（process）やデバッグ用機能（inspector）が抜け落ちていたために、檻の中からこれらに到達できてしまう穴です。塞ぐべき入口を一覧で管理する方式は、一つでも書き漏らせばそこが脱出口になるという弱点を抱えています。

CVE-2026-47208: Promiseの仕組みを悪用してコマンド実行

CVE-2026-47208は、非同期処理を扱うJavaScriptの仕組み「Promise」のふるまいを悪用して檻を破り、サーバー上で任意のコマンドを実行できる穴です。Promiseには、処理の結果を包む型を差し替えられる柔軟な仕掛けがあり、これを突かれると隔離の境界を越えて本体側へ手が伸びます。こちらも満点の10.0です。

壁を回避する残り4件（CVSS 9.8〜8.6）

残る4件は、即座の乗っ取りには届かないものの、隔離の壁の一部をすり抜けて外部通信や本体データの書き換えを許す穴です。単体では一段軽く見えても、ほかの穴と組み合わされると被害を広げる足場になります。

CVE-2026-47210: WebAssemblyの新機能を経由した脱出

CVE-2026-47210（9.8）は、非同期処理が有効で、かつWebAssembly（ブラウザやサーバーで高速にコードを動かす仕組み）の新しい連携機能「JSPI」がその環境で使える場合に、サーバー本体での任意コード実行に至る脱出です。発動には特定の実行環境という前提が必要なため、満点には一歩届かない9.8にとどまっています。

CVE-2026-47135: 遮断すべき特殊な記号の取りこぼし

CVE-2026-47135（8.7）は、本体と檻の境界をまたぐ特殊な記号（シンボル）のうち、遮断すべき9個中2個しか塞いでいなかったために残った穴です。残った記号を起点に本体側の処理を乗っ取る連鎖がつながります。攻撃の難度はやや高いと評価されていますが、成立すれば情報の流出や処理の改ざんに至ります。

CVE-2026-47139: 隠し名の通信機能を使った勝手な外部通信

CVE-2026-47139（8.6）は、外部通信を禁止する設定にしていても、アンダースコア付きの内部用の通信機能（_http_clientなど）が遮断対象から漏れていたために、檻の中から外向きの通信を出したり待ち受けたりできる穴です。サーバーを踏み台に内部ネットワークを探る、いわゆる踏み台化の足場になります。

CVE-2026-47209: 書き込み先を確認せず本体データを改ざん

CVE-2026-47209（8.6）は、檻の中と本体側でデータをやり取りする橋渡し処理が、書き込み先を正しく確認しないまま本体側のオブジェクトへ値を書き込んでしまう穴です。情報を読み取るわけではありませんが、本体側のデータを書き換えられるため、設定の改ざんや別の攻撃の準備に使われる恐れがあります。

本当の問題は、vm2がもう開発を終えていること

8件の修正版は出ていますが、最も大事なのは個々の穴ではなく、vm2という部品そのものの状態です。vm2のリポジトリには、作者自身による「このプロジェクトは終了した。安全なサンドボックスとして使い続けないでほしい」という明確な告知が掲げられています。これは、今後も同種の脱出が見つかり続ける前提で、もはやメンテナンスでは追いつかないという作者の判断です。

実際、vm2は2026年に入ってから脱出系の脆弱性が立て続けに公表されています。5月にも十数件規模の修正が行われ、今回の8件はその波の続きです。セキュリティ研究者がvm2の脱出手法を体系的に掘り下げており、新しい抜け道が次々に見つかる状況が続いています。根っこにあるのは、「同じプログラムの中で、本体と隔離領域を完全に分け切る」という設計の難しさです。JavaScriptは言語の仕組みが豊かなぶん、本体側へ通じる細い経路が無数にあり、一つ塞いでも別の経路が残りやすいのです。

そのため、信用できないコードを動かす用途では、vm2のようなライブラリ方式ではなく、より強い隔離方式へ移すのが現在の推奨です。具体的には、別プロセスとして完全に分離して動かすisolated-vmや、コンテナ（DockerなどでOSごと区切る方式）、専用のサンドボックス基盤などが挙げられます。今回の更新は時間を稼ぐための応急処置と位置づけ、移行計画を並行して進めるのが安全です。定番ほど「動いているから」と置き換えを後回しにしがちですが、開発が止まった部品をセキュリティの最前線で使い続けるのは、穴が開くたびに後手で塞ぎ続ける消耗戦になります。

自分のアプリは影響を受けるか（確認手順）

いま入っているバージョンは、プロジェクトのフォルダでnpm ls vm2と打つと確認できます。間接依存も含めて、どのバージョンが入っているかが一覧で出ます。下の表で自分の番号を照合してください。修正版は3.11.4です。

いま使っている版	状態	やること	優先度
3.11.3以前すべて	8件の影響あり	3.11.4へ更新＋移行を検討	高
3.11.4	今回の8件は対応済み	移行計画を進める	中
vm2を未使用	間接依存に注意	npm ls vm2で確認	—

間接依存で古いvm2が入っている場合は、それを呼んでいる親の部品の更新が必要になることもあります。npm ls vm2で「どの部品がvm2を連れてきているのか」を先に把握しておくと段取りが楽になります。自社の依存関係をまとめて点検したい場合は、貼り付けるだけで危険なバージョンを洗い出せるOSSの脆弱性チェックの仕組みを一度通しておくと、「気づけば奥に古いvm2が潜んでいた」を早めに拾えます。

いま取るべき対応

当座の手当てとして最も確実なのは、vm2を3.11.4へ更新することです。直接依存していればnpm install vm2@3.11.4で上げられます。間接依存の場合は、npm auditや脆弱性データベースで該当を確認し、親の部品の更新か、npmの上書き機能（overrides）で安全なバージョンを強制します。

そのうえで、信用できないコードをvm2で実行している場合は、更新と並行して隔離方式そのものの見直しに着手すべきです。外部から受け取った文字列をそのままvm2に渡している箇所を洗い出し、別プロセスやコンテナで隔離する設計へ寄せていきます。AIにコードを生成させて実行している仕組みでは、生成されたコードを実行する前に危険な命令を弾く検査を挟む、実行環境からネットワークやファイルへの到達を物理的に断つ、といった多層の防御を併用するのが現実的です。今のところ実際の攻撃は確認されていませんが、脱出手法はすでに公開・体系化されているため、修正の公開後は穴の場所がいっそう把握されやすくなります。先送りはそのまま危険の蓄積になります。

なぜ「他人のコードを動かす部品」は狙われ続けるのか

vm2のような部品は、その存在意義からして「信用できないものを受け入れる」場所にあります。だからこそ攻撃者の狙いが集中し、ひとつ穴が塞がれてもまた別の角度から試される、終わりのない攻防になります。利用者の多い定番ほど、コード自体の穴と、配布経路への攻撃の両面から狙われ続けるのは、ほかのnpmパッケージでも繰り返されてきた構図です。

直近でも、HTTP通信の定番axiosに認証情報が漏れる脆弱性が見つかり、別の機会には人気ライブラリの汚染版がVS Code拡張へ連鎖する事件も起きています。配布の仕組み側でも、npmが依存パッケージの自動実行を止める方向へ動いたのは、こうした流れと地続きです。

だからこそ、外から取り込む部品がどのバージョンで、既知の穴を抱えていないか、そして「そもそもまだメンテナンスされているのか」を継続的に点検する発想が要ります。vm2のように開発が終わった部品は、いくら更新しても次の穴が待っているだけです。使われている数の多さがそのまま被害の広さに直結する点を忘れず、定番だからこそ置き換えの判断を先送りにしないことが、今回の8件がいちばん強く突きつけている教訓です。