Hugging Face、自律型 AIエージェントによる侵害を公表

AI・機械学習分野で45,000以上のモデルを公開し、5万を超える組織が利用するプラットフォームHugging Faceは2026年7月16日、自社の本番インフラの一部への侵入を検知・対応したと公式ブログで公表しました。

今回の事案がこれまでのインシデントと決定的に異なるのは、侵入の実行が最初から最後まで自律型AIエージェントシステムによって行われていた点です。同社はこれを業界がかねてより予測してきた、いわゆるエージェント型攻撃者のシナリオに合致する事案だと位置づけています。皮肉なことに、この攻撃をフォレンジック分析する過程では、商用の大規模言語モデル(LLM)が持つ安全ガードレールが攻撃者と対応者を区別できず、Hugging Face自身の調査作業を阻んでしまうという事態も発生しました。

サマリー

• Hugging Faceは2026年7月16日、本番インフラの一部への侵入を検知・対応したと公表しました。侵入は最初から最後まで自律型AIエージェントシステムによって実行されていました
• 限定された内部データセットと、複数のサービスで使用される認証情報への不正アクセスが確認されています。パートナーや顧客データへの影響については調査継続中です
• 一般公開されているモデル・データセット・Spacesへの改ざんの痕跡はなく、コンテナイメージや公開パッケージを含むソフトウェアサプライチェーンもクリーンであることを確認済みとしています
• 侵入は悪意あるデータセットを介してデータ処理用のコード実行脆弱性2件(リモートコード実行型のデータセットローダーと、データセット設定におけるテンプレートインジェクション)を悪用する形で開始されました
• 攻撃は数千件の個別アクションを、次々と生成される短命なサンドボックス群にまたがって実行する自律エージェントフレームワークによって実行されており、指揮統制(C2)は公開サービス上を自己移動する形で維持されていました
• Hugging Faceは攻撃者のログ(1万7,000件超のイベント)をLLM駆動の分析エージェントで解析しましたが、商用APIの大規模言語モデルは攻撃コマンドやエクスプロイトのペイロードを安全ガードレールでブロックしてしまったため、オープンウェイトモデルGLM 5.2を自社インフラ上で稼働させて分析を行いました
• 同社は、防御側もインシデント発生前からあらかじめ自社インフラで運用可能な高性能モデルを検証・準備しておくことが、ガードレールによる分析の停滞を避け、攻撃者由来のデータや認証情報を自社環境の外に出さないための教訓になると述べています

整理表

何が起きたか-データ処理パイプラインを突いた侵入

Hugging Faceによると、侵入はAIプラットフォーム特有の露出点であるデータ処理パイプラインから始まりました。悪意あるデータセットが、データセット処理におけるコード実行の経路2つ(リモートコードを許容するデータセットローダーと、データセット設定内のテンプレートインジェクション)を悪用し、処理ワーカー上でコードを実行させました。ここを足がかりに、攻撃者はノードレベルのアクセスへと権限を昇格させ、クラウドおよびクラスターの認証情報を窃取したうえで、週末をまたいで複数の内部クラスターへ横展開していきました。

同社はこの一連のキャンペーンについて、エージェント型のセキュリティリサーチ用ハーネスを基盤に構築されたとみられる自律エージェントフレームワークによって実行されたと説明しています。使用された大規模言語モデルが何であったかは本稿執筆時点でも判明していません。このフレームワークは、次々と生成される短命なサンドボックスの群れにまたがって数千件もの個別アクションを実行し、指揮統制(C2)は公開サービス上を自己移動する形で維持されていました。Hugging Faceはこれを、業界がかねてより予測してきたエージェント型攻撃者のシナリオに合致する事案だと位置づけています。

Hugging Faceの対応

Hugging Faceは対応として、初期侵入に使われたデータセットのコード実行経路を閉塞し、侵害を受けたクラスター全体から攻撃者の足がかりを排除したうえで、侵害されたノードを再構築しました。影響を受けた認証情報・トークンはすべて失効させたうえでローテーションし、それにとどまらず予防的な観点からより広範なシークレットのローテーションも開始しています。あわせて、クラスターに対する追加のガードレールとより厳格なアドミッション制御を導入し、重大な兆候を検知した際には曜日を問わず数分以内に対応者へ通知が届くよう検知・アラート体制も改善しました。

