AIエージェントや自動化プラットフォームがモデルやユーザーの生成したコードを実行する機会が増える中、そのコードを取り巻くセキュリティ境界は重要性を増している。
Cyeraの研究者がDEF CON 34で発表した研究では、Pyodideを使用する7製品が、信頼できないコードを基盤となるホスト環境から完全には隔離できないPythonレベルの制限に依存していたことが判明した。
Cyeraの調査から得られた主なポイント
- 研究者らは7製品でPyodideのサンドボックス脱出を確認したところ、Pythonレベルの制限では、信頼できないコードを基盤となるホスト環境から完全には隔離できないことが分かった。
- この調査では、8.3～9.9と評価された4件のCVEが明らかになった。これには、接続された統合機能に関連する認証情報を露出させる可能性がある、n8nの重大な脆弱性も含まれる。
- サンドボックス脱出による潜在的な影響はホスト環境によって決まるため、API認証情報、ソースコード、署名鍵、内部サービス、データベースなど、その他の機密リソースが危険にさらされる。
- 組織は、信頼できないコードの実行に多層防御の対策を用いるべきだ。これには、独立した隔離、最小権限アクセス、ネットワーク制限、短期間のみ有効な認証情報、監視、定期的なインシデント対応テストが含まれる。
AIアプリケーションでPyodideのサンドボックスセキュリティが重要な理由
PyodideはWebAssembly（WASM）上でCPythonを実行し、ブラウザー、Node.js、DenoなどのJavaScript環境内でアプリケーションがPythonを実行できるようにする。
製品開発者は、次のような危険性のあるPythonモジュールを制限できる：osとsubprocessを制限することで、信頼できないコードを実行するためのサンドボックスのようなものを構築できる。
しかし研究者らは、テストした7製品すべての制限が、PythonのctypesモジュールとEmscriptenがエクスポートする関数を考慮していなかったことを突き止めた。
これにより、制限されているはずのPythonコードからJavaScriptホストランタイムへ至る経路が生じた。
この開示により4件のCVEが生じ、深刻度スコアは8.3～9.9だった。
根本的な問題は、特定の1アプリケーションに固有のものではなく、アーキテクチャに関するものだった。
WASMは自身の線形メモリを保護するが、ソフトウェアが組み込み環境によって意図的に公開された機能にアクセスすることまでは防げない。
テストした構成では、ctypesが引き続き利用可能で、関連するEmscripten関数を解決できた。
Pyodideのサンドボックス脆弱性の影響を受けた7製品
研究者らは、ワークフロー自動化、スプレッドシート、AIエージェントランタイム、デスクトップアプリケーション、継続的インテグレーション／継続的デリバリー（CI/CD）ツールで、関連するサンドボックス脱出を再現した。
最も深刻な発見の1つはCVE-2025-68668で、深刻度9.9と評価され、n8nに影響した。
n8nのCodeノードでは、Node.js上のPyodideを介してPythonを実行できた。
この回避により、攻撃者はn8nのサービスプロセスに到達し、接続された統合機能にひも付く認証情報へアクセスできる可能性があった。
これを受け、n8nはPythonコードの実行を外部ランナーに移し、コアサービスからさらに隔離した。
Pythonベースの数式に対応するオープンソースのスプレッドシート／データベースプラットフォームGristは、CVE-2026-24002の影響を受けた。この脆弱性のCVSSスコアは9.1だった。
AI生成コードを実行するサンドボックス環境であるCohereのTerrariumは、CVSSスコア9.3のCVE-2026-61522の影響を受けた。
コードを実行し外部ツールを利用できるAIエージェント構築フレームワーク、Hugging FaceのsmolagentsもCVE-2026-10613の影響を受け、CVSSスコア8.3と評価された。
この調査では、langchain-sandbox、stlite、cibuildwheelに関するセキュリティ上の懸念も明らかになった。
各プロジェクトのメンテナーの対応は分かれ、アーキテクチャを変更したもの、影響を受けたコンポーネントをアーカイブしたもの、適切な隔離はデプロイメントレベルで実施すべきだと主張したものがあった。
ホストランタイムがPyodideのサンドボックスセキュリティリスクを高める仕組み
Pyodideからの脱出は、セキュリティ上の要素の一部にすぎなかった。研究者らは、ホストランタイムと周辺環境が潜在的な影響を決めると強調した。
例えば、Node[.]jsのプロセスは、ファイルシステム、プロセス、環境のAPIを公開する可能性がある。
Denoは明示的な権限を使用し、ファイルシステム、ネットワーク、サブプロセスへのアクセスなどの機能を制限できる。
CI/CD環境では、サンドボックス脱出により、公開用トークン、署名鍵、独自のソースコード、リリース成果物などの機密資産が露出する可能性がある。
AIエージェント環境にも同様のリスクがあり、攻撃者がAPI認証情報、内部サービス、データベース、接続されたツール、顧客の機密データにアクセスできる可能性がある。
多層防御の対策でPyodideを保護する方法
今回の発見は、Pythonのインポート制限を完全なセキュリティ境界と見なすべきではない理由を示している。
製品チームは、不要なctypes機能を制限し、モジュールの許可リストを優先して、不要なEmscriptenエクスポートを削除し、ホストランタイムの権限を最小限に抑えるべきだ。
信頼できないコードも、別プロセスやコンテナなど、独立した隔離境界の背後で実行すべきである。
影響を受けたフレームワークを使用している組織は、修正済みバージョンにアップグレードするか、ベンダーが推奨する緩和策を適用すべきだ。
個々の脆弱性に対処するだけでなく、サンドボックスが回避された場合に攻撃者がアクセスできる範囲を制限する多層防御の対策を実装すべきである。
- 最小権限アクセスを徹底し、信頼できないコードを実行するワークロードには、専用のサービスアカウントと範囲を厳格に限定した権限を使用する。
- 制限外向きネットワークアクセスを制限し、侵害されたワークロードが不要な内部サービスに到達したり、機密データを外部へ持ち出したりするのを防ぐ。
- 短期間のみ有効なワークロード固有の認証情報を使用し、サンドボックス環境に長期間有効なシークレットを公開しない。
- 機密性の高いCI/CD機能と認証情報を分離し、ビルド、署名、公開、本番環境へのアクセスなどを分けることで、パイプラインのステージが侵害された場合の影響を抑える。
- ファイルシステムとホストへのアクセスを制限し、読み取り専用マウント、最小限のホスト権限、ワークロードに必要なリソースへのアクセスだけを使用する。
- 一時的なコンテナまたは隔離されたプロセスを使用し、信頼できないワークロードの実行後に環境を破棄できるようにして、永続的なアクセスや状態を維持しない。
- サンドボックス化されたワークロードを監視して不審な挙動を検出し、予期しないプロセスの作成、ネットワーク接続、ファイルアクセス、権限昇格の試みなどを確認する。
- サンドボックス脱出とインシデント対応のシナリオを定期的にテストし、攻撃シミュレーションツールを使って、チームが侵害されたワークロードを封じ込め、アクセスを無効化し、露出した認証情報を速やかにローテーションできることを検証する。
こうした対策を重ねることで、サンドボックス脱出が成功する可能性と、隔離機構が機能しなかった場合の潜在的な被害範囲の両方を抑えられる。
結論
今回の調査は、AIセキュリティに関するより広範な教訓を示している。サンドボックスの強度は、その下にある境界の強度にすぎない。
AIシステムがコードを実行し、機密性の高いリソースとやり取りする権限を強める中、組織はインタープリター内部でコードが呼び出せるものだけでなく、インタープリターレベルの境界が破られた場合にコードが到達できる範囲も保護しなければならない。
1つのゼロトラストアーキテクチャは、アクセスを継続的に検証し、最小権限を徹底し、侵害されたAIワークロードが広範な環境内で到達できる範囲を制限することで、こうした境界の強化に役立つ。