Gemini Live APIに深刻な脆弱性：エフェメラルトークンの実装ミスで音声セッション乗っ取りの可能性

2026年6月下旬、セキュリティ研究者のAlvin Ferdiansyah氏が、Google Gemini Live APIのエフェメラルトークン（一時的な認証トークン）システムに重大な設定ミスが存在する可能性を指摘する詳細な分析を公開しました。この問題が悪用された場合、攻撃者は短時間だけ有効なWebSocketトークンを入手するだけで、ブラウザ上で動作するAI音声セッションを乗っ取り、モデルやシステムプロンプト、さらには実行可能なツールまで自由に制御できてしまいます。^A

脆弱性の核心は、トークン発行（ミント）時に1つのセキュリティフィールドが欠落していることです。本記事では、判明している事実、未確認の点、そして開発者が今すぐ取るべき対策をまとめます。

Gemini Live APIエフェメラルトークンの仕組み

Gemini Live APIは、ブラウザとサーバー間のWebSocket接続にエフェメラルトークンを使用します。これは短時間で期限切れになり、特定の用途に制限できる認証トークンです^A。バックエンドサーバーがこのトークンを発行し、クライアントに渡します。クライアントはそのトークンを使ってGemini APIに直接接続するため、APIキーがブラウザ側に露出することを防げます^S。

Googleのドキュメントによると、この制限付き接続用のエンドポイントはBidiGenerateContentConstrainedで、エフェメラルトークンはaccess_tokenクエリパラメータとして渡されます^DS。

欠落していた「live_connect_constraints」フィールド

Ferdiansyah氏の報告によると、Googleが公開しているリファレンス実装では、トークン発行時に**live_connect_constraintsフィールドが省略されていました**^A。本来このフィールドにはbidi_generate_content_setupオブジェクトを含め、トークンを使用するモデル、システム指示（システムプロンプト）、およびツールセットをバインド（紐付け）する必要があります。

このlive_connect_constraintsが空、あるいは存在しない場合、何の制約も適用されません。攻撃者がエフェメラルトークンを入手すると、**クライアント側で自由に設定したフレーム（setup frame）**を送信し、任意のモデルやシステムプロンプト、ツールを指定できてしまいます。サーバー側にはトークンに紐づいた設定値がないため、攻撃者の設定をそのまま受け入れてしまうのです。

重要な注意点: 提供されたソースには、live_connect_constraintsに関するGoogle公式ドキュメント、CVE（共通脆弱性識別子）、またはGoogleのセキュリティアドバイザリは含まれていません。この主張はFerdiansyah氏のMedium投稿に基づくものであり、現時点では未検証ですが、 plausible（ plausibly あり得る）なものとして扱う必要があります^A。

影響：攻撃者が制約のないトークンで何ができるか

もしこの脆弱性が現実のものだった場合、ブラウザベースでGemini Live APIを使用するアプリケーションに深刻な影響を及ぼします。

• サンドボックス内でのコード実行リスク — Gemini Live APIのサンプルには、クライアント側でカスタムツールを追加する機能が含まれています^D。攻撃者が悪意のあるツール定義を注入できれば、アプリケーションのサンドボックス内でコードを実行される可能性があります。
• コンピュートリソースの悪用 — 乗っ取られたセッションは、被害者アプリケーションのクォータ（利用枠）と課金を消費します。エフェメラルトークンは1回の接続用に設計されていますが、攻撃者はバックエンドのトークン発行エンドポイントに繰り返しリクエストを送り、コストを膨らませることも考えられます^G。
• プロンプトの改ざん — setup frameを制御できるということは、システムプロンプトを自由に書き換えられることを意味します。攻撃者はセッションを乗っ取り、機密情報を引き出したり、有害なコンテンツを生成させたり、信頼できるエージェントになりすましたりする可能性があります^D。
• 繰り返しのセッション悪用 — Live APIのセッションは約10分で接続が切れます^DD。攻撃者は再接続が必要ですが、同じ制約のないトークンフローを使えば、繰り返しセッションを乗っ取ることができます。

Google AIフォーラムでは、エフェメラルトークンがシステム指示を無視する、制限付きエンドポイントが期待通りに動作しないといった報告が既に複数上がっており、この分野のエコシステムがまだ成熟段階にあることを示唆しています^DD。

たった1フィールドの修正

Ferdiansyah氏が提案する修正方法は非常にシンプルです。トークン発行時にlive_connect_constraints.bidi_generate_content_setupフィールドに以下の3つの値を設定するだけです^A。

1. model — 使用するGeminiモデルを指定（例: models/gemini-2.5-flash-native-audio-latest）
2. system_instruction — システムプロンプトをpartsとtextの構造で指定
3. tools — 空の配列[]か、明示的に許可したツールのみを指定し、クライアント側からのツール注入を防ぐ

以下はFerdiansyah氏の記事にあったPythonコードの例です^A。

token = gemini_client.auth_tokens.create({
    "uses": 1,
    "expire_time": now + timedelta(seconds=60),
    "new_session_expire_time": now + timedelta(seconds=60),
    "live_connect_constraints": {
        "bidi_generate_content_setup": {
            "model": "models/gemini-2.5-flash-native-audio-latest",
            "system_instruction": {
                "parts": [{"text": "あなたはカスタマーサポートアシスタントです..."}]
            },
            "tools": []
        }
    }
})

注意: live_connect_constraintsは提供されたソース内のGoogle公式APIリファレンスでは確認できていません。そのため、このコード例はFerdiansyah氏の説明に基づくものであり、本番環境で使用する前に実際のAPIでテストする必要があります^A。

現時点で未確認のポイント

以下の重要な点については、提供されたソースでは確認が取れていません。

• Google公式ドキュメントでlive_connect_constraintsの存在やスキーマは確認されていません。
• CVEやセキュリティアドバイザリは公開されていません。
• この脆弱性の独立した再現検証はソースに含まれていません。
• 制約のないトークンを受け取った場合のBidiGenerateContentConstrainedエンドポイントの正確な動作は、公式リファレンスには記載されていません^DS。

開発者が今すぐ取るべき対策

Googleから公式なアドバイザリが公開されるまでは、この脆弱性を「あり得る」ものとして捉え、予防的に対策を講じるのが最も安全なアプローチです。

1. エフェメラルトークン発行コードを監査する — バックエンドでlive_connect_constraints（または同等のフィールド）が正しく設定されているか確認しましょう。
2. 生のAPIキーを絶対に公開しない — ブラウザ向けの接続には常にエフェメラルトークンを使用します^S。
3. トークンの有効期限を厳しく設定する — GoogleはnewSessionExpireTimeを約60秒に設定することを推奨しており、これによりトークンが漏洩した場合の被害を最小限に抑えられます^G。
4. setup frameをサーバー側で検証する — クライアントが独自の設定を送信してきた場合でも、バックエンドで意図したモデル、プロンプト、ツールを強制する仕組みを入れましょう。
5. 不正利用の兆候を監視する — 同じトークンからの繰り返し接続や、予期しないツールの呼び出しなど、異常なセッションパターンに注意を払いましょう。

Gemini Live APIは、リアルタイムの音声・動画体験を構築するための強力なツールです。たった1つのフィールドの欠落がその可能性を損なうことがないよう、開発者は実装を確実に完了させる必要があります。

本記事は、Google公式ドキュメント、コミュニティフォーラムの議論、および研究者のオリジナル記事を含む21の提供ソースに基づいてファクトチェックされています。研究者の主張のうち主要なものは、公開時点では公式ソースから独立して検証できていません。