Google MCP Toolboxの脆弱性：セルフホスト型AIのユーザーが確認すべきこと

カバー画像：Google Cloud — MCP Toolboxのアーキテクチャ。

CVE-2026-93328は、具体的なソフトウェアのアドバイザリを、ホームサーバーに関するより大きな問題に結び付けています。AIツールサービスが、エージェントに依頼されたタスクに必要な範囲を超えるファイルやクラウドストレージへの権限を持つ可能性があるのです。まずは影響を受ける正確なコンポーネントを確認し、すべてのMCPサーバーに同じ脆弱性があると決めつけないでください。

このガイドでは、公表された事象と実際の実装を切り分けます。ソースが裏付ける内容と証拠の限界を説明し、優れたモデルや新しいサーバーならアクセス制限やレビューは不要だと決めつけずに、個人ファイルを扱うワークフローを評価する方法を紹介します。

このアドバイザリが対象としているソフトウェアは？

GitHub Advisory Databaseの項目は、Google Cloud MCP Toolbox for Databasesのクラウドストレージソースにおけるパストラバーサルと認可の欠如について説明しています。影響を受けるバージョン範囲はコンポーネントごとに定められています。無関係なMCP実装、このソースを一度も実行しないコネクタ、または別のバージョンについては、それぞれ個別の評価が必要です。アプリケーションの表示名から推測するのではなく、照合結果を検証できるよう、インストール済みイメージのダイジェスト、リリースタグ、設定を保持してください。

確認時点でデータベースの項目には未レビューの印が付いていたため、ベンダーによる完全な対応告知として提示すべきではありません。参照先から上流リポジトリをたどり、現在のリリースノートと照合してください。リンクされたプルリクエストではバケットとローカルパスの制限が追加されていますが、それより早いマージ日は一般公開日ではありません。プロジェクトが今週になって初めてすべてを修正したとする時系列は、証拠を誤って伝えることになります。

境界を守るうえで、更新だけでは不十分なのはなぜですか？

更新済みイメージに制御機能が含まれていても、制限の緩い設定、不要なマウント、広範な権限を持つクラウド認証情報が残っている場合があります。設定名だけで制限が適切だと判断せず、実際に適用されている構成を確認してください。モデル自体が別の場所でホストされていても、ホストのファイルシステムを読み取り、リモートバケットに書き込めるツールは、データ転送経路を生み出します。ツールがアクセスできる範囲を決めるのは、ツールを実行する主体です。

ローカルルート、バケットへのアクセス、実行ユーザー、ネットワークへの露出状況を一覧にしてください。専用のタスク用ディレクトリと、用途を限定したサービスIDを使用するのが望ましいです。プロセスが家族のアーカイブや無関係なクラウドバケットにアクセスできなければ、ツール呼び出しを誤っても悪用できる権限は小さくなります。制限はプロンプト層より下の階層に設ける必要があります。OSの権限、コンテナのマウント、クラウドのIAMは、エージェントがリクエストを誤解したり、取得したコンテンツに含まれる悪意ある指示を受け取ったりした場合にも有効です。

リンク先の上流プルリクエストでは、allowedBucketsとallowedLocalRootが挙げられ、制限の緩いデフォルト値について説明されています。デプロイされたソースで実際に適用されている値を確認してください。新しいバイナリにこれらの設定があると確認するだけでは、デプロイ環境の制限が適切である証明にはなりません。同じ履歴では6月のバージョン1.5.0のリリースにも言及しているため、最近公開された注意喚起を、10月に新たにマージされた修正として説明すべきではありません。

攻撃を再現せずに、露出状況を確認するには？

まず設定と実行時メタデータを確認します。デプロイされたソースの種類、正確なバージョン、エンドポイントが信頼できないネットワークから到達可能かどうかを特定します。そのうえで、ステージング環境で使い捨てのテストデータを用い、許可されているローカルルートとバケットを確認します。過度に広い権限を持つ認証情報やマウントが存在することを確認するために、本番環境のシークレットを送信したり、情報流出の手順を再現したりする必要はありません。

