攻撃はひとつのデータセットから始まった

起点となったのは、AIプラットフォーム特有の弱点であるデータ処理パイプラインだ。悪意あるデータセットが、データセット処理工程にある2つのコード実行経路を悪用し、処理を担当するマシン上でコードを実行させた。それ以降の各ステップは、ごく一般的な内部ネットワーク侵入の手口だった。

2つの侵入口は仕組みが異なるので、並べて見ると分かりやすい。

ここでひとつ、見ておくべき対比がある。Hugging Faceが全ユーザーに配布しているdatasetsライブラリは、2025年7月リリースのバージョン4.0.0でスクリプト形式のデータセットを完全に削除し、trust_remote_codeスイッチも同時に廃止した。公式が示す移行パスは、Parquetのような純粋なデータ形式への変換だ。つまり、新しいバージョンのライブラリを入れた一般ユーザーは、とっくに「データセットを読み込むついでにスクリプトを実行する」という経路を通れなくなっていた。ところが、プラットフォーム自身のバックエンド処理パイプラインでは、今回このタイプのコード実行経路がまだ使える状態にあった。初期侵入に使われたこの2つの経路は、現在すでに閉鎖されている。

はっきりさせておきたいのは、バックエンドパイプラインが同じdatasetsライブラリを使っていたかどうかを通知は明言しておらず、悪用されたのが4.0.0で封じられた経路と同一だとも述べていない、という点だ。上記の対比は両者の公開事実を並べたものであり、通知が出した結論ではない。

侵入してきたのは自律稼働するAgentフレームワークだった

攻撃側の正体はこうだ。自律的に段階を踏んで攻撃を進めるプログラムで、レッドチームや脆弱性研究向けに作られた既存の自動化ペネトレーションテストツールを改造したものと見られる。数万回に及ぶ動作は1台のマシンで行われたのではなく、大量の使い捨てマシンに分散して実行され、各マシンは数ステップをこなすと破棄された。背後の操作者との連絡経路は公共サービスの中に隠され、しかも自動的に移動していく。使用されたモデルが何かは、現在も不明のままだ。

この「既存ツールを改造した」という表現について補足すると、業界ではこうした既存ツールをharnessと呼ぶ。モデルを外側から包み込む一種の実行足場のことで、材料を与え、モデルに何を見せるかを決め、出力を解析し、また次のサイクルへと駆動していく役割を担う。モデルがエンジンだとすれば、harnessはシャーシとハンドルにあたる。同じエンジンでも、載せるシャーシが違えば成績は大きく変わる。

この2つの設計は同じ狙いに向かっている——一撃で断ち切れなくすることだ。使い捨てマシンはもともと使い終わったら捨てるものなので、1台封鎖しても意味がない。連絡経路は通常トラフィックに紛れ、しかも移動するため、固定アドレスをブロックしても止められない。

この特性はフォレンジック調査にも影響を及ぼす。マシンが使い終わって破棄されると、ディスクイメージやメモリスナップショットといった現場証拠も一緒に消える。振り返りに使えるのは、実質的にあの行動ログだけになる。だからこそ、後述する17000件超のイベントが、この攻撃全体を知る最も完全な記録となった（この関連づけは本サイトの推論であり、通知には明記されていない）。

前回公開されたAI主導型攻撃はどんなものだったか

これはまさに、業界が長らく警鐘を鳴らしてきた「自律的に攻撃を進める攻撃者」そのものだ。同種の事例として直近で詳しく公開されたのは、Anthropicの脅威インテリジェンスチームが明らかにしたGTG-1002で、2025年9月中旬に検知されたものだった。両者では自動化の度合いが異なる。以下の表はサイト外の補足資料。

Hugging Faceはどうやってこの侵入を解明したのか

防御側のAIは2つの場面で使われた。ひとつは検知、もうひとつは再構築だ。

検知の側では、システムが日々出力する動作ログを常時監視するAI当直プログラムを稼働させ、日常的なノイズの中から本物のシグナルを拾い上げている。最終的に複数のシグナルが結びついたことで、今回の侵入が浮かび上がった。

分析Agentが17000件超のイベントからタイムラインを組み立てた

数万回に及ぶ自動動作が実際に何をしたのかを解明するため、Hugging Faceは分析Agentに攻撃者の行動ログ全件、合計17000件超のイベントを処理させた。ひと通り処理を終えると、同時に4つの成果物が得られた。

最後の項目こそが、今回の作業量のカギを握っている。攻撃側はおとり動作を紛れ込ませており、実際の影響と攪乱用の動作を切り分ける作業は、人手では最も時間を食う部分だ。しかも、おとりを仕込むコストは人間と機械でまったく違う。人間の攻撃者は偽の動作をひとつ増やすたびに自分の時間を費やすが、自動で動くAgentならいくつ増やしても限界コストはほぼゼロに近い（このコストの層は本サイトの推論であり、通知にはおとり動作が存在したとしか書かれていない）。

AIによる処理を経て、本来なら数日かかる作業が数時間に圧縮され、相手のスピードに追いつけるようになった。

フォレンジック調査で商用モデルが処理を拒否した理由

今回の事故で実際にHugging Faceの足を止めたのは、自分たちが料金を払って使っているモデルそのものだった。通知の原文によれば、この分析に使えるモデルが制限された形は「我々が予期していなかったもの」だったという。

ログ分析を始めた当初、Hugging Faceは商用API上の最強クラスのモデルを使っていた。しかしうまくいかなかった。この種の分析でモデルに流し込む必要があるのは、大量の実際の攻撃コマンド、侵入に使われた攻撃コード、そして連絡経路が残した痕跡そのものだ。安全ガードレールはこうした内容を見た瞬間に拒否する。しかもそれを提出しているのがインシデント対応のエンジニアなのか、攻撃者本人なのかを見分けることができない。

