DEF CON 34: Pyodideの単一アーキテクチャ上の欠陥が7製品に影響

AIエージェントや自動化プラットフォームがモデルやユーザーによって生成されたコードを実行する機会が増えるにつれ、そのコードを取り巻くセキュリティ境界が極めて重要になっています。 

Cyeraの研究者Vladimir Tokarev氏とSaar Pearl氏がDEF CON 34で発表した研究によれば、Pyodideを利用する7つの製品はPythonレベルの制限に依存していたものの、これらの制限は信頼できないコードを基盤となるホスト環境から完全に隔離するものではなかったことが判明しました。

Cyeraの研究から得られる重要なポイント

• 研究者らは7つの製品にわたってPyodideサンドボックスの回避手法を特定し、Pythonレベルの制限では信頼できないコードを基盤ホスト環境から完全に隔離できていないことを明らかにしました。
• この研究の結果、CVSSスコア8.3から9.9に及ぶ4件のCVEが発行されました。その中には、連携する統合サービスに紐づく認証情報が漏えいする恐れのある、深刻度の高いn8nの脆弱性も含まれています。
• サンドボックス回避の潜在的な影響度合いはホスト環境によって決まり、APIの認証情報、ソースコード、署名鍵、内部サービス、データベースなど、機密性の高いリソースが危険にさらされる可能性があります。
• 組織は信頼できないコードの実行に対して多層防御の対策を講じるべきであり、独立した分離環境、最小権限アクセス、ネットワーク制限、短命な認証情報、監視、そして定期的なインシデント対応訓練などが求められます。

Pyodideのサンドボックスセキュリティがなぜ重要なのか 

PyodideはCPythonをWebAssembly(WASM)上で動作させる技術であり、ブラウザやNode.js、Denoといったアプリケーションが、JavaScript環境の内部でPythonを実行できるようにします。 

製品開発者はosやsubprocessなど、潜在的に危険なPythonモジュールを制限することで、信頼できないコードを実行するためのサンドボックスとして見えるものを構築できます。

しかし研究者らの調査によれば、検証対象となった7製品すべてにおいて、この制限はPythonのctypesモジュールやEmscriptenがエクスポートする関数を考慮していなかったことが判明しました。 

これにより、本来は制限されているはずのPythonコードから、JavaScriptのホストランタイムへと至る経路が生まれていました。 

この一連の情報開示により、CVSSスコアが8.3から9.9に及ぶ4件のCVEが発行されています。

根本的な問題は特定のアプリケーションに固有のものではなく、アーキテクチャ上のものでした。 

WASMは自身の線形メモリを保護しますが、組み込み先の環境が意図的に公開している機能へのアクセスまでは防げません。 

今回検証された構成では、ctypesが引き続き利用可能な状態にあり、関連するEmscripten関数を解決できてしまう状態でした。

Pyodideのサンドボックス脆弱性の影響を受けた7製品 

研究者らは、ワークフロー自動化ツール、スプレッドシート、AIエージェントのランタイム、デスクトップアプリケーション、そしてCI/CD(継続的インテグレーション/継続的デリバリー)ツールにわたって、関連するサンドボックス回避手法を再現しました。

最も深刻な発見の一つが、n8nに影響するCVE-2025-68668(深刻度9.9)です。 

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システムがコードを実行し、機密性の高いリソースとやり取りする権限をますます強めていく中で、組織はインタープリタ内部でコードが呼び出せる範囲だけでなく、そのインタープリタレベルの境界が破られた場合にコードが到達しうる範囲についても、セキュリティを確保しなければなりません。

ゼロトラストアーキテクチャは、アクセスを継続的に検証し、最小権限を徹底し、侵害されたAIワークロードが到達できる範囲をより広い環境全体にわたって制限することで、こうした境界の強化に役立ちます。