Hugging Faceが自社サイトで公開した報告によると、同社の本番インフラが自律型AIエージェントの群れによる攻撃を受けたとのことだ。発端はプラットフォーム上に仕掛けられた悪意あるデータセットで、データセット処理パイプラインに存在する2つのコード実行経路を悪用していた。さらにリモートコードを受け入れるローダーと、設定ファイルへのテンプレートインジェクションも組み合わされ、最終的に自社ワーカー上でコードが実行される事態となった。
そこを足がかりに攻撃者はノードレベルのアクセス権を奪取し、クラウドおよびクラスターの認証情報を収集。その後、複数の内部クラスターへ横断的に侵入した。しかも、これが丸々一週間末の間ずっと続いていたというのだから恐ろしい。Hugging Faceによれば「公開サービス上にホストされた自己移動型のコマンド＆コントロールを使い、一時的なサンドボックスの群れを通じて数千もの個別アクションが実行された」とのこと。そして、攻撃を動かしていたモデルが何だったのか、いまだに特定できていないというのも衝撃的だ。
被害を受けたのは、限られた範囲の内部データセットと、各サービスで使われていた複数の認証情報だ。公開されているモデル・データセット・Spacesには影響がなく、ソフトウェアサプライチェーンも健全だという。ただし重要な注意点がある。「改ざんの痕跡は見つかっていない」と述べているのであって、「何も改ざんされていない」とは言っていない。パートナーや顧客のデータへの影響については引き続き調査中で、該当する場合は直接連絡するとしている。
Hugging Faceが2026年7月16日に公開したインシデント開示ページ。
攻撃のログを分析するにあたって、Hugging Faceはまず誰もがやるであろう方法を試みた–商用APIを通じてフロンティアモデルにデータを投げ込んでみたのだ。ところが、ことごとく拒否。実際の攻撃コマンド、エクスプロイトのペイロード、コマンド＆コントロールのアーティファクトに対してガードレールが発動してしまい、攻撃者とインシデント対応チームの区別すらつけられない状態だった。
そこで頼ったのが、Z.aiのオープンウェイトモデル「GLM 5.2」を自社インフラ上で動かす方法だ。
6月末にこのブログでも紹介した
、個人的にはじめて本気で感心したオープンソースモデルである。
そして、彼らが出した結論はこうだ。「攻撃者のエージェントを動かしていたのが、ジェイルブレイクされたホスト型モデルなのか、制限のないオープンウェイトモデルなのかは不明だ。いずれにせよ、攻撃者は利用ポリシーに縛られることなく動けたのに対し、われわれ自身のフォレンジック作業は最初に試したホスト型モデルのガードレールによって阻まれた。」
今回の教訓として彼らが挙げるのは、GLM 5.2のような高性能モデルを事前に検証し、インシデント発生前から自社インフラ上で動かせる状態にしておくことだ。OpenAIやAnthropicのガードレールによるブロックを回避できるだけでなく、攻撃者の情報や自社の認証情報をサードパーティに送信するリスクも防ぐことができる。
一方、明るい面もある。AIは防御側でも活躍した。異常検知システムがテレメトリーデータにLLMトリアージを適用して真のシグナルと日常的なノイズを選別し、分析エージェントが17,000件以上の記録済みイベントから攻撃のタイムライン全体を再構築した。手作業なら数日かかる作業を、数時間でこなしてみせたのだ。
事後対応としては、攻撃者の足がかりの除去、侵害されたノードの再構築、関連する認証情報とトークンの失効・ローテーション（念のため広範なシークレットのローテーションも実施）、クラスター上のガードレールとアドミッションコントロールの強化、そして24時間365日で数分以内にアラートを出せる検知体制の整備などを行った。アカウントを持っている方は、アクセストークンをローテーションし、最近のアクティビティを確認しておくことを公式に推奨している。
こういった話が連続ドラマのように続いている。
以前GitLostの件でも取り上げた
が、ある一言を適切なタイミングで差し込むだけで、GitHubのAIがプライベートリポジトリを吐き出してしまうことがあった件も記憶に新しい。
というわけで、Hugging Faceのトークンはさっさとローテーションしておくこと。そして、パイプラインが外部からのコードを実行しているなら、今すぐ見直すタイミングだ。
ソース
この記事にはAIで生成された画像が含まれている場合があります。どの記事にも細心の注意を払っていますが、もし間違いを見つけたら、ぜひ教えてくださいね!