ログやその他の証拠から不正な操作が疑われる場合は、定期的なクリーンアップの前に関連記録を保全し、公開されたサービスに関連する認証情報をローテーションしてください。バージョンをアップグレードしても、コピーされたキーを無効にしたり、すでにシステム外へ持ち出されたファイルを取り戻したりすることはできません。修復作業の記録は調査目的のテストとは分け、変更後に通常のワークフローが機能することを確認してください。目指すのは、単にコンテナが正常に再起動することではなく、権限の範囲が明確に制限されたツールサービスです。

このワークフローを信頼する前に何を測定すべきですか？

デプロイした各インスタンスについて、イメージダイジェスト、ソース設定、実行時のID、マウントされたパス、クラウドID、到達可能なエンドポイントを記録した露出記録を作成してください。コンポーネントがインストールされていることと、影響を受けるソースが有効になっていることを区別します。コンテナのラベルやロックファイルに記載されたパッケージは手がかりとして役立ちますが、実行中のプロセスでどの設定が有効かはわかりません。各結論の根拠とした証拠を保全してください。

無害なテスト用データを使って、制御が機能するかを評価してください。専用のテストルート内で許可された操作は成功し、そのルート外への要求は、モデル自身に不適切だと判断させることなく、実際の制御によって拒否されるべきです。バケットの範囲とIAMにも同じ考え方を適用してください。ディスク上の設定ファイルだけから制御が有効だと判断してはいけません。サービスがそのファイルを読み込んだこと、またデプロイ時の上書き設定によって意図した制限が緩和されていないことを確認してください。

結果の検証可能性と復旧可能性を保つには？

露出が疑われる場合は、時系列を伴う運用上のインシデントとして扱ってください。通常のクリーンアップを行う前に、関連するアクセスログ、デプロイ記録、認証情報の識別子を保全し、それらの記録への不要なアクセスは制限します。把握していることと、まだ確認できていないことを記録してください。脆弱なバージョンが存在していたからといって、データにアクセスされたとは限りません。また、該当するログ記録が見つからないからといって、アクセスが不可能だったとは限りません。

復旧方法は、影響を受けた権限の種類によって異なります。露出したソースを制限または無効化し、必要に応じて脆弱なソフトウェアを置き換え、関係する認証情報をローテーションし、必要であれば既知のコピーから上書きされたファイルを復元します。その後、権限を縮小した状態で、通常の許可された操作が引き続き機能することを検証します。修復後にデプロイされたダイジェストと実効的な許可リストを記録してください。アップグレードによって実行コードが変わっても、広範なマウント、過度に許容的なデフォルト設定、またはすでに露出した認証情報が修正されるとは限りません。

重要なファイルを使う前にワークフローをテストするには？

以下は編集上の検証手順であり、ZimaSpaceがこのサービスのベンチマークを実施したという主張ではありません。使い捨てのテストデータ、または使用を承認されたテストデータを使って実施し、テスト条件を結果とともに記録してください。

1. 稼働中のコンポーネントと影響を受けるソースを棚卸ししてください。デプロイ済みのバージョンをアドバイザリーに記載された範囲と比較し、イメージダイジェストと設定の識別情報を正確に記録します。
2. アドバイザリーと上流の変更を照らし合わせて確認してください。開示日と、それ以前の実装履歴を区別し、アップデートを選ぶ前に最新のリリース情報を確認します。
3. 実効権限を把握してください。ローカルルート、コンテナのマウント、ランタイム権限、バケットのスコープ、IAM、エンドポイントへの到達可能性を調べ、想定するジョブに不要な権限を特定します。
4. ステージング環境で使い捨てのテストデータを使って制限を検証してください。本番環境のシークレットをテストリクエストに含めず、許可・拒否されるパスやバケットを確認します。
5. 不審な活動が疑われる場合は、証拠を保全し、漏えいした認証情報に対処してください。インシデントに関する観察事項と推測、探索的なテストは明確に区別しましょう。
6. 修正後、通常の認可済みワークフローを再実行してください。最終バージョン、読み込まれた設定、強制適用の結果を記録し、変更を独立してレビューできるようにします。

