- Terrariumは、PyodideをベースとしたPythonサンドボックスであり、Cloud Runにデプロイ可能です。低コストかつ許容範囲内のレイテンシーで、信頼性の低いコードを実行できるように設計されています。
- この環境は、呼び出しベースのコンパートメント化、複数の科学ライブラリのサポート、および仮想ファイルシステムを介した入出力ファイルの処理を提供します。
- そのアーキテクチャは、WebAssembly、Node.js、Docker、Cloud Runを組み合わせてコードを分離しているが、安定性やサービス健全性管理に関する問題が検出されている。
- 重大な脆弱性CVE-2026-5752は、root権限でのコード実行を可能にするものであり、パッチの提供予定がないため、対策や代替策を検討することをお勧めします。
信頼できないPythonコードやAIが生成したPythonコードを実行する場合、最大の課題の一つは、それを安全かつ迅速に、そしてインフラコストを抑えて行う方法です。このような背景から生まれたのが、Cohere AIが開発したTerrariumです。Terrariumは、クラウド、特にGoogle Cloud Runにデプロイされたコンテナ内で、このようなコードをホストおよび実行するためのサンドボックスとして設計されています。
このアプローチにより、開発者や企業は、Terrariumを隔離された環境として活用し、ユーザーコードやLLMモデルをリーズナブルなコストと良好なパフォーマンスでデプロイすることが可能になりました。しかし、時が経つにつれ、非常に深刻な脆弱性も明らかになり、その中にはCVE識別子を持つ脆弱性もあり、サンドボックスのセキュリティにおける重大な欠陥を露呈し、Terrariumが注目を集めることになりました。
テラリウムとは何ですか？また、どのような目的で設計されたのですか？
Terrariumは、基本的にPython用の隔離されたランタイム環境であり、例えばGoogle Cloud Runなどの上でデプロイ可能なDockerコンテナとして機能するように設計されています。その主な目的は、潜在的に危険なコードや未知のコード（ユーザーが投稿したスクリプトや言語によって生成されたコードスニペットなど）を、メインのインフラストラクチャを直接危険にさらすことなくデプロイできるサンドボックスを提供することです。
このプロジェクトの理念は、既存のワークフローに簡単に統合できる、手頃な価格で低遅延のサービスを提供することにあります。TerrariumはHTTPリクエストを介して呼び出されるように設計されており、実行するPythonコード（オプションで入力ファイルも含む）を送信し、実行結果と生成されたファイルを受け取ります。
実際には、これは外部システム、API、あるいは内部ツールがPythonコードの実行をTerrariumに委任し、リソース、実行時間、および許可される機能に関する明確なルールを備えた比較的限定された環境内でそのコードを実行できることを意味します。
Terrariumの重要な設計上の特徴の一つは、 Node.jsプロセス内で実行されるCPythonからWebAssemblyへのビルドツールであるPyodideに依存している点です。このアプローチにより、Pythonコードはホストシステム上でネイティブに実行されるのではなく、カプセル化されたインタープリタ内で実行されるため、理論的には分離性が強化されます。
サンドボックスのパフォーマンス、コスト、および主な機能
Terrariumの最大のセールスポイントの一つは、運用コストの低さと許容範囲内のパフォーマンスを両立させている点でした。Google Cloud Run上での実際のデプロイメントでは、メモリ2GB、vCPU 1、オンデマンド自動スケーリングを備えた常時稼働インスタンスが少なくとも1つという一般的な構成で、内部アノテーションフェーズにおける月額コストは約30ドルでした。
速度に関して言えば、テスト結果によると、Terrariumは例えば、シンプルなmatplotlibプロットの200dpi PNG画像を約900ミリ秒で生成でき、SVG版であれば約500ミリ秒で生成できることが示されています。これらの時間は、Cloud Run上でホストされているコード（サービスの一般的な呼び出しサイクルを含む）に基づいています。
Terrariumは、パフォーマンスに加えて、呼び出し間の完全な分離も特長としていました。呼び出しごとにサンドボックスは完全にリサイクルされ、Pyodideの仮想ファイルシステム、グローバル変数、ロードされたライブラリ、およびすべての内部状態が破棄されました。これは、呼び出しが以前の実行からデータやコンテキストを継承することを防ぎ、情報漏洩のリスクを低減することを目的としていました。
もう一つ重要な点は、Cohereは堅牢な隔離を目指していたものの、サンドボックスの完全性に関して絶対的な保証は提供していないことを明確にした点です。これは、幾重にも保護層を設けているにもかかわらず、特にWebAssemblyやNode.jsとの統合といった複雑な環境では、脆弱性が発見される可能性があることを示唆していました。
Terrariumは、他のサービスから簡単に利用できるように設計されています。Cloud Runにデプロイされたエンドポイントに、実行するコードと認証トークン（設定で必要な場合）を添えてHTTPリクエストを送信するだけで済みます。すると、結果を含むJSONファイルと、該当する場合は生成されたファイルがbase64エンコードされて返されます。
Pyodideにおけるファイル実行とライブラリのサポート
Terrariumの魅力的な機能の一つは、入力ファイルと出力ファイルをネイティブに扱えることでした。APIでは、リクエストにPythonコードとともに任意の種類の複数のファイルを添付することができ、これらのファイルはPyodideがPythonインタープリタに公開する仮想ファイルシステムに配置されました。
実行中、Pythonコードはこれらのファイルをサンドボックス内のローカルファイルであるかのように読み取り、操作できます。実行が完了すると、Terrariumは作成または変更されたすべてのファイルを収集し、通常はHTTP経由でのシームレスな転送のためにエンコードされた状態で、クライアントへのレスポンスとして返します。
ライブラリのエコシステムに関して言えば、Pyodideをベースとしているため、Terrariumはかなり広範な科学計算およびデータ分析パッケージを継承しています。直接サポートされているパッケージには、numpy、pandas、matplotlib、sympy、beautifulsoup4、python-sat、scikit-learn、scipy、sqlite3などがあります（後者はデフォルトでは有効になっていませんが、必要に応じてロードするオプションがあります）。
matplotlib の場合、いくつかの制限がありました。plt.show() はこの環境ではサポートされていませんでしたが、plt.savefig() を使用して画像を生成することは、リソース使用量を増加させるような極端に高い解像度などの過剰なパラメータを強制しない限り、正しく機能しました。
このライブラリ群のおかげで、Terrariumはデータ分析、可視化、機械学習モデルのプロトタイピング、構造化情報の操作といったタスクに特に役立ち、それらはすべて理論的に制御されたサンドボックス内で実行される。
内部アーキテクチャ：分離と展開のレイヤー
Terrariumのアーキテクチャは、攻撃対象領域を縮小し、信頼できないコードを可能な限り隔離するように設計された複数のレイヤーで構成されています。最初のレイヤーはNode.jsプロセス自体であり、ホストとして機能し、Pyodide（WebAssemblyにコンパイルされたCPython）をロードします。
ユーザーが送信したPythonコードは、ホストシステム上でネイティブに実行されるのではなく、 WebAssembly環境内で解析、コンパイル、実行されます。Pyodideはメモリ上の仮想ファイルシステムを使用し、ホストディスクへの直接アクセスができず、従来のバックグラウンド処理機能も備えていないため、この方式ではコードが実行できる範囲が本質的に制限されます。
最も重要な制限事項としては、実際のファイルシステムへのアクセスがないこと（Pyodideの内部仮想ファイルシステムのみ）、スレッド処理とマルチプロセス処理が完全に欠如していること、サブプロセスを起動できないこと、Node.jsを実行しているホストのメモリにアクセスできないこと、呼び出し間で状態を共有できないこと（環境全体が再起動されるため）、そして設計上、ネットワークやインターネットにアクセスできないことなどが挙げられます。この最後の制限は、将来的に見直される可能性のある設計上の決定として意図されていましたが、当初は新たな論争の種となりました。
2つ目の分離層は、クラウドデプロイメントそのものです。Node.jsプロセスはDockerコンテナ内で実行され、そのコンテナはGoogle Cloud Runにデプロイされます。これにより、実行時間と利用可能なリソースが制限されるだけでなく、万が一サンドボックスが侵害された場合でも、コードを実行するコンテナが組織のインフラストラクチャの他の部分から切り離されます。
要約すると、Terrariumの本来の設計は、 WebAssembly、Docker、Cloud Runを組み合わせて、Python実行のための比較的安全な環境を構築することに依存しており、サンドボックスからホストシステムや内部ネットワークへの脱出を困難にする一連の障壁が設けられている。
ローカルデプロイ、Dockerデプロイ、およびGoogle Cloud Runデプロイ
Terrariumを開発環境で使用するには、マシンにNode.jsがインストールされている必要がありました。その要件を満たした後は、プロジェクトの依存関係をインストールし、ローカルサーバーとコード実行要求を処理する関数を起動するという通常の手順で作業を進めました。
サーバーが稼働している状態で、ローカルエンドポイントにテストファイルやPythonスクリプトを送信するリクエストを送信することで、開発者は本番環境にデプロイする前にサンドボックスの動作を検証できます。テストディレクトリ内のすべての.pyファイルに対して一連のテストを実行するスクリプトも用意されており、環境検証が簡素化されます。
コンテナ化された環境では、TerrariumはDockerイメージとして構築され、スタンドアロンコンテナとして実行できます。一般的な手順には、構築、実行、停止の各ステップに加え、実行中のコンテナの識別子を特定し、必要に応じて手動で管理するためのコマンドが含まれています。
TerrariumがGoogle Cloud Runに移行した際、リソースと同時実行数のパラメータを構成可能なオートスケーリングHTTPサービスとしてデプロイされました。パフォーマンス、コスト、セキュリティのバランスを取るために、これらの値を調整することが推奨されました。例えば、負荷の高いワークロードの場合、より多くのCPUとメモリを割り当て、インスタンスごとの同時実行数を制限してブロッキングを防ぐことができます。
PyodideはTerrarium用に構成すると、メインのNode.jsプロセスで実行されることに注意が必要です。つまり、Pythonコードが特にリソースを大量に消費したり、複雑なループに陥ったりすると、Node.jsが他のリクエストに応答できなくなる可能性があります。Pyodideは、実行を中断したり、さらに分離したりする必要がある場合はWorkersを使用することを推奨していますが、この方法は統合を複雑にし、場合によってはmatplotlibなどのライブラリのサポートを制限する可能性があります。
医療サービス管理と安定性の問題
Google Cloud Run でのデプロイメントにおいて、実務上の課題の 1 つは、サービスの健全性を監視し、クラッシュから復旧することでした。Cloud Run はデフォルトでは、HEALTHCHECK を使用して Dockerfile で定義されたヘルス チェックを直接サポートしていないため、若干の追加調整が必要でした。
通常の手順では、gcloud コマンドを使用して Cloud Run サービスを定義し、その設定を service.yaml ファイルにエクスポートします。その YAML ファイル内に、コンテナ イメージに関連付けられた livenessProbe 設定を追加することで、Cloud Run がサービスが正常に応答しなくなったことを検出できるようにします。
設定が変更されると、既存のサービスは適切なgcloudコマンドに置き換えられ、Cloud Runがコンテナの状態をアクティブに監視し、ライブチェックが失敗した場合は再起動するようになりました。この操作は、特定のイメージを使用して新しいサービスを初めてデプロイする場合にのみ必要でした。
純粋なDockerレベルでは、さらに別の制限があります。Dockerエンジン自体は、HEALTHCHECKのみに基づいて自動再起動を提供する機能を備えていません。さらに、コンテナ内のPID 1のプロセスは特に保護されており、内部から簡単に終了させることはできません。そのため、一部の環境では、コンテナの状態を監視し、問題が検出された場合に強制的に再起動を行うdocker-autohealなどのサードパーティツールの使用が検討されています。
実行の安定性に関して、チームは、特に負荷の高いワークロードを処理する際に、Pyodide内で「RangeError: Maximum call stack size exceeded」などのエラーが頻繁に発生することを確認しました。これは、matplotlibを使用したPNG生成時に非常に高いdpi値を使用した場合や、特に複雑なpandas操作を実行した場合に多く発生しており、WebAssembly環境におけるスタック管理の内部的な制限を示唆しています。
Terrariumにおける重大な脆弱性CVE-2026-5752
時間の経過とともに、Terrariumに重大な脆弱性が発見されました。これはCVE-2026-5752として識別され、CVSSスケールで9,3と評価されています。この深刻度は、このサンドボックスを使用するシステムのセキュリティに非常に大きな影響を与える可能性のある欠陥であることを示しています。
この脆弱性により、攻撃者はホストプロセス内でroot権限で任意のコードを実行できます。攻撃手法は、Pyodide WebAssembly環境内での悪意のあるプロトタイプチェーンのトラバーサルに依存しており、サンドボックスの制限を効果的に回避します。
最も懸念される点は、この脆弱性を悪用するのに特別な権限や追加のユーザー操作が一切必要ないことです。サンドボックスにコードを注入できる攻撃者（例えば、Terrariumを使用するツールのコード実行機能を悪用するなど）は、この欠陥を利用して制御された環境から脱出することができます。
この脆弱性が悪用されると、/etc/passwdなどの機密性の高いシステムファイルやその他の内部コンテナリソースへの不正アクセスが可能になり、全体的なセキュリティ構成によっては、ホストや同じインフラストラクチャを共有する他のサービスへの権限昇格も可能になる場合があります。
この状況は、ユーザーコードまたはAIモデルの実行環境としてTerrariumを使用しているすべての組織にとって重大なリスクとなります。これは単なる理論上の脆弱性ではなく、サンドボックスの侵害によってデータ漏洩、内部サービスの侵害、ネットワーク内での横方向の移動につながる可能性のあるシナリオです。
企業、開発者、エンドユーザーへの影響
この脆弱性の発見は、信頼できないPythonコードを実行するためにTerrariumをインフラストラクチャに統合しているすべての企業や開発者に直接的な影響を与えます。共同開発ツール、学習プラットフォーム、オンデマンド分析サービス、またはAIベースのコード支援製品が、ランタイムレイヤーとしてTerrariumを使用している場合、脆弱性にさらされる可能性があります。
エンドユーザーの視点から見ると、リスクはサービスプロバイダーのインフラストラクチャが侵害される可能性だけでなく、攻撃者が脆弱性を悪用した場合、それらのプラットフォームに保存されている個人情報や業務情報が事前の通知なしに漏洩または改ざんされる可能性もある。
さらに事態を複雑にしているのは、Terrariumがもはや積極的にメンテナンスされていないという事実です。つまり、問題を修正する公式パッチが提供される見込みはなく、このソリューションに依存し続ける組織は、既知の脆弱性を抱えたままサポートを受けられない状況に置かれることになります。
このような状況下では、追加対策を講じることなくTerrariumを使い続けることは、重大なセキュリティリスクを伴います。攻撃者は、この脆弱性を認識している場合、この技術を使い続けているサービスを標的にし、システム全体のセキュリティ上の弱点を探し出す可能性があります。
さらに、複数のサービスが同じ内部ネットワーク、あるいは同じコンテナクラスタを共有している環境では、Terrariumからの情報漏洩が、一見孤立しているように見える他のシステムへの横方向の移動を招き、攻撃が成功した場合の潜在的な影響を増幅させる可能性があります。
検討すべき緩和策と代替案
これほどの脆弱性があり、かつ積極的なメンテナンスが行われていない現状を踏まえ、組織がまず最初に行うべきことは、Terrariumの現在の利用状況を緊急に評価することです。サードパーティ製のコードやAIモデルによって生成されたコードを実行するためにTerrariumを使用している場合、リスクはさらに高まるため、直ちに対策を講じる必要があります。
短期的な対策としては、より安全な代替策を評価する間、本番環境で任意のコード実行を可能にする機能を一時的に無効化することが挙げられます。その他の選択肢としては、ネットワークポリシーの強化、Terrariumを使用するサービスのさらなるセグメンテーション、および他のシステムからのコンテナへのアクセス制限などがあります。
中期的には、積極的なメンテナンスが行われ、脆弱性のパッチ適用を支援するコミュニティやプロバイダーが存在する、他のサンドボックスまたは隔離実行ソリューションに移行する方が賢明かもしれません。これには、マネージドサービス、より厳格な制限を備えたサーバーレス実行環境、あるいはセキュリティをデフォルトで考慮して設計されたマイクロサービスアーキテクチャなどが含まれます。
いずれにせよ、今回の事件は、開発ライフサイクルに適切なセキュリティ対策を組み込むことの重要性を浮き彫りにしている。具体的には、定期的な依存関係の監査、アーキテクチャで使用されるサードパーティ製コンポーネントのレビュー、関連するCVEの監視、そして重大な障害が検出された際の迅速な対応計画などが挙げられる。
エンドユーザーがコードを実行または生成できるAIベースのツールを開発する企業は、サンドボックスの設計を慎重に分析し、隔離プロセスが常に最新の状態に保たれていることを確認し、信頼できないコードの実行といった機密性の高い機能に、放棄されたプロジェクトを使用することを避けるべきである。
Terrariumのあらゆる側面は、ユーザーコードやLLMモデルを実行するには極めて厳格なセキュリティ対策が必要であることを示しています。高性能かつ低コストのサンドボックスは非常に魅力的に見えるかもしれませんが、重大な脆弱性が発見され、パッチが提供される見込みがない場合、バランスが崩れ、多くの重要なユースケースにとってリスクが許容できないものとなります。
