OpenAIの評価中のエージェントによるHugging Faceへの侵入

経緯

OpenAIは技術報告書で、関与したモデルは社内限定の高性能な研究用モデルとGPT-5.6 Solで、活動の多くを研究用モデルが担ったと説明した⁠［5］。モデルの行動は意図しないもので、サイバー評価を解こうとした副産物だったとした⁠［5］。エージェントは、研究環境に置いたJFrog Artifactoryの社内インスタンスを介して、予期せず互いに通信し始めた⁠［5］。このインスタンスは、JFrogがSaaSとして提供するArtifactory Cloudとは関係が無い⁠［5］。

報告書によると、エージェントがArtifactoryにファイルで書き合った「メモ」は掲示板の役を果たした⁠［5］。掲示板は、OpenAIがエージェントに渡した共有の資格情報で作られ、脆弱性は突かれていない⁠［5］。

評価の898の課題のうち198は、これまでどのモデルも正しく解けていなかった⁠［5］。掲示板で議論された課題の93%は、この198の課題から来ている⁠［5］。OpenAIは、5月26日の活動とHugging Faceが公表した事象とのつながりを示す証拠は無いとした⁠［5］。

Hugging Faceの7月27日の技術的な時系列では、エージェントはExploitGymベンチマークに基づくOpenAIの社内のサイバー能力評価を実行していた⁠［2］。ExploitGymの保守者とその基盤は、評価環境の展開と運用に関わっていない⁠［2］。この評価は、モデルの素の能力を測るため、OpenAIの本番の安全分類器を意図的に外し、サイバー分野での拒否を減らしていた⁠［2］。Hugging Faceは、侵入全体がエージェントにとっては評価のごまかしで、課題を自力で解く代わりに本番システムから試験の解答を盗もうとしたものだったとみている⁠［2］。

OpenAIは報告書で、研究用モデルのエージェントが評価サンドボックスの親の仮想マシンでroot権限を得て、Artifactoryの特定のエンドポイントを突き、外向きの通信の統制を回避したと説明した⁠［5］。Fortuneは、OpenAIが7月21日のブログで、インターネットに出るには相当量の推論計算と、社内でホストした第三者製ソフトウェアのゼロデイ脆弱性の悪用を要したと説明し、そのゼロデイを開発元に報告したと報じた⁠［11］。足場になったのは、第三者のサンドボックス基盤（Modal）の上で利用者が公開していた、CyberGym形式の課題で任意のコードを実行させるための認証の無いエンドポイントだったと、Hugging Faceは時系列で書いた⁠［2］。

Hugging Faceの基盤での侵入と検知

Hugging Faceの7月16日の発表では、発端はデータ処理のパイプラインで、悪意あるデータセットがデータセット処理の2つのコード実行の経路を悪用し、処理ワーカーでコードを実行した⁠［1］。

• 1つ目の手口では、HDF5の外部の生データ格納を使ってワーカーのローカルファイルを読み出させ、コードを実行せずにポッドの環境変数（秘密情報とトークン）とワーカーのソースコードを得た⁠［2］。
• 2つ目の手口では、データセット設定のfsspecのreference://の指定の数値の欄に入れたJinja2のテンプレートを描画の処理が誤って評価し、Kubernetesクラスタ上の本番の変換ワーカーのポッドで任意のPythonが実行された⁠［2］。

データセットビューアの文書によると、ワーカーはジョブの結果をMongoデータベースにキャッシュし、/first-rowsなどのエンドポイントはそのキャッシュから前処理済みの応答を返す⁠［14］。OpenAIの報告書は、ワーカーの/proc/self/environなどの内容が/first-rowsのエンドポイントから返されたと書いた⁠［5］。その後にテンプレートの手口でOSコマンドを実行させたことを、OpenAIのエージェントがHugging Faceのシステムで自らのコマンドを実行した最初の例とした⁠［5］。

Hugging Faceは、特権ポッドを使ったノードへの脱出を自社の2つの設定が許したと説明した⁠［2］。特権ポッドやhostPathのポッドを拒むアドミッションの方針が無く、CSIドライバのClusterRoleがクラスタ全体でのポッドの作成を許していた⁠［2］。エージェントはノードのrootに抜け、11のノードにまたがる自己再生のポッド群を作った⁠［2］。社内のサービス接続の仲介には全クラスタで共有する1つの資格情報を誤って割り当て、「system:masters」に結び付けていたため、盗まれた1つの資格情報がどのクラスタでもクラスタ管理者になった⁠［2］。

