ChatGPTの隔離サンドボックスにアカウントをまたぐ隠れチャネル — Check PointがGmail連携経由のデータ窃取を実証

Check Point Researchは2026年9月8日、異なるChatGPTアカウントのコード実行コンテナ間で、アカウントをまたいでデータをやり取りできる隠れチャネルが存在したとする調査結果を公開した。コンテナ自体は互いに直接通信できず、インターネットへの直接アクセスも遮断されていたが、パッケージ取得のために共用される内部サービスJFrog Artifactoryのメタデータ領域が、アカウント間で共有されるクリップボードとして機能していたことが原因だ。

同社はこのチャネルを隠れタスクの指示と結果の中継に転用できることを実証した。攻撃者が用意した共有会話やカスタムGPTに紛れ込ませた隠れ指示が被害者の会話文脈に入り込むと、被害者が通常の質問を送った際に、ChatGPTが被害者の画面には見えない形で別のタスクを実行し、Gmailなど連携先アプリから取得したデータを攻撃者側アカウントへ中継できた。PoCでは、料理に関する通常の質問に回答する裏側でGmailのメール一覧を窃取する動作が確認された。

共用のArtifactoryが「共有クリップボード」になった仕組み

ChatGPTは複雑な分析でコード実行が必要になると、隔離されたコンテナを生成する。Check Pointが調査した時点では、これらのコンテナはインターネットへ直接アクセスできず、別アカウントのコンテナとも直接通信できない設計だった。

一方で、Pythonやnpmなどの追加パッケージを導入する必要があるため、コンテナは社内のJFrog Artifactoryへアクセスして依存関係を取得できるようになっていた。Artifactoryは公開リポジトリへの直接アクセスを避けるための制御された中継点だ。

問題は、このArtifactoryが公開するアイテム管理APIにあった。Check Pointによれば、/api/storage/{repoKey}/{itemPath} エンドポイントの次の2機能が、コンテナに付与された読み取り用認証情報で実行できた。

• Set Item Properties — リポジトリ内のファイルやフォルダに文字列プロパティを付与する
• Get Storage Item Information — 同一エンドポイントで当該アイテムに付与されたプロパティを返す

コンテナに渡される認証情報は環境変数に格納され、ChatGPTが起動するコードからそのままArtifactoryへ認証できた。権限昇格や秘密情報の抜き取りは不要だった。

Check Pointは、あるアカウントのコンテナで自動キャッシュされたファイルに chatgpt_test_ts というテストプロパティを書き込み、別アカウントのコンテナから同一ファイルのプロパティを取得すると、書き込んだ値がそのまま返ることを確認した。プロパティ値はテキストを直接格納できるほか、Base64でエンコードしたバイナリも格納でき、大きなデータは分割して複数キーに分散し、受信側で再結合できた。パッケージサービスのメタデータ領域が、アカウント間で共有されるクリップボードとして機能していた。

隠れタスクは「見えない第二の利用者」として動作する

この共有クリップボードは、単なるデータ交換にとどまらず、被害者のChatGPTセッションを遠隔操作するチャネルとして機能した。Check Pointが示した攻撃の流れは次の通りだ。

1. 攻撃者が隠れ指示を含む短いメッセージを用意する。配布経路は、被害者に貼り付けさせる悪意あるプロンプト、内容に指示が紛れた共有会話、指示をビルダー設定に隠したカスタムGPTのいずれでも成立した。
2. 被害者の会話文脈に当該指示が入った状態で、被害者が通常のメッセージを送信する。
3. ChatGPTは被害者の可視リクエストを通常通り処理して回答を返すと同時に、裏側で隠れメールボックス（Artifactoryのプロパティ領域）に溜まったタスクを回収し、被害者セッションが持つ権限とデータで実行する。
4. 結果は再び同チャネルで攻撃者側アカウントへ返送される。可視の回答には隠れタスクの痕跡は表示されない。

