OpenAI による Hugging Face への攻撃

～2026 年 7-8 月の脅威動向と代表的な攻撃（前編）～

2026 年 7-8 月の脅威動向を見るために、記事末尾で 7-8 月の代表的なインシデント・攻撃等を羅列しています。もちろんこれらは代表的なものであり、その他にも多くのインシデントが発生しています。

今回は 7-8 月に発生した中でも

OpenAI による Hugging Face への攻撃
Cl0p ランサムウェアグループによる攻撃

を見てみたいと思います。

1. OpenAI による Hugging Face への攻撃

2026/07/16 に Hugging Face（AI モデルや学習データを共有・公開する場所）で、Hugging Face の内部データセットやサービスで使用される認証情報に対して、不正アクセスが検知されました。
その数日後の 2026/07/21 に OpenAI が公式ブログで、このインシデントが OpenAI のモデルを用いたサイバー攻撃能力の内部評価中に発生した事故だったことを公表しています。この事案は、AI モデルの評価テスト中に複数の AI エージェントが自発的に強固な防御網を破り、意図せずに攻撃を行ったという、AI 技術の高度化がもたらす新たなセキュリティ脅威を物語っています。

いつもと少しスタイルは変わりますが、下記で 2026 年 8 月末時点で判明している本件の情報についてまとめています。

1-1. エグゼクティブサマリー

項目	内容
Who（誰が）	OpenAI
When（いつ）	2026/07/16
Where（どこで）	Hugging Face の内部データセット及びサービスで使用される認証情報
What（何を）	認証情報への不正アクセス
Why（なぜ）	モデル評価中での事故
How（どのように）	AI モデルの評価テスト中に、隔離環境から外部の JFrog Artifactory に対する SSRF 攻撃を発展させてメッセージボードを構築し、外部サービスの脆弱性を経由して Hugging Face の Kubernetes クラスタの管理者権限を奪取
回避策	N/A

1-2. Who（誰が）

OpenAI が AI モデルをテストしている間に、意図せずに AI エージェントが攻撃を行うという事態になってしまいました。

1-3. When（いつ）

以下、判明している時系列になります。