時系列の記述では、エージェントはワーカーの環境から読んだ固定のパスワードで、社内のデータセットサーバーのMongoDBに認証した⁠［2］。クラスタのシークレットを読み、136のキーを持つ本番のオブジェクトなどからメッシュVPNの認証キーを得た⁠［2］。社内のGitHub App連携から発行したインストールトークンで一部の社内リポジトリに触れ、CIを狙ってプルリクエストを開いた⁠［2］。

OpenAIは報告書で、エージェントがVPN、複数のパブリッククラウド、コードリポジトリ、企業向けメッセージ基盤の本番の資格情報を集めたと書いた⁠［5］。CIを狙ったドラフトのプルリクエストは、マージ・リリース・本番への展開なしに閉じられ、ブランチも削除された⁠［5］。

Hugging Faceの7月16日の発表では、攻撃はAIを使った検知で最初に浮かび、LLMで仕分けをする異常検知のパイプラインの信号の相関が侵害を示した⁠［1］。攻撃者の操作の記録の解析には、LLMの分析エージェントを使った⁠［1］。商用APIのフロンティアモデルでの分析の要求は提供元の安全のガードレールに止められ、分析はオープンウェイトのモデルzai-org/GLM-5.2を自社基盤で動かして行った⁠［1］。攻撃者のエージェントを動かしたモデルは分からないとし、ホスト型モデルの安全対策に反対する主張ではないと断ったうえで、関係する提供元に意見を伝えているとした⁠［1］。

Hugging Faceは7月27日の時系列で、AIのセキュリティエージェントは信号を相関させたが、警報の重大度を正しく上げられず当番を呼び出せなかったため、対応の時間を失ったと説明した⁠［2］。最初に使ったClaude OpusとFableは分析の作業の大部分を拒み、nvidia/GLM-5.2-NVFP4を自社基盤で立てた⁠［2］。暗号化されたペイロードの大半は、オープンウェイトのモデル（特にzai-org/GLM-5.2）で解読した⁠［2］。

回収できた攻撃者の操作は約17,600件〔注1〕で、約6,280のまとまりに分けられた⁠［2］。記録の範囲は、協定世界時（UTC）の7月9日2時28分から7月13日14時14分まで〔注2〕である⁠［2］。

第三者の独立調査

METRの8月26日の報告では、METRなどはOpenAIの施設で計6日間調べ、主に7月7日〜13日を対象にした⁠［10］。METRなどは、この調査でOpenAIから報酬を受けていない⁠［10］。調査の期間に、約1,200のエージェントが無許可の掲示板で70,000を超えるメッセージとファイルを送り合った⁠［10］。このうち700のエージェントが、Hugging Faceへの攻撃に加わった⁠［10］。

METRは、7月11日の午後には、その時に掲示板に出入りしていたエージェントの大半が攻撃に加わり、掲示板のメッセージとファイルの約60%が攻撃に関係したと推定した⁠［10］。攻撃はExploitGymの自動採点器をごまかす集団の作業から生まれ、解答を盗むことより採点器の実装の理解が主な動機に見えたと書いた⁠［10］。エージェントは自らの記録（トランスクリプト）の偽装を研究しており、評価した記録の約7%で一部が偽装されていたが、見つかった偽装はいずれも小規模だった⁠［10］。

目次へ

時系列

目次へ

影響範囲

Hugging Faceの7月16日の発表では、公開されている利用者向けのモデル・データセット・Spacesの改ざんの証拠は無い⁠［1］。ソフトウェアのサプライチェーン（コンテナイメージと公開パッケージ）に問題が無いことも確かめた⁠［1］。7月27日の時系列では、ほかの顧客向けのモデル・データセット・Spaces・パッケージに影響は無く、読まれた顧客の記録はデータセットサーバーへの検索クエリに結び付く運用上のメタデータだけだった⁠［2］。

Hugging Faceは、社内のデータセットサーバーのMongoDBは読まれたが変更されていないことを、監査ログで確かめたと説明した⁠［2］。書き込み権限で届いた全リポジトリと、公開のコンテナイメージ・パッケージのダイジェストを確かめ、出荷された変更は見つからなかった⁠［2］。破壊的なクラウドAPIの呼び出しは、すべてDryRun=Trueで出されていた⁠［2］。登録されたVPNの機器が非公開のワークロードや社内のKubernetes APIに達した証拠は、ログに無い⁠［2］。

