ChatGPTのアカウントをまたぐデータ漏えい経路、Gmail連携データの持ち出しをCheck Pointが実証

Check Point Researchは2026年9月8日、ChatGPTのコード実行環境を利用し、異なるユーザーアカウント間でデータをやり取りできる隠れた通信経路を確認したと公表しました。

研究者は、ChatGPTのコード実行コンテナから共通して利用できた内部のJFrog Artifactoryを経由し、別アカウントのコンテナへ情報を渡せることを確認しました。さらに、この経路と悪意ある指示を組み合わせ、被害者側のChatGPTセッションに接続済みのGmailからメール情報を取得し、攻撃者側のChatGPTアカウントへ返すPoC（概念実証）に成功しています。

ただし、任意のChatGPT利用者のGmailへ無条件にアクセスできたわけではありません。Check Pointが示した攻撃では、悪意ある指示が被害者の会話コンテキストに入り、被害者がその会話でメッセージを送信し、さらにGmailなどの外部サービスがChatGPTへ接続済みで、当該セッションに必要な権限があることが前提になります。

Check Pointによると、同社が報告を完了した時点でクロスアカウント通信経路は利用できなくなっており、OpenAIは研究で特定された内部Artifactoryが廃止されたことを確認しています。実際の攻撃で悪用された事例や、一般利用者からデータが流出した事実は、公開された一次情報では確認されていません。

ChatGPTのクロスアカウントデータ漏えい問題のサマリー

確認できている内容：

• Check Point Researchは2026年9月8日、ChatGPTの異なるアカウントに属するコード実行コンテナ間で、双方向通信が可能になる経路を公表しました。
• 研究者が問題を確認したのは2026年6月です。
• 通信経路には、ChatGPTのコード実行コンテナから利用できた内部JFrog Artifactoryが使われました。
• Artifactory上のリポジトリアイテムへ付与できるメタデータのプロパティが、アカウント単位で分離されていなかったことが原因でした。
• 別アカウントのコンテナから、他方のコンテナが書き込んだプロパティを読み取れることをCheck Pointが実証しました。
• 研究者は、この通信経路を「隠れたタスクチャネル」として利用し、被害者のChatGPTセッションに攻撃者の指示を処理させるPoCを実施しました。
• PoCでは、被害者が接続していたGmailからメール情報を取得し、攻撃者側のChatGPTアカウントへ返すことに成功しています。
• 悪意ある指示は、貼り付けられたプロンプト、共有されたChatGPT会話、カスタムGPTの設定などを通じて会話コンテキストへ入る可能性があるとされています。
• 影響範囲はGmailに限らず、そのセッションが利用できるチャット履歴、アップロードファイル、接続済みアプリ、外部サービス、付与済み権限によって変わります。
• Check Pointが報告を完了した時点で当該クロスアカウント経路は利用できなくなっており、OpenAIは対象の内部Artifactoryを廃止したと確認しています。

現時点で確認できない内容：

• 実際の攻撃者がこの問題を悪用した事例は公表されていません。
• 一般利用者や企業からGmailデータなどが実際に流出したという事実は、Check Pointの公表資料では確認できません。
• 本件に対するCVE番号、CVSSスコアはCheck Pointの公表資料に記載されていません。
• OpenAIが内部Artifactoryを廃止した正確な日時は、Check Pointの公表資料では示されていません。

項目	内容
公表日	2026年9月8日
発見	2026年6月
発見者	Check Point Research、Alexey Bukhteyev氏
対象	ChatGPTのコード実行環境と接続済みアプリを利用する攻撃シナリオ
問題	異なるアカウントのコード実行コンテナ間で内部サービスを介した通信が可能だった
利用された内部サービス	JFrog Artifactory
PoC	あり。接続済みGmailから取得したメール情報を別アカウントへ返す動作を実証
攻撃成立の主な条件	悪意ある指示が被害側の会話コンテキストに存在し、被害者が会話を実行し、対象データへアクセスできるアプリ・権限が存在すること
CVE	公表資料では確認できず
CVSS	公表資料では確認できず
実攻撃での悪用	公表資料では確認できず
対応状況	Check Pointの報告完了時点で経路は利用不可。OpenAIが対象Artifactoryの廃止を確認

原因は共有Artifactoryのメタデータがアカウント単位で分離されていなかったこと

ChatGPTでは、コード実行を伴う処理を隔離されたコンテナ内で実行します。Check Pointによると、研究時点の環境ではコンテナから一般のインターネットへ直接アクセスできず、別の会話やアカウントに属するコンテナ同士も直接通信できない構成でした。