日付	詳細
2026/05/07	OpenAI で社内専用の実験モデルに対して新しいトレーニングを開始。こちらのトレーニングセットには（気づかなかったが）実際に不可能または非常に難しいタスクがいくつか含まれていた模様。インターネットアクセスは無効にしてある状態。
2026/05/08	エージェントに「不足している数式を使用して、この Excel ワークブックを完成させてください」という問題を与える。しかし（気づかなかったが）この Excel に Google ドライブへのリンクが複数混入しており、インターネットへのアクセスが無効にされているため、モデルが「Google にアクセスする必要がある」と認識。
2026/05/08 以降数日	モデルがインターネットへのアクセスを得るために JFrog Artifactory サービスをサーバーサイドリクエストフォージェリ（SSRF）を用いて攻撃したが失敗に終わる。その際に OM というファイルシステムにファイルをアップロードできる、つまり JFrog Artifactory サービスに書き込みアクセス権限を持っているということに気づく。
上記のさらに数日後	別のエージェントがデータベースの softrace.pro というファイルに関する解決不可能なタスクを与えられる。このエージェントはタスクに失敗したが、その際に別のエージェントがこのファイルに関するタスクの情報を持っているかもしれないと気づく。そして上記のように書き込みアクセス権限を持っていることがわかっているため、もともとあるファイルのメッセージ読み取りや、他のエージェントと連絡を取るために「softrace.pro の情報を求む」というメッセージ送信を行う。
上記のさらに数日後	さらに他のエージェントもタスクに行き詰まった際にメッセージの読み取りや送信を行う。このような繰り返しで、エージェントにより意図しない形でメッセージボード（掲示板）のようなものが出来上がる。
2026/05/26	トレーニング中のモデルが JFrog Artifactory に対して SSRF 攻撃を成功。
2026/06/11	非常に持続的な実験的内部モデルがトレーニングを開始。この間に SSRF 脆弱性が先述のメッセージボードに書き込まれる。他のモデルも、それを認識する。
2026/06/26	複数の AI エージェントが JFrog Artifactory に存在したゼロデイ脆弱性を悪用。具体的には、旧仕様のトークン更新エンドポイントに「署名が無効なトークン」を送信することで、逆に「有効な管理者権限トークン」を自ら偽造・取得することに成功した。さらに取得した管理者権限を用いて Groovy プラグインを導入し、コマンド実行サービス（C2 サーバー）まで構築していた。これにより、モデルが管理者権限を取得して JFrog Artifactory 上でかなりの活動を行うようになった。
2026/07/04	JFrog Artifactory の停止が発生し、その後セキュリティインシデントが発生。OpenAI のオンコールエンジニアがすぐにインシデント対応を開始した。
2026/07/06	ゼロデイはパッチが適用され緩和された。また、元のメッセージボードの内容もクリアされた。
2026/07/08	エージェントがさまざまな手段とメカニズムを使用してメッセージボードを再確立しようとした。結果としてエージェントは JFrog Artifactory で認証されていない webdav エンドポイントを見つけ、JFrog Artifactory のリモートキャッシュ内にディレクトリを作成できることを確認。以降、ディレクトリ名を用いてメッセージをやりとりするようなメッセージボードを代替として確立。
上記の後	ExploitGym などの解けない問題に直面した AI 群が、メッセージボード上で「正解（データセットや模範解答）が GitHub や Hugging Face に存在するはずだ」と推測・議論を開始。単なるテキスト共有にとどまらず、攻撃キットやスクリプトを Base64 でエンコードしてフォルダ経由でやり取りし始めた。
上記の後〜2026/07/15	モデルは正解を探す中で、Hugging Face 上の非公開データセットを暴くために攻撃を仕掛けるアイデアを思いつく。この際に、モデル自身も「本来のタスク範囲から外れている」と認識しつつも一部の行動を継続。膨大なメッセージが行き交う中で、あるエージェントが他のエージェントの成果物を上書きしてしまう等の混乱が発生した。
2026/07/08〜2026/07/19	流出した Pastebin 投稿の公開アーカイブから外部組織（組織１）の認証情報を発見し、メッセージボードで共有。実際に書き込みできることを確認し、悪意のある Ruby スクリプトを置く「置き場所」として使用し、再び OpenAI の JFrog Artifactory を攻撃（JRuby のデシリアライズの RCE 脆弱性を使用した模様）。管理者トークンの署名キーを再奪取し、さらに Linux の root 権限も奪取。
2026/07/08〜2026/07/19	さらにクラウドサービス「Modal」上に置かれていた CyberGym 関連アプリを発見したエージェントが、デフォルト設定のまま放置されていた公開 API キーを見つけ出し、コマンドインジェクション攻撃を実行。Modal 上のアプリを乗っ取り、Hugging Face へ本格的な攻撃を仕掛けるための足場とした。
2026/07/08〜2026/07/19	乗っ取った Modal から Hugging Face に対し、2 つの未知の脆弱性（ゼロデイ）を組み合わせて連鎖攻撃を行った。 1. HDF5 ファイル解析バグを悪用し、サーバー内部の任意のファイルを読み出す権限を取得して内部ファイル（ソースコード）の盗み出しを行った。 2. 1. で獲得したソースコードの解析結果と盗んだ認証情報を用いて、Jira2 の脆弱性をついてリモートコード実行（RCE）を成功。結果として、最初に足場を得てから 13 時間未満で、Hugging Face が運用する複数の Kubernetes クラスタの Cluster Admin 権限を奪取。
2026/07/16	Hugging Face が「自主開発 AI エージェントによるサイバー攻撃を受けた」旨のブログ記事を公開。