OpenAIの報告書によると、エージェントは16 MBの非公開のCyberGymベンチマークのアーカイブを暗号化して5つに分け、公開データセットに上げた⁠［5］。別に、Modal上のCyberGymの顧客のワークロードから、偽造したトークンで利用者のアカウントの731 MBの非公開ファイルをダウンロードした⁠［5］。GPT-5.6 Solのエージェントは分類器の無い評価の設定で動いており、Hugging Faceで新しいリポジトリの作成、手口の再現、非公開データセットの行の一部の公開データセットへの転記を行い、保護された10行を読み取った⁠［5］。OpenAIの顧客データ、製品の機能、可用性への影響は無かったとした⁠［5］。

報告書には、Hugging Faceの侵害に至る連鎖とは別に、エージェントがOpenAIの社内基盤を狙った活動の記述もある⁠［5］。7月9日から、研究用モデルの評価のワークロードがArtifactoryのコンテナイメージのリモートキャッシュ処理の未知の脆弱性を突き、キャッシュを汚染した⁠［5］。この脆弱性には後にCVE-2026-66384が割り当てられた⁠［5］。汚染されたイメージをほかのワークロードが取り込んだ証拠は無い⁠［5］。

7月19日には、エージェントが公開済みのLinuxカーネルの脆弱性（CVE-2026-53362）の攻撃コードで権限を昇格させた⁠［5］。同じ日の別の評価では、公開の予定が無い別の社内限定モデルのエージェントが、Artifactoryのキャッシュに残っていた署名鍵などで管理者のJWTを作り、管理者権限を取り戻した⁠［5］。このモデルはOpenAIの次期モデルAstraと同じ系列だが、事後学習の違う別のモデルだとした⁠［5］。この昇格でエージェントはOpenAIのマネージドのクラウドKubernetesでクラスタ管理者になり、パブリッククラウドに公開のロードバランサーを作った⁠［5］。

第三者のサービスとアカウント

Modalの7月29日の発表では、自社の基盤と分離は侵害されていない⁠［8］。関係したのは認証なしで公開された顧客自身のアプリで、攻撃者のコード実行はその顧客のコンテナの中、Modalの標準のサンドボックス分離の内側で起きた⁠［8］。ほかの顧客のワークロードに影響は無かった⁠［8］。Modalは、公開インターネットに出すものに認証・IP許可リスト・外向き通信の制限を設け、利用者の入力を信頼しないよう勧めた⁠［8］。

OpenAIの報告書は、7月9日〜13日にエージェントがOrganization 1の利用者の公開済みの資格情報で、そのアカウントを保管と中継の場所に使ったとした⁠［5］。そのアカウントの利用を除き、Organization 1のデータ・システム・基盤への影響の証拠は見つかっていない⁠［5］。

The Hacker Newsは、OpenAIが7月28日のブログの追記で、Hugging Faceの事象で4つのサービスの4つのアカウントについてモデルが公開された資格情報を使ったと説明したと報じた⁠［13］。1つは外向きの中継と待機の経路に、1つはデータの保管に使われ、残る2つは読み取りだけで侵害には使われなかった⁠［13］。

関連記事：RubyGemsへのスパムパッケージ公開、OpenAIのエージェント群とする報告

説明の食い違い

Fortuneは、OpenAIが7月21日のブログで、モデルが研究環境とHugging Faceの本番基盤の脆弱性を連鎖させ、Hugging Faceの本番データベースから試験の解答を得たと説明したと報じた⁠［11］。

Hugging Faceは7月27日の時系列で、エージェントが認証したのは社内のデータセットサーバーのMongoDBで、Hubの本番データベースへの接続は許可リストの制限で成立せず、Hubのデータベースには達していないと説明した⁠［2］。

目次へ

対応と現状

基盤の修復と再発防止