同社は外部のサイバーセキュリティフォレンジック専門家と連携して調査を継続しているほか、本件を司法機関へ通報済みであることも明らかにしています。利用者に対しては、予防措置としてアクセストークンのローテーションと、自身のアカウントにおける直近のアクティビティの確認を推奨しています。

AIを使ったフォレンジック分析-1万7,000件のイベントを数時間で解析

今回の事案でとりわけ興味深いのは、Hugging Face自身がこの攻撃を検知・解析する過程で、大きくAIに依存していた点です。同社の異常検知パイプラインは、セキュリティテレメトリに対するLLMベースのトリアージを用いて日々の大量のノイズから本物の兆候を見分けており、これらの兆候の相関関係から今回の侵害が発覚しました。

攻撃者による数万件にも及ぶ自動化されたアクションが何を行ったのかを理解するため、Hugging Faceは1万7,000件を超える記録済みイベントからなる攻撃者のアクションログ全体に対し、LLM駆動の分析エージェントを走らせました。これにより、タイムラインの再構築、侵害指標(IOC)の抽出、影響を受けた認証情報のマッピング、そして実際の被害とおとりの活動の切り分けを行うことができ、通常であれば数日を要する作業を数時間で終えることができたとしています。

ガードレールの非対称性という新たな課題

もっとも、この分析に使用するモデルの選択肢は、同社が予想していなかった形で制約を受けました。ログ分析の初期段階では商用APIを介したフロンティアモデルを使用しましたが、これはうまくいきませんでした。分析には実際の攻撃コマンド、エクスプロイトのペイロード、C2の痕跡といった大量のデータを提出する必要がありますが、これらのリクエストがモデル提供事業者側の安全ガードレールによってブロックされてしまったのです。ガードレールは、インシデント対応者と攻撃者を区別することができません。

そこでHugging Faceは、オープンウェイトモデルであるGLM 5.2を自社インフラ上で稼働させ、フォレンジック分析を実施しました。これには副次的な利点もありました。攻撃者由来のデータや、そこに含まれる認証情報が一切自社環境の外に出ることがなかった点です。

同社はこの経験について、計画しておくべきギャップだったと振り返っています。攻撃者のエージェントを動かしていたモデルが、ジェイルブレイクされたホスティングモデルだったのか、あるいは制約のないオープンウェイトモデルだったのかは分かっていません。いずれにせよ攻撃者はいかなる利用ポリシーにも縛られていなかった一方で、防御側であるHugging Face自身の調査作業は、最初に試みたホスティングモデルのガードレールによって阻まれてしまいました。同社はこれを踏まえ、防御側にとって実践的な教訓は、インシデントが発生する前に、自社インフラ上で運用できる十分な性能を持つモデルを検証し準備しておくことだと述べています。これにより、ガードレールによる分析のロックアウトを回避できるだけでなく、攻撃者データや認証情報を自社環境の外に出さずに済むとしています。なお同社は、これはホスティングモデルの安全対策そのものへの反対を意味するものではないとしたうえで、この経験から得たフィードバックを該当するモデル提供事業者と共有しているとも付け加えています。

業界が予測してきた「エージェント型攻撃者」の到来

Hugging Faceは今回の事案が示す意味について、自律的でAI駆動型の攻撃ツールはもはや理論上の存在ではないと総括しています。こうしたツールは、広範かつ辛抱強い多段階のキャンペーンを実行するコストを引き下げ、人間ではなく機械の速度で動作します。オンラインプラットフォームを防御するということは、今やデータとモデルの表面そのものを第一級の攻撃対象として扱い、防御側もAIを活用して攻撃側の速度に対応することを意味すると同社は述べています。

過去にもあったHugging Faceを巡るセキュリティインシデント

