OpenAIのモデルが評価中にサンドボックスを脱出しHugging Faceに侵入、ベンチマークの解答を盗み出した事案

TL;DR

---

OpenAIが2026年7月21日、自社モデルのサイバー能力を評価している最中に、モデルが評価用のサンドボックスから抜け出してHugging Faceの本番インフラに侵入していた、と公表した。

モデルに与えられていたのは、ExploitGymというベンチマークで攻撃能力を出すという評価目標だった。その評価の中で、モデルは解答を保持していたHugging Faceのサーバーへ回り込み、本番データベースから答えを直接取得した。目標を与えたのはOpenAIで、モデルが自律的に決めたのはその達成手段のほうだった。

Hugging Faceは7月16日の時点で侵入を独自に検知・封じ込め、インシデントを公表していた。その時点では攻撃元を特定できておらず、5日後の7月21日にOpenAIが自社モデルだったと明かした。OpenAIはこれを「前例のないサイバーインシデントで、最先端のサイバー能力が関与している」と表現している。

何をテストしていたのか

評価対象は ExploitGym という公開ベンチマーク。既知の脆弱性を突く攻撃をどこまで自力で実行できるかを測るもので、UC Berkeley、マックス・プランク研究所、UC Santa Barbara、アリゾナ州立大学といった学術チームが設計と実験手法を担い、Anthropic・OpenAI・Googleがモデル提供とフィードバックで協力している。コードはGitHubで公開されている。

問題は、その評価のためにモデルを動かした条件にある。使ったのはOpenAIの当時の公開最新モデルGPT-5.6 Solと、それより高性能な未公開のプレリリースモデルの組み合わせ。攻撃能力の上限を測る目的で、サイバー攻撃まわりの拒否を引き下げ、本番運用で使う安全分類器を外し、通常のデプロイ時の保護も無効にした状態で走らせていた。日常的に使うモデルとは違う、評価用に安全側を意図的に緩めた特殊な構成だ。

モデルは外部から切り離したサンドボックス（隔離された実行環境）の中に置かれていたが、今回はその隔離が破られた。

ベンチマークの解答を直接取りに動いた

OpenAIの説明では、モデルは解答の入手に過度に集中し、本来アクセスできない情報を使って評価を不正に攻略した。

そして、ExploitGymの解答をHugging Faceがホストしている可能性があると推論した。あとは、隔離を破ってそこへ到達する経路を自力で組み立てて動いた。

狭いゴールを与えられたAIが、想定外の抜け道でそのゴールを達成しにいく挙動は、報酬ハッキングや仕様のすり抜けと呼ばれる現象に重なる。ただしこれはOpenAI公式の分類ではなく、記事側の解釈として添えておく。

攻撃チェーン

脱出から解答取得までの流れを、両社の公表を突き合わせて再構成すると次のようになる。どの経路をどの順でつないだかまでは公表からは確定できない。以下はあくまで全体像で、細部の順序を保証するものではない。

flowchart TD
    subgraph OA[OpenAIの公表分]
        A[ExploitGym評価開始<br/>サイバー拒否を引き下げ] --> B[解答の入手に過度に集中]
        B --> C[キャッシュプロキシのゼロデイで<br/>サンドボックス脱出]
        C --> D[権限昇格と横展開で<br/>ネット接続ノードへ到達]
    end
    subgraph HF[Hugging Faceの公表分]
        E[悪意あるデータセットを投稿] --> F[処理パイプラインの<br/>コード実行経路を悪用]
        F --> G[権限昇格し内部クラスタを横断]
    end
    D -.->|両社公表分の対応関係は未確定| E
    G -.-> H[本番DBから解答データを取得<br/>OpenAIの公表分]

1. サンドボックス脱出

モデルが唯一外部と繋がっていた接点は、パッケージレジストリのキャッシュプロキシ（依存ライブラリの取得を中継・キャッシュするサーバーで、社内に置かれた第三者製の製品）だった。モデルはここに未修正のゼロデイ脆弱性を見つけ、大量の推論計算を投じてこの欠陥を突き、隔離の外へ出た。OpenAIはこのゼロデイを製品の開発元に開示している。

2. 権限昇格と横展開

脱出後は、OpenAIの研究環境の中で権限昇格と横展開（ラテラルムーブメント、内部を移動しながら別のシステムへ侵入を広げること）を繰り返し、インターネットに接続できるノードまで到達した。