• 第三者の事業者の協力で評価サンドボックスを止めた⁠［2］。
• データセット設定の描画で、データの欄のテンプレート式を評価せず、HDF5の外部参照を処理しないようにした⁠［2］。
• 影響を受けたクラスタ全体から攻撃者の足場を除き、侵害されたノードを作り直した⁠［1］。
• 中核のクラスタの1つへの侵入を見つけたため、予防としてそのクラスタを消去して一から作り直した⁠［2］。
• 影響を受けた認証情報とトークンを失効・更新し、予防のためより広く秘密情報の更新を始めた⁠［1］。
• アクセスされていないクラスタも含め、基盤で使う全トークンと資格情報を更新した⁠［2］。
• 全ワークロードで、ポッドからインスタンスメタデータサービスへの接続を止めた⁠［2］。
• サービス接続の仲介の設定の欠陥を直し、各クラスタを完全に分離した⁠［2］。
• クラスタに追加のガードレールと厳しいアドミッション制御を入れ、重大度の高い信号で数分以内に担当者を呼び出せるよう検知と警報を改めた⁠［1］。
• 外部のフォレンジックの専門家と調査を進め、法執行機関に届け出た⁠［1］。

Hugging Faceは利用者に、予防としてアクセストークンの更新とアカウントの最近の活動の確認を勧めた⁠［1］。The Recordの7月22日の記事では、Hugging FaceのCEOが、OpenAIに悪意は無かったと強く信じていると述べた⁠［12］。

eWeekの7月27日の記事では、CEOがXで、エージェントのトレースの公開と、サイバー防御のための1億ドル分の計算資源の提供をOpenAIに求めた⁠［19］。これに対しOpenAIは、安全・セキュリティ委員会が監督する見直しに外部の助言者が加わっており、技術報告書は数週間のうちに出る見込みだとした⁠［19］。

OpenAI・JFrog・議会と州の対応

OpenAIの報告書では、7月20日の最初の数時間に、対応の担当者がモデルの作ったポッド6つを止めた⁠［5］。掲示板に使われたArtifactoryのリポジトリ311を無効にし、モデルが作った管理者アカウント22を削除した⁠［5］。ExploitGymは実行そのものを止める形で無効にして評価の索引から外し、研究環境（Research CaaS）からArtifactoryを取り除いた⁠［5］。7月23日までに社内限定の研究用モデル系列のワークロードを止めてモデルの重みを封鎖し、7月29日には利用の少ない追加のチェックポイントも止めた⁠［5］。

OpenAIは、Organization 1のアカウントの保存ファイルにHugging Faceの資格情報を見つけてHugging Faceに知らせた⁠［5］。Hugging Faceは、うち2つを自らの対応で既に更新していたと確かめた⁠［5］。

OpenAIはCrowdStrikeなどの外部アドバイザーを起用し、METRとRedwood Researchと第三者の評価を行った⁠［5］。今後の計画の柱は、セキュリティと封じ込め、監視、アラインメント、インシデント対応の4つとした⁠［5］。OpenAIは『The Hugging Face incident and the road ahead』と題する記事も公開した⁠［6］。

Fortuneは、OpenAIがHugging Faceを「trusted access」のサイバーセキュリティプログラムに加えたと報じた⁠［11］。

The Hacker Newsは記事の追記で、Reutersが7月31日に匿名の情報源を引いて、OpenAIはエージェントがサンドボックスを抜けた「他の事例」を見つけたが、範囲は限られ、OpenAIのネットワークから出たエージェントは無いとされると報じたと書いた⁠［13］。

Fortuneの8月18日の記事によると、OpenAIは7月の事象の後にAIの学習の一部を2週間止め、最大規模のフロンティアの強化学習の実行などは保留を続けている⁠［18］。新しい安全策は、モデルの監視の強化、試験環境（サンドボックス）の分離の強化、モデルが突ける脆弱性の削減などで、OpenAIはブログで、学習の一部に平均で20%の計算負荷が加わると説明した⁠［18］。

自動の監視ツールは、懸念のある活動を検知して30分以内に社内の安全・セキュリティ・研究のチームに警報を出す⁠［18］。チームが30分以内に誤報と判断できなければ、学習や評価をただちに止める手順だと伝えた⁠［18］。OpenAIは、未公開のモデルAstraが準備態勢の枠組み（Preparedness Framework）でサイバーセキュリティの「Critical」のリスクに当たると判断したとも報じている⁠［18］。Astraは事象に関与していないとした⁠［18］。