ZimaOSサーバーの活用方法

ZimaCube 2パーソナルクラウドNASは、プロジェクトで複数のドライブ、SSD作業領域、または増え続けるアーカイブへの共有アクセスが本当に必要な場合に、ローカルのストレージおよびアプリケーションレイヤーとして利用できます。保持するソースデータ、稼働中のサービス、バックアップポリシーに合わせてハードウェアを選びましょう。この製品の推奨はアーキテクチャ上の参考情報であり、このクラウドモデル、プレビューサービス、または研究システムがNAS上でローカルに動作することを示すものではありません。

推論とデータの保管場所は分けて考えましょう。ホスト型モデルに承認済みの抜粋を送る一方で、正式な原本はサーバー上に保持できます。任意のローカルインデックス作成、変換、小型モデルのサービスについては、それぞれメモリと計算リソースを評価する必要があります。メインデバイスの外部に復元可能なコピーをもう1つ保管し、RAIDやアップロードの成功を完全なバックアップ対策と見なさないでください。既存の小型サーバーで測定済みのワークロードを処理できるなら、そのサーバーを使い続けるのも妥当です。

よくある質問

このアドバイザリーはすべてのMCPサーバーに影響しますか？

いいえ。引用されたエントリーが説明しているのは、googleapis/mcp-toolboxのバージョン1.2.0～1.4.0におけるクラウドストレージのソースです。他の実装やデプロイについては、それぞれ個別に評価する必要があります。

イメージを更新すれば、修正は完了しますか？

更新は評価の一部にすぎません。実効的なローカルルートとバケットの制限、マウントされたパス、ランタイムのID、クラウド認証情報を確認してください。バイナリを新しくしても、過剰な権限で動作する可能性があります。

本番データを使ってファイルのエクスポートを再現すべきですか？

設定の証拠と無害なステージング用テストデータを使って、露出の範囲を評価してください。マウント、ID、許可リストの範囲が広すぎないかを検証するために、本番環境のシークレットやプライベートファイルは必要ありません。

AIツールにプライベートなアーカイブ全体を公開すべきですか？

タスクに必要なデータだけを、適切に制限されたアカウントまたは作業ディレクトリ経由で提供してください。該当するサービスが何をアップロード、記録、保持するか確認してください。プライベートなストレージに保存しても、接続されたツールの処理がローカルにとどまるとは限りません。

より大容量のNASが役立つのはどんな場合ですか？

測定されたソースデータの増加、共有アクセス、稼働中のアプリケーション、または保持要件から、そのストレージ構成が妥当と判断できる場合です。これだけで、モデルへのアクセス、サポート対象外のランタイム、ネットワークのアップロード制限、調査結果の不確実性が解消されるわけではありません。

本番利用前の中止条件は何ですか？

ソフトウェアやモデルの正体、入力に対する権限、必要な機能の利用可否、または復旧手順を確認できない場合は中止してください。まずこれらの条件を解決してから、小規模なテストを再度実施してください。証拠が不足しているからといって、推奨内容をより断定的にして補ってはいけません。

出典と参考資料

• 公式発表または勧告
• 上流のクラウドストレージにおけるアクセス制御の変更
• 上流プロジェクトのリリース

2026年10月28日時点で確認済み。製品の在庫状況、アクセスプラン、セキュリティ勧告は変更されることがあります。上流の主張は出典を明記しています。ワークフローの推奨事項とアーキテクチャ例は編集上の分析であり、ZimaSpaceのハードウェアテストによる測定結果ではありません。

関連記事：セルフホスト型AIエージェントは読み取り専用のファイルシステムビューを通じて動作できるか？。

関連記事：エージェントの権限が必要なツール操作のみに限定されているかをテストする方法。

関連記事：AIの脆弱性検出と自動パッチ適用の違い：それぞれ何を解決するのか？。