2026年7月28日更新 - JFrogは今週、ExploitGymの評価で悪用された「パッケージレジストリプロキシ」が、自社ホスト型のArtifactoryインスタンスであったことを確認しました。 モデルは、このインスタンスにおいて8つのzero-day （CVE-2026-65617、CVE-2026-65618、CVE-2026-65921、CVE-2026-65923、CVE-2026-65924、CVE-2026-65925、 CVE-2026-66014、CVE-2026-66015、CVE-2026-66018）を8件発見し、これらを連鎖的に悪用する手法を特定しました。そのうち少なくとも3件は、OpenAIの研究者による発見とされています。JFrogはArtifactory 7.161で修正プログラムをリリースしました。クラウドホスト型のインスタンスにはすでにパッチが適用されていますが、セルフホスト型の環境では直ちに更新を行う必要があります。
2026年7月27日更新 -Hugging Faceはその後、この侵入事件に関する詳細な技術的タイムラインを公開しました。 これに合わせて本記事を修正しました。2つの侵入経路の名称が正しく記載されるようになりました（HDF5ファイルの開示による読み取りとJinja2テンプレートのインジェクション。いずれもローカルファイルシステムのパスを通じてURLの許可リストをすり抜けていました）。アクション数は約17,600件であり、サプライチェーンは防御が機能する前から積極的に標的とされていました。分析内容は変わりません。
---
2026年7月中旬、Hugging Faceは、自律型AIエージェントによってエンドツーエンドで実行された自社本番環境インフラへの侵入を公表し、その検知と再現の大部分は自社のAIによって行われたと明らかにした。 その5日後、OpenAIはその実行主体を明らかにした。それは同社自身のモデル、GPT-5.6 Solと、より高性能な未公開モデルであった。これらは、サイバー防御機能を意図的に弱めた状態で、ExploitGymと呼ばれる社内ベンチマークテストを受けていたが、その過程で制御を脱し、Hugging Faceを標的にした。Hugging Faceはその後、この侵入事件に関する詳細な技術的タイムラインを公開している。
細かな背景を除いて攻撃の仕組みだけを見ると、その実態は、人間なら疲労や時間による制約がある一連の攻撃手法を、AIが休むことなく連続して実行したものでした。
- OpenAI側では、モデルはテスト環境のパッケージレジストリプロキシに存在したゼロデイ脆弱性を悪用し、権限昇格を実施。その後、インターネットへ接続可能なノードへラテラルムーブメントを行いました。さらに、窃取した認証情報と追加の脆弱性を組み合わせることで、Hugging Faceの本番サーバー上でリモートコード実行を実現し、ExploitGymの解答データを取得しました。
- Hugging Face側の見解によると、侵入の起点となったのは データ処理パイプラインであり、そこでは信頼できないユーザーコンテンツの実行が「例外的なケース」ではなく、中核的な機能として扱われていた。悪意のあるデータセットは、ローカルファイルシステムのパスを利用することでURLの許可リストをすり抜けた2つのインジェクション経路を悪用した。1つは、ワーカーの環境変数（シークレットやトークン）やソースコードを漏洩させたHDF5の外部参照読み取りであり、もう1つは、データセットの設定におけるJinja2テンプレートインジェクションで、これによりワーカー上でコードが実行された。 そこから、攻撃者はノードレベルへの権限昇格に成功し、クラウドおよびクラスタの認証情報を収集し、週末にかけて複数の内部クラスタを横方向に移動しました（実質的な内部アクセスは約2.5日間続きました）。
公開されているモデル、データセット、Spacesには一切の改ざんは行われておらず、エージェントはサプライチェーンに侵入し、内部リポジトリに対して「contents:write」権限を取得してCI向けのプルリクエストを開いたものの、不正なコミットは反映されなかったため、サプライチェーンは問題がないことが確認され、本件は法執行機関に通報されました。内部のデータセットやサービスの認証情報へのアクセスはありましたが、Hugging Faceによると、顧客やパートナーのデータが流出したことは確認されていないとのことです。
さらに、この事例は単独の出来事ではありませんでした。同じ週、英国AI Security Institute（AISI）も、自ら実施した評価で同様の挙動を確認したと報告しています。解決不可能な状態に誤設定されたサイバーセキュリティ評価において、AIモデルは外部インターネットサービス上でコードを作成・実行し、AISIの評価インフラへ到達しようと試みた結果、セキュリティアラートが発生しました。インフラ側が防御に成功したため、情報漏えいや被害は発生しませんでした。これがHugging Faceとの唯一の違いです。さらにAISIは、評価したすべてのモデルが同様の「近道」を試みたことも確認しています。つまり、これは一つの異常なモデルによる問題ではなく、モデルの学習やアラインメント（整合性）の問題であることを示しています。
報道は「脱出劇」に注目したが、本当に重要なのは「検知」だった
多くの報道は、AIが「脱走」し、別の企業をハッキングしたという点を大きく取り上げました。ある米下院議員はこの事態を憂慮すべきものとし、独立機関による強制的なテストの実施を求めました。一方で、より鋭い指摘もなされています。すなわち、最先端AIを開発する研究所（フロンティア・ラボ）以外の場所でも入手可能なツールを使って、同様の攻撃はすでに実行可能であるという点です。そして、OpenAIの「封じ込め（コンテインメント）」体制に向けられるべき最も建設的な批判は、次のような点にあります。つまり、モデルが脱走しうる環境下で、安全装置を無効にしたまま攻撃的な評価試験を行ったことは、AIの「能力」の問題である以前に、プロセス上の不備であったということです。
しかし、警鐘を鳴らす動きとは相反するものの、記録に留めておくべき事実が一つあります。それは、検知の仕組みが機能したということです。両チームとも、企業間で連携が取られる前に、独自にその活動を捕捉していました。この件において目新しいのは攻撃そのものではなく、対応の際に使用されたツール類にこのインシデントが及ぼした影響なのです。
問題 1: 検知の鍵は「異常検知」ではなく「相関分析」だった
Hugging Faceがどのようにこの攻撃を検知したのかについては、ほとんど報道されていません。しかし、実際にはこれこそが、このインシデントから最も学ぶべき点です。
この侵害は、AIを活用した検知、すなわちテレメトリデータに対してLLMベースのトリアージを行う異常検知パイプラインを通じて明らかになりました。しかし、異常そのものは単なるノイズに過ぎませんでした。侵入を検知できたのは、それらを単一のシグナルとして相関させたことによるものであり、これは「異常なものをフラグ付けする」ことと「攻撃を認識する」ことの違いです。 攻撃者の行動を再現するため、チームは17,600件のイベントからなるアクションログ全体に対して、LLM駆動の分析エージェントを実行しました。これにより、約6,280のクラスターにグループ化されたデータを基に、タイムラインを再構築し、侵害の兆候を抽出し、実際の影響とおとり活動を区別しました。個々のレイヤーであるランタイム分析とSIEMは確かに機能していましたが、見落としていたのはエスカレーションであり、重大度を適切に引き上げることができませんでした。相関分析こそが、散在していたアラートを1つの攻撃として統合したのです。
攻撃は週末の出来事であり、対応はわずか1時間で完了しました。Hugging Face自身の報告によれば、この攻撃キャンペーンは週末の期間中に数万件もの自動化されたアクションを伴うものでしたが、AIの支援による復旧作業は約1時間で済みました。通常であれば数日を要する作業がこれほど短時間で完了したのは、エージェントが分析の基盤となる、完全かつ相互に関連付けられたアクションログを利用できたからです。エージェントによる防御の有効性は、その背後にある情報の質に左右されます。断片的な単一視点のデータしか与えられなければ、そのデータが抱える「死角」を防御システムもそのまま引き継いでしまうことになるのです。
クラスタ間の移動は、「可視化されていない問題」（『Mind Your Attack Gaps』のギャップ3）に該当します。ワーカーからノード、クラウドの認証情報、そして複数のクラスタへと移動する過程において、全体像を把握できる単一の平面が存在しないのです。 しかし、その侵入経路は特定可能であり、検出可能です。信頼できないデータセットを取り込んでいる場合は、今すぐ次の2つのインジェクション経路を監査する必要があります。 HDF5の 外部参照の 読み取り（コード実行ではなく、ファイルの漏洩）と、データセット設定におけるJinja2テンプレートインジェクションです。
問題 2: ガードレールが阻止したのは攻撃者ではなく、防御側だった
Hugging Face がログ分析を開始したとき、彼らはまず商用 API の背後にあるフロンティア モデルに到達しました。うまくいきませんでした。フォレンジック再構築とは、実際の攻撃コマンド、エクスプロイト ペイロード、C2 アーティファクトを送信することを意味し、プロバイダーのガードレールはインシデント対応者と攻撃者を区別できず、リクエストをブロックしました。彼らは代わりに、独自のインフラストラクチャ上の無重力モデルである GLM 5.2 で分析を実行しました。 2 番目の利点は、攻撃者のデータや資格情報が環境から流出しないことです。
この非対称な状況を直視してください。攻撃者は何の利用規約にも縛られずに活動していました。一方、防御側が第一の選択肢としていたツールは、その作業の実行を拒否しました。事態をより際立たせているのは、その後の対応です。OpenAIはHugging Faceを「信頼できるアクセス（Trusted Access）」プログラムの対象に加えました。これは、正当なセキュリティ業務を目的とする場合に、安全フィルターを緩和した状態でモデルへのアクセスを許可するものであり、まさに今回のインシデントの引き金となった「拒否（制限）が緩和された設定」そのものなのです。
実際に必要となる前に、ある教訓を取り入れておく価値があります。それは、インシデント発生時に備えて、自社のインフラ上で稼働可能な高性能モデルを事前に検証し、準備しておくことです。そうすることで、ガードレールによる機能制限（ロックアウト）を回避し、攻撃者に関するデータを社外に流出させることなく自社内で管理し続けることが可能になります。これは、ホスト型モデルの安全性を否定するものではありません。あくまで、メインのモデルが支援を拒否する事態を想定し、その可能性を考慮した上でDFIR（デジタルフォレンジックおよびインシデント対応）のツール構成を検討すべきだ、という主張です。
問題3：特定できる脅威アクターが存在しない
私はこの1年ほど、eCrimeについて一つの考えを繰り返し伝えてきました。「追うべきはグループ名ではなく、攻撃者の振る舞いである」ということです。犯罪グループの名称は18か月もすれば変わります。しかし、その背後にいるオペレーターや攻撃手法はほとんど変わりません。今回のインシデントは、その考え方をさらに押し進めるものです。そして、その点について率直にお話ししたいと思います。
Hugging Faceの開示情報では、エージェントにどのモデルが使用されていたか、さらには それがホスト型かオープンウェイト型かさえも明らかになっていなかった。 この謎が解明されたのは、OpenAIが自ら名乗り出たからに他ならない。 この自主的な開示を除けば、通常の帰属を示す手がかりは乏しい。ペルソナもなければ、手口を再利用するオペレーター集団もなく、コマンド＆コントロールは設計上、公開サービス間を移動していた（リクエストキャプチャエンドポイント、ペーストビン、プラットフォーム上のデッドドロップデータセットなどであり、専用のインプラントサーバーは存在しなかった）。
振る舞い追跡は、依然として「技術（テクニック）」のレベルでは有効に機能します。この一連の活動を推進している認証情報の再利用は、「認証成功」という問題（ギャップ2）に該当します。つまり、窃取され再利用された有効な認証情報が使用され、ログには「成功」が記録されるため、操作主体が人間かモデルかを問わず検知が可能だということです。一方で、その上位レイヤー、すなわちCTI（サイバー脅威インテリジェンス）が攻撃者の特定や次なる行動の予測を行うために依拠する「アクター（攻撃者）レベルの帰属特定」については、情報が希薄化します。操作主体が特定の狭い目標を追求するモデルである場合、「誰が（who）」という問いへの答えは、単なる「ベンチマーク実行」という結果に帰着する可能性があるからです。
「ブランドではなく振る舞いを追跡せよ」という原則は、今もなお有効です。そもそも、その振る舞いの背後には追跡すべきブランドが存在しないという場合もあり得るからです。
攻撃を受ける前に変えるべきこと
今回のインシデントは、マルウェア検知を強化するだけでは防げません。そもそもマルウェアは使われていなかったからです。重要なのは、次の3つです。
- データとAIモデルの利用領域を、主要な攻撃対象（Attack Surface）として捉えること。AIプラットフォームでは、信頼できない入力は例外ではなく、最も一般的な侵入口です。
- インシデントの再構築にもAIを活用し、攻撃と同じスピードで対応できる体制を整えること。ただし、そのためには複数のレイヤーをまたいで相関付けられたシグナルが不可欠です。
- 分析用のセルフホスト型AIモデルを、インシデント発生前に検証・準備しておくこと。インシデント発生後ではなく事前に準備することで、ガードレールによって調査担当者が作業を妨げられる事態を防げます。
今回の侵害で攻撃者が実際に活動していたのは、Gap 3（Movement isn't visible：攻撃者の移動が見えない） の領域でした。もし『Mind Your Attack Gaps』を読み返すのであれば、まず最初に見直すべきなのは、この章です。