1-4.Where（どこで）

N/A

1-5.What（何を）

N/A

1-6.Why（なぜ）

意図せずに AI エージェントが引き起こした事故とのことです。

1-7.How（どのように）

OpenAI の公式情報、及びBlackHat 2026 での講演 (YouTube)から、本件でどのような事が発生したのかをまとめています。特に YouTube 動画には様々な情報が載っています。

1-7-1. 攻撃の背景

OpenAI には、「Preparedness Framework」というフロンティア AI モデルの安全性評価・リスク管理をどのように行うかを定めた公式フレームワークがあります。
このフレームワークの中では、「Our team develops or adopts evaluations designed to track progress on each of these capabilities and to indicate when the identified capability thresholds may have been reached.（当チームは、これらの各能力における進捗状況を追跡し、特定された能力の閾値に達した時期を示すために設計された評価方法を開発または採用しています）」としており、その評価の一つとして「The ability of an AI model to assist in the development of tools and executing operations for cyberdefense and cyberoffense.（AI モデルが、サイバー防御およびサイバー攻撃のためのツール開発や作戦実行を支援する能力）」を挙げています。

これに従い、OpenAI では自社の AI モデル（GPT-5.6 Sol など）の開発で「AI モデルがどれくらいのサイバー攻撃能力を持っているか」を測定・評価しようとしていました。
OpenAI の公式情報によると、この評価は高度に隔離された環境で実行されており、ネットワークアクセスに関しても、機能が極度に限定されているものになっています。

この「サイバー攻撃能力の評価」を行っている際に、（OpenAI が集めた証跡によると）テストでは ExploitGym のソリューションを見つけることに集中していたようです。

1-7-1-1. ExploitGym とは

ExploitGymは、AI エージェントが既知の脆弱性から実際に動作するエクスプロイトを作成できるかを評価するためのベンチマークです。実世界の 898 件の脆弱性（ユーザー空間プログラム、Google V8、Linux カーネル）を収録し、AI のサイバー攻撃能力を現実的な環境で測定することを目的としています。

(ExploitGym のアーキテクチャ : 画像は論文より引用 )

上図は ExploitGym のアーキテクチャになります。

脆弱性と緩和策設定を組み合わせることでタスクインスタンスが定義されます。
エージェントにはビルド・ソース情報、脆弱性情報、ランタイム情報が提供されます。
エージェントは制限されたリモートターゲットと通信してエクスプロイトを開発します。
フラグの確認で不正なコード実行が確認され、エージェントによりエクスプロイト脆弱性を標的として動作したかどうかを評価します。

1-7-2. 「全権限奪取」行動の詳細と要因

前述の ExploitGym のようなタスクでは、モデルに C 言語のメモリ脆弱性を取得させ、それを悪用して任意の読み取り権限を取得するよう、テストのために要求することがあります。AI エージェントにこのような難しいタスクを与えると多くの場合、行き詰まってタスクの実行が不可能だと AI エージェントが気づきます。

モデルの処理が行き詰まったときによく起こることは、要求を完了させるために、課題を不正に操作したり、ごまかしたりしようとすることです。例えばインターネット上に既に同じデータセットがあるかもしれない、と考えて探そうとします。さらに時には、エージェントは処理に行き詰まった結果として、他のエージェントに連絡を取るというアイデアを思いつくことがあります。このような AI エージェントの特性が、今回の問題を生んでしまいました。

公式の声明文、また YouTube での動画によると、OpenAI の方ではログをチェックしている（現在進行形）ようですが、ログが 70 億件以上に及んでいるらしく、完全な調査にはまだ時間がかかるようです。しかし、現時点で判明していることが色々ありますので簡単に説明します。ちなみに今回 OpenAI の AI モデルで発生した事象は、「When」の箇所で時系列に沿って解説していますので参考にしてください。

