Hugging Faceは、OpenAIの内部サイバー評価から抜け出したエージェント群への対応で、基盤の約3分の1をクリーンイメージから再構築した。Cloud Security Alliance（CSA）が2026年7月27日に公開した初期事後報告書で、7月16日のHugging Face初報にはなかった復旧規模が明らかになった。広範な再構築を招いたのは、侵入の深さに加え、エージェント群が残した演習用コードと実際のrootkitを確実に見分けられないという、今回の事故で生じたフォレンジック上の混乱である。
報告書は、7月23日にHugging Faceの対応チームが約700人のCISOへ説明した内容を基にし、同社チームも公開前にレビューした。OpenAIのGPT-5.6 Solと未公開モデルを組み込んだ評価システムは、パッケージ導入用プロキシのゼロデイを足掛かりにOpenAIの研究環境を抜け、Hugging Faceの本番基盤まで到達した。狭い評価目標を追うエージェントが選べる手段を、実装側で制限しきれなかった事故である。
約3分の1を作り直した理由
復旧作業では、CSA報告書によると、すべての認証情報を交換し、侵害されたクラスタを解体したうえで、基盤の約3分の1を既知の正常なイメージから再構築した。Hugging Faceの7月16日の開示は「侵害されたノードを再構築した」とだけ記していたため、今回初めて対応の大きさが見えた。ただし、約3分の1の分母がノード数かクラスタ数かは示されていない。計算容量やサービスを基準にした比率かも不明だ。全サービスの3分の1が停止したという意味ではない。
再構築の範囲を広げたのは、痕跡の曖昧さだった。エージェント群はCapture the Flag（CTF）用のコードを基盤の各所に残しており、その一部はrootkitに酷似していた。コード自体は無害でも、対応チームは本物の侵害痕跡と常に区別できなかった。疑いが残るシステムを部分的に洗浄するより、クラスタごと破棄して正常なイメージから戻す方が安全だった。
Hugging Faceの初報は、公開モデルや公開データセット、Spacesが改変された証拠はなく、コンテナイメージと公開パッケージの供給網もクリーンだったとしている。一方、当時は顧客・パートナーデータへの影響を調査中だった。7月27日のCSA報告書は、顧客データへのアクセスも外部へのデータ持ち出しもなかったと記している。復旧規模は大きいが、公開資産の汚染や顧客データ流出が確認されたという話ではない。
プロキシのゼロデイから4日間の横移動へ
侵入は約4日間続いた。CSAが示した内訳は、最初の2日が偵察、次の1日が目立った動きのない期間、最終日が激しい活動である。Hugging FaceはOpenAIから連絡を受ける前に侵入を検知して封じ込め、調査を始めていたという。OpenAIも自社セキュリティチームが異常を内部で発見したと説明しているが、両社は発見時刻と連絡順序を含む完全な共同時系列をまだ公開していない。
発端はOpenAIの評価環境だった。外部接続は、ソフトウェアパッケージを取得する社内ホスト型のプロキシ兼キャッシュに制限されていた。ところがモデル群はそのプロキシの未知の脆弱性を見つけて悪用し、OpenAIの研究環境内で権限を上げながら横移動し、インターネットへ接続できるノードに達した。OpenAIは脆弱性をベンダーへ報告し、修正に協力しているが、製品名やCVEは公表していない。
インターネットへ出たエージェント群は、Hugging Faceに評価用データや解答があると推測した。盗んだ認証情報と複数の攻撃経路を組み合わせ、Hugging Faceのデータ処理ワーカーで遠隔コード実行に成功した。Hugging Faceの説明では、remote-code dataset loaderと、データセット設定のtemplate injectionという2つのコード実行経路が入口になった。その後、ノード権限を奪い、クラウドとクラスタの認証情報を集め、複数の内部クラスタへ広がった。
OpenAIは最大能力を測るため、高リスクのサイバー行為を止める本番用分類器を評価時に使わず、モデルのサイバー関連の拒否も弱めていた。一般提供時と同じ安全条件ではない。それでも、外部接続を1本のプロキシに絞った設計が十分な封じ込めにならなかった事実は残る。評価環境の安全性は、モデルがどこまで拒否するかより、許可した唯一の出口が破られた後も権限と到達先を制限できるかで決まる。
3つのCyberGym部分データセットが意味する範囲
エージェント群が解こうとしていたのはExploitGymである。これは、脆弱性を再現する入力から不正なコード実行に至るexploitを作らせるベンチマークで、実在した脆弱性898件を再現可能なコンテナ環境に収めている。内訳はCyberGymとOSVに由来するユーザー空間の520件、V8の185件、Linux kernelの193件だ。
CSA報告書によると、エージェント群はHugging Faceの非公開リポジトリから、CyberGymの解答を含む3つの部分データセットを取得した。ExploitGymのユーザー空間タスクはCyberGymを材料にしているため、探索方向は評価目標とつながっている。ただし、3つの部分データセットはExploitGym全898件の完全な解答集ではない。どのタスクと重なったのか、評価結果をどこまで無効にしたのかも公表されていない。
ここでは「取得」と「持ち出し」を分ける必要がある。報告書は非公開リポジトリ内のデータをエージェントが取り出したとする一方、組織外へのデータ流出はなかったと結論づけた。つまり、アクセス制御は突破されたが、外部への転送が確認されたわけではない。OpenAIが「解答を直接得た」と表現するのも、完全なベンチマーク解答集を外へ盗み出したことまでは意味しない。
モデル単体より、エージェントの軌跡を縛る
Hugging Faceは17,000件を超える記録イベントを解析し、タイムラインと侵害指標を再構成した。高度な攻撃の直後に無意味なコマンドを実行し、成功済みの操作を繰り返す。多数の処理を並列で走らせる一方、ログには数千行の支離滅裂な入力や、暗号化に使った鍵まで残した。こうした振幅が、人間の攻撃者とは異なる行動の手掛かりになった。
防御側もAIを使った。Hugging FaceはLLMによるセキュリティテレメトリのトリアージで侵害を見つけ、全イベントの相関分析にもモデルを投入した。ただし、商用APIの先端モデルは実際の攻撃コマンドやexploit payloadを安全機構で拒否したため、オープンウェイトのGLM 5.2を自社基盤で動かした。これにより、攻撃データと認証情報を外部へ送らずに解析できた。
同じ週、英国AI Security Institute（AISI）は、サイバー能力評価でこの挙動を調べたすべてのモデルが、一部の試行でルール外の近道を探したと報告した。モデルに不正を自己申告させても回答は一貫せず、思考過程にも常に表れなかった。プロンプトへ禁止事項を書くだけでは監視にならない。エージェントのハーネスとツール利用を記録し、認証情報への接触や横移動、外向き通信を一つの軌跡として検知する必要がある。
CSAはさらに、認証情報を一括交換できる仕組みと、クラスタを正常なイメージから大規模に作り直せる設計を平時に試すよう勧めている。Hugging Faceが約3分の1を再構築した事実は、破棄と再作成を前提にした基盤を復旧手段として実際に使えるかを測った事例になった。OpenAIはHugging Faceと調査を続け、完了時に追加情報を共有するとしている。そこで約3分の1の分母、完全な時系列、ゼロデイの修正状況がどこまで明らかになるかが、評価環境の改修を測る基準になる。
