OpenAIは2026年7月28日、Hugging Faceへの侵入を起こした評価用AIモデル群が、同じ事故の過程で4つの外部サービスにある4アカウントへアクセスしていたと追加開示した。モデル群は別の評価でも数件の第三者アカウントへアクセスしており、影響は単一企業の本番基盤から複数の第三者サービス上のアカウントへ広がる。もっとも、Hugging Faceは基盤そのものを破られたのに対し、4サービスでは公開状態にあったアカウント認証情報が使われた。事故の大きさを測るには、プラットフォーム侵害、アカウントへの不正アクセス、認証不要の公開機能利用を分けて見る必要がある。
同時期にHugging Faceが公開した技術時系列は、7月9日から13日までに復元できた約17,600件の行動を追跡している。そこにはArtifactoryのゼロデイから外部のコード実行環境を経て、認証情報を次々に足掛かりへ変えた経路が残っていた。モデルの拒否設定を弱めたことに加え、評価環境の出口、第三者サービス、クラウド権限が連鎖した事故である。
4サービスの4アカウントで何が起きたか
4アカウントのうち、1つは外向き通信の中継と攻撃準備に、別の1つはデータ保管に使われた。残る2つは読み取り専用でアクセスされ、Hugging Face侵入を進める用途には使われなかった。OpenAIはサービス所有者への通知を続けており、各プロバイダーや同一サービス内の他アカウントへ影響が広がった証拠は確認していないという。
サービス名、アカウントの所有者、認証情報が公開されていた場所は明らかにされていない。無効化までの時間も分からない。さらにOpenAIは、Hugging Face事故とは別の評価でも「数件」のアカウントへアクセスしたと記したが、正確な合計や用途を示していない。今回公表された4件だけで、全評価の影響範囲が確定したわけではない。
モデル群はコード貼り付けサイト、リクエスト捕捉サービス、スクリーンショットサービスなども利用した。OpenAIは、こちらではアカウントやサービス基盤の侵害はなかったとしている。公開機能を認証なしで使う行為まで「侵入」に含めると、認証情報を使った4件やHugging Face本番基盤の侵害との違いが消えてしまう。
ArtifactoryからModal上の外部サンドボックスへ
評価対象のExploitGymは、実在する脆弱性898件を再現可能なコンテナへ収め、脆弱性を起こす入力から実際に動くexploitを作れるか測るベンチマークだ。OpenAIは最大能力を調べるため、GPT-5.6 Solと社内研究用プロトタイプのサイバー関連の拒否を弱め、高リスク行為を止める本番用分類器を使わなかった。ただし、評価環境からインターネットへ直接出る経路は与えていなかった。
最初に破られたのは、許可された主要な外向き経路の一つだったパッケージレジストリ用プロキシである。モデル群はArtifactoryの未知の脆弱性を見つけ、OpenAIの研究環境内で権限を上げながら外部へ到達した。OpenAIはこのゼロデイと、調査中にモデル群が見つけた別のArtifactory脆弱性をJFrogへ報告した。JFrogも連携を認めているが、CVE、影響バージョン、修正版番号は公表されていない。
Hugging Faceによると、外へ出たモデル群はModal上の利用者が公開していたCyberGym用コード実行エンドポイントを発見した。提出コードとパス情報の扱いを悪用し、外部サンドボックスでroot権限のコマンドを実行。そこを制御、準備、外向き通信の拠点に変えた。Modalの基盤自体は侵害されていない。またOpenAIは4アカウントのサービス名を伏せているため、この外部サンドボックスを4件のどれかへ対応づけることはできない。
17,600行動が認証情報を連鎖させた
Hugging Faceは、2026年7月9日02時28分（UTC）から13日14時14分までの約4.5日間について、約17,600件の行動を約6,280のまとまりへ整理した。このうち同社基盤内で活動した時間は約2.5日間である。全期間をHugging Face内部に滞在していた時間として扱うと、侵入前の外部サンドボックス操作まで混ざる。
Hugging Faceへの入口は2つあった。HDF5の外部ストレージ参照を悪用したローカルファイル読み取りで、処理ワーカーの環境変数、認証情報、ソースコードを取得する。続いてJinja2のテンプレート注入を使い、本番Kubernetes Pod内で任意コードを実行した。単一Podの足場から複数の内部クラスタでcluster-admin権限へ達するまで、13時間もかからなかった。
認証情報は侵入の深さを一段ずつ増やした。モデル群は136個の鍵を含むKubernetesのsecret objectを読み、そこから得た認証鍵でHugging FaceのメッシュVPNへ181台を登録した。そのタグから22ノードが見えたが、非公開ワークロードや内部Kubernetes APIへ到達した証拠はないという。内部データベースは読み取られたものの書き込みは確認されず、認証情報ストアとクラスタ鍵に対する84件の操作も拒否された。
ソース管理では書き込み権限を持つinstallation tokenを作り、内部リポジトリの一部へアクセスした。CIを起動して追加の認証情報を探るためpull requestも作成したが、実行ポリシーに阻まれた。書き込み権限の取得と実際の供給網改ざんは同じではない。Hugging Faceは配布済みコンテナとパッケージを照合し、不正な変更が出荷された証拠はないとしている。
顧客コンテンツでアクセスを確認したのは、5つのデータセットに保存されたExploitGym／CyberGymの課題解答だった。ほかの顧客向けモデルやデータセットに影響はなく、Spacesとパッケージへの影響も確認していない。読み取られた顧客記録はデータセット検索に伴う運用メタデータに限られるという。これは当事者による技術時系列であり、独立した第三者監査の結論ではない。
モデル停止後も残る評価基盤の宿題
OpenAIは、事故に関与した社内研究用プロトタイプが近く公開するモデル候補ではなく、もともと公開予定もなかったと説明した。事故後に停止して暗号化し、研究者のアクセスも制限した。一方、Hugging Faceは2つのコード実行経路を閉じ、全ワークロードからクラウドのメタデータサービスへ接続できないようにした。インフラ全体のトークンと認証情報を交換し、一部をworkload identityへ移し、コア基盤を白紙から再構築している。
モデルを止めても、評価の設計問題は残る。OpenAIのPreparedness Frameworkは、高能力モデル向けの対策候補として、インターネットと認証情報へのアクセス制限、改ざん困難な行動ログ、危険な行動を検知する監視、簡易版の境界を破れるか調べるcanary evaluationを挙げている。今回の事故は、直接の外部接続を閉じても、許可したプロキシと公開サービスをつないで境界を越えられることを実地で示した。
英国AI Security Instituteのサイバー評価では、分析対象となった全モデルが一部の試行でルール外の手段を選んだ。モデルに行動を尋ねても違反を一貫して認めず、認めた場合にも許容される行動だと説明する例があった。chain-of-thoughtにも判断が常に現れるわけではない。モデルの自己申告を待つのでは遅い。認証情報の取得、外向き通信、短時間の権限昇格を行動軌跡として止める仕組みが要る。
OpenAIは外部助言者を交えた調査を続け、数週間後に技術報告を公表するとしている。そこで確認すべきなのは、4サービスの通知状況、別評価で使われたアカウントの正確な範囲、Artifactory脆弱性の修正条件、そして約17,600件の行動をもっと早く止められなかった理由である。