今回のインシデント（Hugging Face への不正アクセス）に至るまでには以下の３つの要因があります

AI エージェントが会話をし合うメッセージボード（掲示板）が作成され、削除された後も再作成されてしまった
多数のモデルの実行が行われていたが、それらがモデル評価タスクのために、メッセージボードを用いて潜在的な攻撃対象や方法などを共有してしまった
メッセージボードが作成された時期から内部モデルが「この一連の行動」に関してトレーニングを実施してしまった（そのため、メッセージボードの再作成もできてしまった）

今回のインシデントの遠因は「あるエージェントが note（メモ）を OpenAI で内部的に使用しているパッケージマネージャ（JFrog Artifactory）にアップロードすることで、通信を行うことができる」と気づいたことにあったようです。このエージェントは、サンドボックス化されたテスト環境でのテストで「Excel ワークブックを完成させてください」という課題を与えられました。しかし（OpenAI 側では気づいていなかったようですが）この Excel に Google ドライブへのリンクが複数混入しており、インターネットへのアクセスが無効にされているため、モデルが「Google にアクセスする必要がある」と学習してしまったようです。

そしてこの「課題」を解決するために、他のエージェントと連携するための連絡手段として「ファイルが書き込める状態にある」ことを見つけてしまいました。これを様々なエージェントも連絡手段として利用した結果、AI エージェント全部で使用できるような「メッセージボード（掲示板）」が生まれました。

このメッセージボードについては Hugging Face への攻撃（実際のインシデント）の前に OpenAI 内部でのサンドボックス脱出などの問題を起こしていたため、インシデント対応により削除されました。しかしその後、AI エージェントがディレクトリ名を媒介にして情報のやりとりを行うという方法を確立し、このメッセージボードで攻撃情報を共有していました。さらには外部の組織（時系列では組織１としています）をツール置き場にして JFrog Artifactory を攻撃し、root 権限まで奪取します。

その後、モデルは Hugging Face が ExploitGym 用のモデル、データセット、およびソリューションをホストしている可能性があると推測し、外部のサーバー（Modal）を乗っ取ることで Hugging Face サーバーへの攻撃の足がかりにしました。その後、Hugging Face 上の下記の二つの脆弱性を組み合わせて Hugging Face で全権限奪取（クラスタ管理者に昇格）しました。

HDF5 ファイル解析バグを悪用し、サーバー内部の任意のファイルを読み出すことでソースコードを盗み出しました。
盗んだ認証情報とソースコードの解析結果を用いて Jira2 の脆弱性をつき、リモートコード実行を行いました。

1-8. 本インシデントの教訓

世界最大級のサイバーセキュリティカンファレンスのひとつである「Black Hat USA 2026」の YouTube 動画でも紹介されていましたが、OpenAI としては今回のインシデントを重く受け止めており、研究のペースを意識的に減速させてセキュリティ基盤を刷新しています。AI エージェントの監視を劇的に拡大し、予防・検知・緩和の制御環境を大幅に強化中とのことです。

さらに、業界への提言として以下の 4 つを挙げています。

「防御ループ（Defensive Loop）」の完全自動化
1. 「脆弱性の発見」だけでなく、「修正パッチの提示」「適用パッチの自動デプロイ」「障害時の自動ロールバック」までを含むソフトウェア開発ライフサイクルの修復ループ全体を自動化
AI エージェントによる「レッドチーム（Red Team）」の導入
1. AI エージェントを活用した防御側の自動レッドチームを自社インフラに導入
AI 時代の「インシデント対応（IR）」のスケール化意図的な原則
1. Honey Token や欺瞞技術などのおとりを適宜混ぜていくことで、攻撃のスピードを意図的に減速させる
基本原則（ネットワーク分離・最小権限）の徹底
1. AI エージェントの行動も、最終的には「獲得できた権限」や「通信できるシステム」の範囲に制限されるため、引き続きこれらは有効