一方、Pythonやnpmなどの追加パッケージを取得する必要があるため、それぞれのコンテナは共通の内部JFrog Artifactoryへアクセスできました。

問題になったのは、このArtifactoryで利用できたItem Management APIです。研究者が調べた環境では、コンテナに渡された認証情報でリポジトリアイテムのプロパティを書き込み、同じアイテムのプロパティを読み取ることができました。

Check Pointは、一方のアカウントに属するコンテナからテスト用プロパティを書き込み、別アカウントのコンテナから同じ値を読み取れることを確認しました。

テキストだけでなく、バイナリデータをBase64でエンコードして渡すことも可能で、大きなデータは複数のプロパティへ分割して送信できたとしています。これにより、本来分離されているはずのコンテナ間で、Artifactoryのメタデータが実質的な「共有クリップボード」として機能しました。

攻撃者の指示を被害者側ChatGPTが処理する「第2の通信経路」

Check Pointは、単にデータを別アカウントへ渡せるだけでなく、この経路を攻撃者から被害者側ChatGPTへの指示チャネルとして利用できることも確認しました。

研究者が作成したPoCでは、ChatGPTが利用者から見える通常の依頼と、攻撃者側から受け取る隠れたタスクを同じターン内で並行して処理しました。

被害者には通常の回答が表示されます。一方でChatGPTは内部の通信経路を確認し、攻撃者が用意した別の指示があれば、被害者側セッションが利用できるツールやデータを使ってその指示を処理し、結果を攻撃者側へ返しました。

Check PointはThinking modeを使った検証で、この2つの処理を分離して実行できたと説明しています。

Gmailのメール情報を別のChatGPTアカウントへ返すPoCに成功

影響を確認するため、Check PointはGmailを接続済みのChatGPTセッションを使ったPoCを実施しました。

被害者は、悪意ある指示があらかじめ含まれた共有ChatGPT会話を開き、通常のメッセージを送信します。画面上ではその質問に対する通常の回答が返されます。

その裏側で、攻撃者側から隠れたタスクを受け取ったChatGPTが被害者の接続済みGmailへアクセスし、メール情報を取得しました。取得した情報は、前述のArtifactory経由の隠れた通信経路を使い、攻撃者側のChatGPTアカウントへ返されました。

研究者によると、画面上の回答にはGmailへの要求や取得したデータは表示されず、テスト時には「Talked to Gmail」という表示がGmail利用後に現れることが主な手掛かりでした。

これはGmail自体の脆弱性ではありません。ChatGPTへGmailアクセスを許可したセッションが、攻撃者の指示によって既存の権限を利用したことが問題です。

任意のGmailアカウントを無条件に盗める脆弱性ではない

CyberPressは「ChatGPT Flaw Allowed Attackers to Steal Gmail Data Across User Accounts」と報じていますが、一次情報からは攻撃成立に複数の前提条件が確認できます。

Check Pointが示した主な条件は次のとおりです。

• 被害者側の会話コンテキストに悪意ある指示が存在する
• 被害者がその会話で通常のメッセージを送信する
• 被害者のChatGPTセッションがコード実行環境を利用できる
• Gmailなど対象となる外部サービスがChatGPTへ接続されている
• 当該セッションに、取得対象データを読み取れる権限がある

悪意ある指示の持ち込み方法として、Check Pointは「利用者が貼り付けるプロンプト」「共有ChatGPT会話」「カスタムGPT」を挙げています。

このため、「攻撃者がChatGPTアカウントを持っていれば、無関係な利用者のGmailを直接読めた」と理解するのは正確ではありません。

デフォルト設定ではアプリの読み取りが確認なしで実行される場合がある

Check Pointが影響拡大の要因として挙げたのが、ChatGPTの接続済みアプリに対する権限設定です。

OpenAIの現在のヘルプ情報では、接続済みアプリのデフォルト設定として「Important actions」が使われ、アプリからの読み取りは自動的に行える一方、外部へ大きな影響を与える操作や機密情報の共有などでは確認を求める仕組みになっています。

ユーザーは「Always ask」を選択し、アプリ利用前に確認を要求する設定も利用できます。Workspace管理者は、アプリの有効・無効、利用できるユーザー、読み取りや書き込みなどのアクション、接続可能なドメインを管理できます。

今回のPoCでは、Gmailからの読み取りが独立した承認画面なしで実行されました。そのため、攻撃者の指示がモデルに受け入れられた場合、「読み取りだけだから低リスク」という設定がデータ持ち出しにつながる可能性を示しています。

Gmail以外にもチャット履歴、ファイル、接続済みサービスが影響範囲になり得た

Check Pointは、クロスアカウント経路を通じて持ち出せるデータがGmailに限定されないとしています。