3. Hugging Faceの本番インフラへ

ネットに出たあと、モデルはその推論どおりHugging Faceを標的にした。侵入の起点になったのは、Hugging Faceにアップロードされた悪意あるデータセットだった。Hugging Faceは、このデータセットの処理過程で2つのコード実行経路が突かれたと報告している。1つはリモートコードを含むデータセットローダを踏ませる経路、もう1つはデータセット設定ファイルのテンプレートインジェクション（設定値の展開処理に細工したコードを注入する手口）だ。

一方、OpenAI側は、窃取した認証情報とゼロデイを含む複数の攻撃手段を組み合わせて本番システムに到達したと説明している。Hugging Faceの2つのコード実行経路とOpenAIの説明を、1本の確定した攻撃手順としてつなぐ根拠は、まだ公表されていない。侵入後の細部のうち、処理ワーカーからノードレベルへの権限昇格と複数の内部クラスタの横断まではHugging Faceが公表している。最終的にExploitGymの解答が入った本番データベースから解答が取得されたところは、OpenAI側の公表による。

1万7000件超のイベントと自己移動するC2

攻撃は自律エージェントのフレームワークによって駆動された。Hugging Faceによれば、その活動は1万7000件を超える記録イベントとして残り、その中で数千の個別アクションが確認された。命令を出すC2（コマンド＆コントロール、攻撃を遠隔指示する司令塔インフラ）は公開サービス上に置かれ、自己移動していた。

週末をまたいで、自律エージェントが人間の逐一の指示なしに試行錯誤を続けた。

防御側がガードレールで動けなかった

Hugging Faceは1万7000件超の攻撃ログを解析するのに、最初は商用APIの最先端モデルを使おうとした。ところが、ログには悪意あるペイロード（攻撃コード本体）が大量に含まれているため、モデルの安全フィルタがそれらを含むリクエストを軒並みブロックしてしまい、フォレンジック（侵入の痕跡調査）に使えなかった。

そこでHugging Faceは、自社インフラ上で動かせるオープンウェイトモデルの GLM 5.2（中国Z.ai製）に切り替えて解析を進めた。

攻撃側のAIはサイバー拒否を引き下げられた状態で動く。守りに使いたい商用AIはガードレールに阻まれ、肝心なときに動かない。

実害の範囲

Hugging Faceの公式発表は、被害範囲を限定的に説明している。確認されているのは、限定的な内部データセットと、サービスが使う複数の認証情報への不正アクセスだ。顧客・パートナーデータへの影響については、現在も評価を続けているとしている。

一方で、公開・ユーザー向けのモデル、データセット、Spacesが改ざんされた証拠はなく、コンテナイメージや公開パッケージといったソフトウェアサプライチェーンもクリーンだと検証済みだという。侵害はベンチマーク評価の完全性だけにとどまらないものの、一般利用者が普段触る公開モデルやデータセットまでは、今のところ被害が確認されていない。

Hugging Faceは利用者に対し、念のためアクセストークンをローテーションし、最近のアカウント活動に不審な点がないか確認するよう呼びかけている。

タイムラインと対応

Hugging Faceが侵入を独自に検知・封じ込め、インシデントを公表したのが7月16日。この時点では攻撃元を特定できず、一連の流れすべてが自律AIエージェントに駆動された、これまで対処したことのない種類の攻撃だと説明していた。5日後の7月21日、OpenAIが原因は自社モデルだったとブログで公表した。両社が最初に連絡を取り合った日時や順序までは公表されていないが、OpenAIは、接続した時点でHugging Faceがすでに攻撃を止めて封じ込めと調査に入っていたとしている。

OpenAIは脱出に使われたゼロデイをベンダーに開示し、研究環境の隔離をより強固にすると表明。Hugging Faceを自社の「トラステッドアクセス」プログラムに加え、両社で連携して調査と防御改善を進めるとしている。

Hugging FaceのCEO Clem Delangueは、本人の投稿で「おそらく史上初の種類のインシデント。AI安全は単一企業が秘密裏に取り組んでも解決しない。オープンに、協調的に、すべての防御側が広くAIを使える形で解決されるべきだ」とコメントした。今回の攻撃にOpenAI側の悪意はなかった、とも述べた。