Hugging Faceにとって、AIエージェントが関与したセキュリティインシデントが確認されたのは今回が初めてですが、同社関連のセキュリティ事案はこれが最初ではありません。2年前には、Spacesプラットフォームへの侵害を受けて一部メンバーの認証シークレットを失効させ、より安全なきめ細かいアクセストークンへの切り替えを推奨した経緯があります。当サイトでも既報のとおり、Hugging Face上では過去にバックドアを仕込まれた機械学習モデルが発見されたこともあり、脅威アクターが同プラットフォームを悪用して悪意あるAI・機械学習モデルや情報窃取マルウェアを配布したり、大量のAndroidマルウェアの亜種を拡散したりする事例も報告されてきました。オープンなAI・機械学習プラットフォームという性質上、モデルやデータセットの共有機能そのものが攻撃の踏み台にされやすいという構造的な課題を、同社は繰り返し経験していることになります。

情報システム部門への示唆

今回のHugging Faceの事例は、2つの異なる意味で情報システム部門にとって重要な示唆を含んでいます。

1つ目は、攻撃側における自律型AIエージェントの実用化が、もはや将来の懸念ではなく現実の脅威になりつつあるという点です。数千件のアクションを短命なサンドボックス群にまたがって自動実行し、C2基盤すら自己移動させるという手口は、人手による対応速度を前提とした従来の防御体制では追いつきにくい水準に達しています。

2つ目は、インシデント対応そのものにAIを活用しようとする際に直面し得る、ガードレールの非対称性という新しい課題です。攻撃者が利用ポリシーに縛られない一方で、防御側が正規に契約している商用AIサービスは、悪意あるコードやエクスプロイトの内容を含むフォレンジック分析の依頼そのものを、安全機構によってブロックしてしまう可能性があります。

自社のインシデント対応計画にAI活用を組み込む場合は、平時のうちに自社インフラ上で運用可能なオープンウェイトモデルを検証し、実際にインシデントが発生した際に速やかに切り替えられる体制を整えておくことが、Hugging Faceの経験から得られる具体的な教訓です。あわせて、攻撃者由来の機密データや認証情報を外部の商用APIに送信せずに分析を完結できるという点は、フォレンジック分析における情報漏えいリスクの観点からも重要な考慮事項です。

出典

• • Security incident disclosure — July 2026 – Hugging Face公式ブログ
  • Hugging FaceでAIのバックドア付き機械学習モデルを確認 – セキュリティ対策Lab

関連記事

Hugging FaceでAIのバックドア 付き 機械学習モデルを確認 自律型 AI エージェント OpenClawに4つの脆弱性「Claw Chain」-CVSS 9.6のサンドボックス脱出を含む4件をチェーンしてデータ窃取・権限昇格・恒久バックドア設置が可能 フィッシング経由で1.7万件のクレカ情報が不正売買、警察庁、集中取締りで20人を検挙 日本大学、在学生・卒業生9名のメールアカウントへ不正アクセス 1万7,864件の不審メールを送信 Pythonのパッケージ「llama_cpp_python 」で重大な脆弱性（CVE-2024-34359） OpenAI、個人情報を自動マスキングするOSS型AI「Privacy Filter」をApache 2.0で公開 Microsoft、破壊専用の新型バックドア GigaWiperを警告-偽ランサムウェアやディスク完全消去でWindows PCを完全破壊 米国の対イラン作戦でサイバー領域が先行-作戦開始前にサイバー攻撃で対象の通信・センサー網を攪乱 AI ボイス クローニングを用いたボイスフィッシングで家族の声を偽装し脅迫—日本のオレオレ詐欺にも応用される可能性

投稿者：三村

セキュリティ製品を手がける上場企業にて、SOC（セキュリティオペレーションセンター）運営およびWebアプリケーション脆弱性診断の営業に8年間従事。その後、システムエンジニアへ転身し、MDMや人事系SaaSの開発に携わる。
8年の実務経験と開発者としての知見を活かし、「セキュリティ対策Lab」ではダークウェブ調査、セキュリティインシデントの分析、および高度なセキュリティ対策解説の執筆・編集を統括しています。
LinkedIn(外部サイト)