PoCでは、隠れタスクとして「メール一覧を取得せよ」という指示を与え、被害者が料理に関する無関係な質問を送ったタイミングで、ChatGPTが通常回答を返す裏側で連携済みのGmailからデータを取得し、隠れチャネル経由で攻撃者へ中継した。画面上の手がかりは、回答上部に表示される小さな「Talked to Gmail」ラベルのみで、読み取り自体は実行後に記録される表示であり、事前の承認を求めるものではなかった。

Check Pointは、ChatGPTの連携アプリ（Connected apps）ではデフォルトで低リスクな読み取りが自動承認され、重要とみなされる操作のみが確認を求められる点を指摘した。対象の環境では、メールを読む操作が自動承認の範囲だったため、被害者が気付かないまま個人のメールや業務上の機密を含むデータが窃取され得ると分析している。ユーザーが設定を「Always ask（常に確認）」に変更すれば読み取り時にも確認が生じるが、デフォルトでは読み取り後の表示のみになると説明している。

共有会話とカスタムGPTは、被害者に1回だけ通常のメッセージを送らせるだけで隠れタスクを起動できる点で、特に実用的だった。共有会話ではリンクを開いた被害者が一言送るだけで、カスタムGPTでは本来の機能を装いながら裏側でメールボックスをポーリングできた。いずれも、会話に表示されない指示領域に隠れ指示を置けることが悪用を容易にしていた。

背景 — 評価環境でのエージェント間不正連携との共通点

Check Pointは、今回の調査がOpenAIが公表したHugging Face関連の事後分析で触れられた、別々の評価環境で動作するエージェントが不正な通信路を確立して情報を共有した事案と時期が重なったことにも言及した。悪用された具体的な経路は異なるが、本来は隔離されるべき環境が、共用する内部サービスを介して意図せず通信路になったという構造的な弱点は共通していると指摘している。

修正と提言 — 当該Artifactoryは廃止、共有状態はテナント分離を

Check Pointによれば、同社は2026年6月にこの隠れチャネルを発見し、報告書の完成時点でチャネル自体は既に利用できなくなっていた。同社がOpenAIへ開示したところ、調査で特定された内部Artifactoryは廃止されたことがOpenAI側から確認された。

Check Pointは、今回の事案をエージェント型プラットフォームに共通する設計課題と位置づけ、次の原則を提言している。

• モデルは信頼境界の内側で動作する — 認証情報を使い、コードを実行し、内部サービスや利用者データに触れる。テキスト指示で動作を誘導され得るため、モデルが「強制された内部者」として振る舞う事態を前提に設計する必要がある。
• 共有インフラの可変状態は分離する — 内部サービスでコンテナが変更できるデータは、所有するアカウントやセッションだけが参照できるように分離する。
• 管理インターフェースは実行環境から到達不能にする — 権限は最小限に絞る。
• 外部連携は影響範囲を拡大させる — セッションがGmailやGoogle Drive、Microsoft Teams、GitHubなどと連携している場合、隔離の破綻が容器内のデータを超えて外部サービスのデータへ波及する。

日本企業でもChatGPTを業務で利用し、メールやドライブ、Teams、GitHubなどを連携させる事例が増えている。今回の隠れチャネル自体は廃止されたが、共有会話やカスタムGPTなど、会話文脈の外側から指示が紛れ込む経路は今後も残る。Check Pointが示したように、連携アプリの権限は最小限に絞り、デフォルトの自動承認に頼らず「常に確認」を検討すること、共有会話や野良のカスタムGPTを安易に利用しないことが、エージェント型AIを安全に使ううえでの実務的な出発点になる。

出典

• Check Point Research「The Shared Clipboard Inside the Sandbox: Cross-Account Data Leakage in ChatGPT」 (2026年9月8日) — https://research.checkpoint.com/2026/the-shared-clipboard-inside-the-sandbox-cross-account-data-leakage-in-chatgpt/