同社の説明では、チャット履歴や会話へアップロードされたファイルも対象になり得ました。さらに、Google Drive、Microsoft Teams、GitHubなどの外部サービスが接続されている場合、被害側セッションに与えられた権限の範囲内でデータへアクセスできる可能性があります。

ただし、これらすべてのサービスから実データを窃取したとするPoCが個別に公開されているわけではありません。影響範囲は、各利用者・Workspaceで有効になっていたアプリと権限によって異なります。

企業で生成AIを外部SaaSや社内システムへ接続する際の考え方は、AIセキュリティとは？生成AI・AIシステムのリスクと企業のセキュリティ対策を解説でも整理しています。

OpenAIは対象の内部Artifactoryを廃止、実攻撃での悪用は未確認

Check Pointによると、同社が調査報告を完成させた時点で、今回確認したクロスアカウント通信経路は利用できなくなっていました。

その後、Check PointがOpenAIへ調査結果を開示し、OpenAIは研究対象となった内部Artifactoryインスタンスを廃止したことを確認したとしています。

Check Pointの公開資料には、CVE番号やCVSSスコアは記載されていません。また、攻撃者がこの経路を実際に悪用した事例や、一般ユーザー・企業のGmailデータが本件によって流出した事実も記載されていません。

したがって、本件は「実際のデータ侵害が確認されたインシデント」ではなく、「研究者がクロスアカウントデータ持ち出しをPoCで実証し、公開時点では該当経路が利用できなくなっているセキュリティ問題」として整理するのが適切です。

OpenAIのHugging Faceインシデントとは別件、共通点は共有内部サービス

Check Pointは、調査時期がOpenAIのHugging Faceインシデントと重なっていたことにも触れています。

OpenAIは2026年8月26日に公表した技術報告で、社内のサイバー能力評価中に、本来独立して動作するエージェントがArtifactoryなどの共有リソースを利用して無許可の通信経路を作り、情報を共有していたことを説明しています。

ただし、Check Pointは今回発見したクロスアカウント経路について、Hugging FaceインシデントでAIエージェントが利用した手法とは異なると明記しています。

共通するのは、本来分離されるべき実行環境から共通して利用できる内部サービスが、意図しない通信経路になった点です。

情報システム部門・AI管理者が確認したいポイント

今回確認された特定のクロスアカウント経路は、Check Pointの報告完了時点ですでに利用できなくなっています。そのため、企業側で脆弱性パッチを適用する種類の問題ではありません。

一方、ChatGPTなどのAIサービスへメール、ファイル、SaaSを接続している企業では、今回のPoCを踏まえて次の設定を確認できます。

• ChatGPT Workspaceで現在有効になっている外部アプリを一覧化する
• Gmail、Google Drive、Microsoft Teams、GitHubなど、機密情報へ到達できる連携が誰に許可されているか確認する
• 業務上不要なアプリ接続やOAuth権限を停止する
• 読み取り操作を確認なしで許可する必要があるか、アプリごとに見直す
• 機密性が高いデータへ接続するアプリでは「Always ask」など、より厳しい確認設定を検討する
• WorkspaceのRBACで、外部アプリを利用できるユーザー・グループを限定する
• アプリ側のAction controlで、読み取り・書き込み・新規追加アクションの許可範囲を確認する
• 接続可能なGoogle Workspace等のドメインを組織管理下のアカウントへ制限できるか確認する
• ChatGPT Enterprise等でCompliance Logsを利用している場合、アプリ呼び出しを監査できる状態にする
• 出所が不明な共有ChatGPT会話やカスタムGPTに、機密性の高い接続済みアプリを利用させる運用になっていないか確認する
• AIへ接続するデータと実行権限を「利用者が持つ最大権限」ではなく、業務に必要な範囲まで絞る

OpenAIの現行ドキュメントでは、Enterprise/EduのWorkspaceではアプリがデフォルトで無効、Businessではデフォルトで有効とされています。管理者はWorkspace設定からアプリの有効化、RBAC、アクション制御などを設定できます。

プロンプトインジェクションによるChatGPT上のデータ持ち出しについては、ChatGPTに7つの抜け道―間接プロンプトインジェクションでメモリや会話履歴が漏えいする恐れでも別の攻撃経路を整理しています。

出典

• The Shared Clipboard Inside the Sandbox: Cross-Account Data Leakage in ChatGPT – Check Point Research
• Apps in ChatGPT – OpenAI Help Center
• Google App for ChatGPT – Data Controls FAQ – OpenAI Help Center
• The Hugging Face incident and the road ahead – OpenAI
• ChatGPT Flaw Allowed Attackers to Steal Gmail Data Across User Accounts – CyberPress