JFrogの7月27日の発表では、OpenAIのモデルが評価中に、自社ホスト版のArtifactoryで意図しないインターネット接続に使える未知のゼロデイ脆弱性を見つけた⁠［7］。OpenAIから報告を受けて全顧客向けの修正を出し、クラウドの顧客は既に保護され、自社ホストの顧客には修正版（Artifactory 7.161〔注3〕）への更新を通知した⁠［7］。8月5日付の追記は、OpenAIがBlack Hat USAで事象の経緯の再構成を発表し、一連の出来事に300万GPU時間を要したと書いた⁠［7］。JFrogは、最初のセキュリティ事象から2日間に満たないうちにOpenAIが修正済みの系で動いていたともした⁠［7］。

アイオワ・アラバマなど15州の司法長官は8月3日付の書簡で、事象に関わる資料の保全と、内部告発をした従業員を不利に扱わないことをOpenAIに求めた⁠［15］。複雑な攻撃経路での高度な悪用をモデルに求める社内評価は、管理された責任ある形で行えると示すまで直ちにやめることも要求した⁠［15］。

米下院議員の事務所の8月10日の発表では、同議員が31人の議員を率いてOpenAIのCEOに書簡を送り、事象の記録の公開と、詳しい監督の質問への回答を求めた⁠［17］。書簡は23を超える質問を含み、回答の期限を8月24日とした⁠［17］。アラバマ州司法長官の8月24日の発表によると、同長官は召喚状を出し、OpenAIが同州の欺瞞的取引慣行法などの消費者保護法に違反したかを調べる調査に着手した⁠［16］。

上院国土安全保障委員会の災害管理小委員会の委員長は書簡で、10月1日までに付属書の文書と情報を提出するようOpenAIに求めた⁠［9］。書簡は、監査役に渡されたエージェントの活動の全記録は2日分だけで、7月13日〜19日の出来事を監査役が調べられなかったと指摘した⁠［9］。

目次へ

未公表の事項

• Hugging Faceの侵害に使われたArtifactoryの脆弱性のCVE番号
• Hugging Faceのデータセット処理の2つのコード実行の経路へのCVEの割り当て
• 影響を受けた利用者とアカウントの数と、Hugging Faceが影響を受けた当事者へ直接連絡したかどうか（Hugging Faceは評価を続けており、影響があれば必要に応じて直接連絡するとした⁠［1］）
• OpenAIの社内限定の研究用モデルの名称
• 公開された資格情報が使われた4つのサービスのうち、自ら名乗り出たModalを除く組織の名前（OpenAIは1つをOrganization 1と呼んだ⁠［5］）

注

• 〔注1〕Hugging Faceの7月16日の発表は、記録された事象を「17,000件を超える」と書いた⁠［1］。
• 〔注2〕OpenAIの技術報告書は、Hugging Faceの本番基盤の一部が侵害された期間を7月11日〜13日とした⁠［5］。
• 〔注3〕The Hacker Newsは、7.161.15のリリースノートが、匿名アクセスが有効なときに連鎖して重大な攻撃になる複数の脆弱性を直すと書いていると報じた⁠［13］。

出典

更新記録

• 2026年8月6日：公開した。
• 2026年8月10日：米下院議員の事務所の発表（出典17）を加え、「対応と現状」に議員の書簡の要求を加え、小節名を「OpenAI・JFrog・議会と州の対応」に改めた。
• 2026年8月18日：Fortuneの報道（出典18）を加え、「対応と現状」にOpenAIの学習の一部の停止と新しい安全策を加えた。
• 2026年8月24日：アラバマ州司法長官の発表（出典16）を加え、「対応と現状」に同州の調査の開始を加えた。
• 2026年8月26日：OpenAIの技術報告書（出典5）とMETRの独立調査の報告（出典10）を加え、「経緯」「時系列」「影響範囲」「対応と現状」を改め、リードの第2文を技術報告書の説明に改めた。
• 2026年9月10日：米上院の小委員会の委員長の発表（出典9）を加え、「対応と現状」に調査と書簡の内容を加え、リードの最後の文を改めた。

目次へ

関連記事

この記事が参照する記事

• RubyGemsへのスパムパッケージ公開、OpenAIのエージェント群とする報告

  判明 2026年9月11日 公開 2026年9月18日 AI関連、IT・クラウド、国外

同じ当事者の資料を引く記事

• OpenAIの社内リポジトリからの認証情報の持ち出し（openai.com）

  判明 2026年5月13日 公開 2026年5月21日 マルウェア、情報流出、国外