はじめに：なぜフロントエンドエンジニアも知るべきか

Node.js環境でセキュアなコード実行を実現するためのサンドボックスライブラリ`vm2`に、深刻度`critical`の脆弱性（CVE-2026-92957 / GHSA-8686-vhfx-7r3j）が報告されました。この脆弱性は、サンドボックス環境の境界を突破し、ホスト環境の`child_process`のような危険なモジュールへのアクセスを許してしまうものです。

フロントエンドエンジニアの皆さんは、直接`vm2`をアプリケーションで利用する機会は少ないかもしれません。しかし、Node.jsベースのバックエンドサービス、ビルドツール、テスト環境、CI/CDパイプラインなどでNode.jsが使われている場合、この脆弱性は間接的にあなたの開発環境や本番サービスに影響を及ぼす可能性があります。この記事では、脆弱性の技術的な詳細と、取るべき対策について解説します。

vm2とは？Node.jsサンドボックスの役割

`vm2`は、Node.js上で信頼できないコードを隔離された安全な環境（サンドボックス）で実行するためのライブラリです。悪意のあるコードがファイルシステムへのアクセス、ネットワーク通信、OSコマンド実行など、ホストシステムに不適切な操作を行うのを防ぐことを目的としています。例えば、ユーザーが提供するカスタムスクリプトを実行するようなサービスで利用されます。

CVE-2026-92957 / GHSA-8686-vhfx-7r3j の概要

この脆弱性は、`vm2`の`NodeVM`モードにおいて、Node.jsの組み込みモジュールに対するアクセス制御の不備が原因で発生します。具体的には、サンドボックス内のコードが、本来アクセスを拒否すべき`child_process`などのモジュールにアクセスできてしまう問題です。これにより、サンドボックスの境界が突破され、ホストシステム上で任意のコマンドを実行されるなど、非常に深刻な結果を招く可能性があります。

深刻度は`critical`に分類されており、迅速な対応が求められます。

技術的詳細：なぜサンドボックスが突破されたのか？

脆弱性の根底にあるのは、`vm2`が`node:`プレフィックスを持つ組み込みモジュール名の扱いにおいて、内部で不整合を起こしていた点です。

Node.jsでは、組み込みモジュールを`require('child_process')`のように参照するほかに、`require('node:child_process')`のように`node:`プレフィックスを付けて参照することも可能です。`vm2`は`require()`の解決時に`node:`プレフィックスを内部的に正規化して扱います。

しかし、組み込みモジュールのアクセスを拒否するポリシー（`builtin`オプション）を設定する際、ユーザーが`'-node:child_process'`のように`node:`プレフィックスを付けて拒否リストに追加した場合、`vm2`の`lib/builtin.js`内の処理は、このエントリを正規化せずにそのまま`'-node:child_process'`という文字列として扱っていました。一方で、Node.jsの組み込みモジュールリストには`child_process`という正規名しか含まれていません。

結果として、`builtin: ['*', '-node:child_process']`という設定は、正規名である`'child_process'`を拒否するエントリとして認識されず、サンドボックス内のコードから`require('child_process')`または`require('node:child_process')`が成功し、ホストの`child_process`モジュール（`execSync`や`spawn`などの危険なAPIを含む）にアクセスできてしまう状態でした。

具体的な影響

この脆弱性が悪用された場合、サンドボックスで実行されるはずの信頼できないコードが、以下の操作をホストシステム上で実行できるようになります。

- `require('child_process')`や`require('node:child_process')`による`child_process`モジュールのロード成功。

- ロードされたモジュールを通じて、`execSync`、`spawn`などの関数を利用したOSコマンドの実行。

これは、サンドボックスが提供するセキュリティ境界の完全な突破を意味し、攻撃者がホストシステム上で任意のコードを実行できることと同義です。機密情報の窃取、システムの改ざん、サービス停止など、最悪のシナリオではシステム全体が危険に晒される可能性があります。

フロントエンド開発における潜在的なリスク

直接`vm2`を使用しない場合でも、以下のようなシナリオで間接的な影響を受ける可能性があります。

- **Node.jsバックエンド**: Next.js、Nuxt.jsなどのSSRフレームワークやAPIサーバーとしてNode.jsを使用している場合、バックエンドで`vm2`を利用してユーザーコードを実行しているサービスがあれば、攻撃対象となる可能性があります。

- **ビルドツール・CI/CD**: 特定のシナリオで、信頼できないプラグインやスクリプトをサンドボックス環境で実行するビルドツールやCI/CDパイプラインが`vm2`を利用している場合、脆弱性が悪用される可能性があります。

- **開発環境・テスト環境**: 開発中のカスタムスクリプトやサードパーティ製ツールで`vm2`が利用されている場合、開発環境のセキュリティリスクが高まります。

ご自身のプロジェクトや依存関係に`vm2`が存在しないか、また`vm2`に依存するライブラリがないかを確認することが重要です。

対策：速やかなアップデートと設定の見直し

この脆弱性に対する最も重要な対策は、`vm2`ライブラリを速やかに最新バージョンにアップデートすることです。最新バージョンでは、この問題が修正されています。

また、アップデートに加えて、`builtin`オプションで組み込みモジュールのアクセスを拒否する設定を見直す必要があります。`node:`プレフィックスに依存せず、常にCanonical Name（正規名）で指定するようにしてください。例えば、`child_process`モジュールを拒否する場合は、以下のように設定します。

- **安全な設定例**: `builtin: ['*', '-child_process']`

これにより、`require('child_process')`と`require('node:child_process')`の両方が正しく拒否されるようになります。他の組み込みモジュールについても、同様にCanonical Nameでの指定を徹底してください。

まとめ

`vm2`におけるこの致命的な脆弱性は、サンドボックスの最も重要な役割であるセキュリティ境界を無効化するものです。Node.jsを使用するプロジェクトにおいては、バックエンドエンジニアだけでなく、フロントエンドエンジニアも依存関係を把握し、最新のセキュリティ情報を追跡することが不可欠です。速やかなライブラリアップデートと設定の見直しを行い、サービスの安全性を確保しましょう。