自社インフラ上でモデルを動かし、このガードレールを回避した

Hugging Faceは最終的に、フォレンジック分析をGLM 5.2に切り替え、自社インフラ上で動かした。これはZhipu AI（Z.ai）が開発したオープンウェイトモデルで、重みはMITライセンスで公開されており、ダウンロードして自前でデプロイできる。誰かにこの材料を提出していいか承認を求める必要もない。学習データと完全なパイプラインは非公開なので、オープンソースではなくオープンウェイトという位置づけになる。

自社マシンで動かすことには、ガードレールに阻まれないこと以外にもうひとつの利点がある。Hugging Faceがわざわざ言及しているのは、攻撃者データとそこに含まれる認証情報が、一度も自社ネットワークの外に出なかったという点だ。事故のフォレンジック調査で認証情報入りのログを外部APIに送ること自体が、新たな漏洩リスクになる。

これはホスト型モデル上の安全対策に反対しているわけではない。我々はこのフィードバックを関連するサービス事業者にも共有しているところだ。 Hugging Faceセキュリティ事故通知

オープンウェイトモデルに切り替えると、セキュリティ分析の精度は落ちるのか

サイト外に参考になる独立ベンチマークがある。Semgrepが同一のIDOR（アクセス制御不備）脆弱性データセットと同一のプロンプトで一連の構成をテストしたところ、GLM 5.2は専用のharnessを一切使わず、プロンプト1本だけの条件でF1スコア39%（F1は適合率と再現率を統合したスコアで、検出したもののうちどれだけが本物か、本物のうちどれだけを検出できたかを表す。満点は100%で数値が高いほど良い）を記録し、自社のAgent harness上で動かしたClaude Codeを上回った。

したがって防御側への提言はひとつに尽きる。事故が起きる前に、自社インフラ上で動かせるモデルを選定・検証しておくことだ。そうすればガードレールに阻まれることも、攻撃者データや認証情報が外部に流出することも避けられる。

Hugging Faceはどの穴を塞ぎ、ユーザーは何をすべきか

事後対応として、合計5つの措置が取られた。

• 根本原因となった脆弱性を修正：初期侵入に使われた2つのデータセットコード実行経路は既に閉鎖済み。
• 影響を受けたクラスタ内にあった攻撃者の拠点を排除し、侵害されたマシンを再構築。
• 影響を受けた認証情報とトークンを失効・ローテーションし、あわせてより広範囲の予防的なキーローテーションを実施。
• クラスタに追加の防御措置とより厳格なアクセス制御を導入。
• 検知とアラートを強化し、高リスクなシグナルが出れば週末でも数分以内に当直担当を呼び出せるように改善。

さらに、外部のサイバーセキュリティフォレンジックチームに調査への参加を依頼し、セキュリティ方針とプロセスの見直しを行った。また、この事件はすでに法執行機関に報告済みだという。

ユーザーおよび防御側が取るべきアクションを、以下のチェックリストにまとめた。最初の3項目は一般ユーザー向け、後の2項目は企業のセキュリティチーム向けだ。

最後に、いくつかの判断を書き留めておく。自律的に攻撃を進めるAI攻撃ツールは、もはや仮説の段階ではない。以前なら、広範囲かつ長期間、複数段階にわたる攻撃を仕掛けるにはコストが高くついたが、そのコストは今や大きく下がり、しかもすべてが機械のスピードで動いている。オンラインプラットフォームにとって、ユーザーがアップロードするデータセットやモデルファイルは、これまで主に「処理待ちのコンテンツ」として扱われてきたが、今後は「毒を含んでいるかもしれない入力」として防御対象にしなければならない。防御側についても、人手でログを見張るスピードはもはや機械に追いつかず、AIを活用せざるを得なくなっている。

7月16日、Hugging Faceが通知を発表：同じ週の早い時期に、外部向けサービスを提供する内部システムの一部が侵入を受けた。以前ならこの種の作業はひとりがキーボードの前に張り付いて一歩ずつ進めるものだったが、今回は最初から最後まで人の手が入らず、AIプログラムが自ら攻め切った。

攻撃チェーンは5ステップ：毒入りデータセットを送り込む → それを処理するマシン上でコードを実行 → マシン全体の権限へ昇格 → クラウドとクラスタの認証情報（他のマシンへ進むための鍵）を奪取 → その鍵を使って複数の内部クラスタへ横展開。ステップ3から5までは、すべて週末のうちに起きた。

確認済みの影響は、一部の内部データセットと複数のサービス認証情報。公開モデル、データセット、Spacesに改ざんの痕跡は見つからなかった。本当の問題は次のステップ、つまりHugging Faceがこの17000件超のログを調査しようとした時に起きた。

攻撃者が何をしたのかを解明するには、実際に打ち込まれたコマンドや侵入に使われた攻撃コードを丸ごとモデルに読み込ませる必要がある。ところが商用モデルの安全ガードレールはこうした内容を見た瞬間に拒否し、それを提出しているのが火消し役のエンジニアなのか攻撃者本人なのかを見分けられない。

17000件を超える行動イベントを、人が1件ずつ追うと数日、AIが1回処理すると数時間。しかも単純に一読するだけの作業ではない。攻撃側は偽の動作も紛れ込ませており、実際の影響と攪乱動作を切り分ける作業自体が、人手では最も時間を食う部分だ。

オープンモデルへの切り替えは、妥協を意味するわけではない。Semgrepが2026年7月に実施したアクセス制御不備の検出ベンチマークでは、GLM 5.2はプロンプト1本だけで39点を記録し、自社harnessで動かしたClaude Code（32点）を上回った。ただしこれは単一タスク・単発実行の結果であり、今回の事故のデータではない。