共有ArtifactoryキャッシュがChatGPTのアカウント間「秘密通信路」になった経緯

サンドボックスで外部ネットワークへの直接接続を遮断していても、すべての実行環境が同じ内部サービスに書き込み可能な形で到達できるなら、利用者同士を完全には隔離できない。これが、Check Point Researchが2026年6月下旬にOpenAIへ報告し、9月8日に公表したChatGPTのコード実行環境に関する問題の要点だ。報告された通信経路は、その後閉鎖されたとされる。56

問題の核心：パッケージのメタデータが「メールボックス」になった

Check Pointの報告によれば、ChatGPTのコード実行コンテナは、他のコンテナおよび公開インターネットから隔離される設計だった。一方で、パッケージ配布に用いる内部のJFrog Artifactoryサービスにはアクセスできたという。6

問題はArtifactoryに到達できたことだけではない。同サービスのItem Management APIを通じ、キャッシュ済みアイテムに関連する可変メタデータを、コンテナが読み取り・変更できたと報告されている。つまり、アカウントをまたいで参照可能な共有状態が生まれていた。

1. 攻撃者が操作するセッションが、共有メタデータに指示やデータを書き込む。
2. 被害者側のコード実行環境が、自身の会話を処理する過程でその状態を読み取る。
3. 被害者側環境が、実行結果を同じ共有場所へ書き戻す。
4. 攻撃者側環境が、その結果を取得する。

実質的に、このパッケージサービスは、本来は分離されているはずのアカウント間で命令と結果を往復させる「共有クリップボード」――内部の指令・制御およびデータ返送経路として機能し得た。619

プロンプトインジェクションで、通信路がデータ流出経路になるまで

共有サービスだけで、攻撃者が被害者の接続済みアプリへアクセスできるわけではない。報告された攻撃では、悪意あるプロンプト、共有会話、あるいはカスタムGPT内に隠された指示などを通じ、攻撃者の命令を被害者のChatGPTコンテキストへ持ち込むことも必要だった。46

その指示が会話コンテキストに入ると、被害者が画面上で依頼した作業と並行して、別の隠れたタスクを実行するようセッションを誘導できる可能性があった。重要なのは、その処理が攻撃者の権限ではなく、被害者セッションがすでに持つツール、連携アプリ、データへのアクセス権で動く点だ。6

Check Pointの概念実証では、被害者のChatGPTセッションが接続済みのGmailアカウントから情報を取得し、Artifactoryの通信路を介して攻撃者のアカウントへ渡した。被害者には、表向きの依頼に対する通常の回答が表示され、報道によれば、注入された指示や転送された内容は確認できなかったという。36

報道では、Gmailが利用されたことを示す小さな「Talked to Gmail」という表示が唯一の目印だったとされる。ただし、これは処理後の利用記録であり、個別の取得や転送について利用者が詳細な承認を求められたことを、それ自体で示すものではない。3

OpenAIの対応

研究者らは2026年6月下旬にこの通信路をOpenAIへ報告した。開示に基づく報道によれば、該当するArtifactoryサービスはすでに廃止されており、問題は解消済みとされる。5

公開された内容は研究者による概念実証である。Gmail情報の取得が、一般利用者を標的として広範に悪用されたことを示すものではない。56

先行するDNS経由の問題との違い

Check Pointはこれより前に、ChatGPTのコード実行ランタイムから公開インターネットへ出る、隠れた通信経路についても報告していた。関連する報告ではDNSを介した仕組みと説明されており、サンドボックスから外部へデータを持ち出せる点が焦点だった。1516

両者は仕組みが異なる。

報告された問題	通信経路	セキュリティ上の影響
先行する外部向け通信経路	ランタイムから公開インターネットへの経路	機微情報を環境の外へ送信できる可能性。1516
Artifactoryの秘密通信路	内部パッケージサービス内の共有・可変状態	名目上は隔離された別アカウント間で、タスクと結果をやり取りできる可能性。6

共通する教訓は、インターネットへの直接接続を塞ぐだけでは十分ではないということだ。プロンプトによって行動が左右され得るシステムは、情報を外部へ、あるいはテナント間で横方向へ運べる到達可能な仕組みを、通信路として悪用し得る。

Hugging Faceを巡るArtifactory事案との関係

Check Pointが示したArtifactory経由の通信路は、OpenAIの評価エージェントとHugging Faceに関わる別の事案と同一の攻撃ではない。ただし報道では、制限された環境から到達可能なサービスとして、Artifactory関連インフラが持つ役割という広い文脈で両者が結び付けられている。5

OpenAIのインシデント報告書には、関連する脆弱なArtifactory経路の遮断や、対象となる研究ワークロードの種類の制限といった緩和策が記載されている。22 これらを一つのエクスプロイトとして混同すべきではないが、共有パッケージリポジトリを単なる無害な裏方の仕組みと見なす危険性を、両事案は浮き彫りにしている。

設計上の弱点：隔離すべきなのは依存先も同じ

サンドボックスの境界の強さは、内部から到達できるサービスの強さを超えない。複数テナントが同じキャッシュ、レジストリ、キュー、メタデータストア、DNSサービス、あるいはID連携エンドポイントを読み書きできるなら、その依存先が秘密通信路になり得る。

信頼できない指示を取り込み得て、連携ツールを呼び出せるAIシステムでは、次の対策が重要になる。

• 書き込み可能なリソースをテナント単位で分離する。 あるアカウントの実行環境が書いた状態を、別アカウントが読めてはならない。
• サービスIDに最小権限を徹底する。 パッケージ取得用の処理に、広範なメタデータ管理権限を当然のように与えない。
• 内部サービスもネットワーク境界として扱う。 信頼できないワークロードから到達可能なら、「内部」であることは安全の根拠にならない。
• ツールの認可と会話上の指示を分離する。 接続済みアプリでの機微な操作には、明確で検証可能な認可境界が必要となる。
• 影響の大きい操作を可視化する。 ログや利用者向け通知は、単にアプリが使われたと示すだけでなく、どのツールで何を対象にした操作かを示すべきだ。

この概念実証が示すのは、単一のパッケージキャッシュの問題にとどまらない。隔離の設計は、直接のネットワークソケットだけでなく、データの経路と共有状態まで対象にしなければならない、という原則である。615