はじめに：NodeVMのサンドボックス機能と今回の脆弱性

皆さんが開発現場でNode.jsを利用している際、外部から提供された信頼できないコードやユーザーがアップロードしたスクリプトを安全に実行する必要がある場合、NodeVMのようなサンドボックスライブラリの利用を検討することがあります。NodeVMは、隔離された仮想環境を提供することで、危険な操作（ファイルシステムへのアクセスやネットワーク通信など）を制限し、メインシステムへの影響を防ぐことを目的としています。

今回報告されたGHSA-r9pm-gxmw-wv6p（CVE-2026-47139）は、このNodeVMのサンドボックス機能に深刻な脆弱性があることを示しています。具体的には、ネットワーク通信を禁止する設定をしていても、Node.jsの特定の「隠れた内部モジュール」を通じて、外部へのHTTPリクエストが可能になってしまうというものです。これにより、攻撃者がシステム内部への不正アクセス（SSRF）を試みることが可能となり、非常に危険な状況を招く可能性があります。

脆弱性の技術的詳細：隠れた内部モジュールの脅威

NodeVMは、通常、サンドボックス内で`require('http')`や`require('https')`といった標準的なネットワーク関連モジュールへのアクセスをブロックする機能を提供しています。しかし、Node.jsには`_http_client`や`_http_server`のように、モジュール名がアンダースコア（`_`）で始まる内部的なネットワークモジュールが存在します。これらは通常、Node.jsのコア機能で利用されるものであり、一般の開発者が直接利用することは稀です。

今回の脆弱性の問題点は、NodeVMのモジュールブロック機能が、これらのアンダースコア付き内部モジュールを見落としていたことにあります。そのため、サンドボックス内で実行される信頼できないJavaScriptコードが、たとえ標準の`http`モジュールがブロックされていても、`require('_http_client')`のように直接内部モジュールを読み込むことで、外部へのHTTPリクエストを送信したり、HTTPサーバーソケットを開設したりすることが可能になってしまいました。これは、本来意図しないネットワークアクセスを許してしまう状態です。

具体的に影響を受ける可能性のある内部モジュールとしては、以下のものが挙げられます（これらに限定されません）：

`_http_agent`, `_http_client`, `_http_common`, `_http_incoming`, `_http_outgoing`, `_http_server`, `_tls_common`, `_tls_wrap`

影響を受けるシステムとSSRF攻撃のリスク

この脆弱性は、NodeVMをサンドボックス環境として使用し、外部へのネットワークアクセスを禁止する設定にしているアプリケーションに影響します。特に、脆弱性がある`vm2`のバージョン（例: `vm2: 3.11.2`）を使用している場合に確認されています。

攻撃者は、この脆弱性を利用することで「Server-Side Request Forgery (SSRF)」攻撃を仕掛けることができます。SSRFとは、サーバーを踏み台にして、本来アクセスできないはずの内部システムや外部リソースへリクエストを偽装して送信する攻撃です。これにより、以下のような深刻なリスクが発生します。

<ul><li>**内部システムの調査・アクセス**: `localhost`上で動作する管理パネルやAPI、イントラネット内のサービスへのアクセス。</li><li>**クラウドサービスのメタデータエンドポイントへのアクセス**: AWS EC2のメタデータサービスなどから、機密情報（一時的な認証情報など）が漏洩する可能性。</li><li>**社内APIやデータベースへの不正操作**: 許可されていないAPI呼び出しやデータ操作。</li></ul>

この脆弱性は、ホスト自体へのリモートコード実行（RCE）には直結しませんが、内部ネットワークリソースへの不正アクセスは、情報漏洩やシステム乗っ取りの足がかりとなる極めて深刻なセキュリティリスクと見なされます。

フロントエンドエンジニアが今すぐ取るべき対策

NodeVMを利用しているシステム開発に携わっている場合は、以下の対策を速やかに実施してください。

最も根本的かつ推奨される対策は、使用している`vm2`ライブラリを、この脆弱性が修正された最新バージョンにアップデートすることです。通常、最新バージョンでは脆弱性が修正されており、基本的な対策はこれで完了します。`npm update vm2`や`yarn upgrade vm2`を実行し、`package.json`の依存関係も適切に更新してください。

最新版へのアップデートがすぐに困難な場合や、追加のセキュリティレイヤーとして、以下のNode.js内部ネットワークモジュールをNodeVMのブロックリストに明示的に追加することを強く推奨します。これにより、これらのモジュールへのアクセスも確実に禁止されます。

NodeVMの設定で、以下のように`builtin`オプションにブロックしたいモジュールを追加します。

`const { VM } = require('vm2');`

`const vm = new VM({`

` timeout: 1000,`

` sandbox: {},`

` // 危険な内部モジュールを明示的にブロック`

` builtin: ['_http_agent', '_http_client', '_http_common', '_http_incoming', '_http_outgoing', '_http_server', '_tls_common', '_tls_wrap', 'http', 'https'],`

`});`

NodeVMのワイルドカードを使った組み込みモジュールの許可設定（例: `builtin: ['*']`）を使用している場合、アンダースコア付きのNode.js内部モジュールをデフォルトで除外するような設定変更も有効です。セキュリティを最大化するためには、本当に必要なモジュールのみを許可する「ホワイトリスト」方式を採用することが最も安全です。

また、定期的に依存関係の脆弱性スキャン（例: `npm audit`やGitHubのDependabotなど）を実行し、使用しているライブラリに新たな脆弱性が発見されていないかチェックする習慣をつけることも重要です。

まとめ

NodeVMのSSRF脆弱性は、サンドボックス環境の基本的なセキュリティを脅かす深刻な問題です。フロントエンドエンジニアの皆さんにとって、Node.jsのランタイムが関わる脆弱性は、ビルドプロセスやサーバーサイドレンダリング（SSR）、APIレイヤーなどで間接的に影響する可能性があります。この機会に、ご自身のプロジェクトでNodeVM（またはそれに類するサンドボックスライブラリ）がどのように利用されているかを確認し、上記対策を迅速に実施することで、システムを潜在的な攻撃から保護しましょう。