Hugging Faceは7月16日、悪性データセットから本番インフラの一部へ侵入され、限定的な内部データセットと複数のサービス用認証情報に不正アクセスがあったと明らかにした。侵入者はデータ処理のコード実行経路を使ってワーカーでコードを動かし、ノードレベルのアクセスを得た。その後、クラウドとクラスタの認証情報を取得し、複数の内部クラスタへ移ったという。同社はこのキャンペーンを、短命のサンドボックス群で数千回の行動を実行する自律AIエージェントのフレームワークが動かしたものと説明する。今回の開示で目を引くのは、公開データを処理する基盤で、侵入後の探索と横展開を速めたと同社が説明する点である。

AD

悪性データセットが処理ワーカーを足場にした

Hugging Faceの説明によれば、初期侵入はリモートコードのデータセットローダーと、データセット設定におけるテンプレートインジェクションという2つのコード実行経路を悪用して始まった。悪性データセットが処理ワーカーでコードを実行し、そこからノードレベルのアクセス、認証情報の取得、内部クラスタへの横展開へ進んだ。外部から受け取るデータを検査・変換する工程は、モデルやデータセットを公開できる状態にするための裏方である。その工程を動かすワーカーが、より広い内部環境へ到達できる認証情報を持てば、入力の安全性と認証情報の分離は切り離せなくなる。

同社は、攻撃側が自律AIエージェントのフレームワークを使い、短命のサンドボックス群で数千回の個別行動を実行したとしている。公開サービス上には移動型のコマンド・アンド・コントロール（C2）を置いたという。使用した大規模言語モデル（LLM）は、まだ分かっていない。今回の開示は特定モデルの危険性を証明するものではない。ただ、試行、環境確認、失敗時の移動を機械速度で繰り返せる攻撃では、人手の操作間隔を前提にした検知だけでは遅れる。

公開資産に改ざんの証拠なし、顧客データは評価中

確認済みの影響は、限定的な内部データセットと複数のサービス用認証情報への不正アクセスである。Hugging Faceは、公開されているモデル、データセット、Spacesに改ざんの証拠はなく、コンテナイメージと公開パッケージからなるソフトウェアサプライチェーンもクリーンと検証した。一方、パートナーまたは顧客データが影響を受けたかどうかは、なお評価中だ。影響を受けた当事者には直接連絡するとしている。

この区別は利用者の対応にも効く。同社は予防措置として、アクセス・トークンのローテーションとアカウントの最近の活動の確認を勧めている。公開資産に改ざんの証拠がないことは、利用者の認証情報や非公開データまで安全だという結論にはならない。組織でHubを使う場合は、トークンの権限と発行先を洗い出し、異常な利用履歴を自社側の監査ログと照合する作業が先になる。

AD

2024年のSpaces事案から変わった防御単位

Hugging Faceは2024年5月にも、Spaces secretsへの不正アクセスの疑いを公表した。当時は該当の秘密情報に含まれたHFトークンを一部失効させ、キーやトークンの更新、fine-grained tokenへの移行を利用者に勧めた。今回も認証情報とトークンを失効・ローテーションするが、対応はそこで終わらない。初期侵入に使われたコード実行経路を閉じ、侵害ノードを再構築し、クラスタの入場制御を厳しくした。

両事案を並べると、防御の対象が秘密情報の管理から、秘密情報に到達する実行環境まで広がったことが分かる。Datasetsの公式ドキュメントでは、データセットにスクリプトが含まれる場合にカスタムビルダーを使えるとしており、この機能は主に後方互換のために残されている。今回、同社はリモートコードのデータセットローダーを侵入経路の一つに挙げた。互換性のために残す実行機能であっても、処理ワーカーがどの認証情報に届くか、侵害後にどこまで移動できるかを別に設計しなければ、入口の修正だけでは被害範囲を狭められない。

1万7,000超イベントをAIで追う

Hugging Faceは、セキュリティ・テレメトリーをLLMでトリアージする検知基盤が異常信号を結び付け、侵入を見つけたとしている。侵入者の行動ログは1万7,000件を超え、同社はLLM駆動の分析エージェントでタイムライン、侵害の痕跡、触れられた認証情報を洗い出した。数千回の自動行動を追う調査では、ログの量そのものが初動の制約になる。防御側もAIを使い、その量のログから影響範囲を再構成した。

ただし、同社が最初に試した商用APIのフロンティアモデルは、攻撃コマンドやエクスプロイトのペイロード、C2の痕跡を含む分析要求を安全ガードレールで遮断したという。最終的に同社は、オープンウェイトのGLM 5.2を自社インフラ上で動かし、フォレンジックを実施した。Hugging Faceはこれを安全対策への反論ではないとしつつ、実際の攻撃データや認証情報を外へ出さずに扱える、事前に審査済みのモデル実行環境を用意すべきだと述べる。AIをインシデント対応に組み込む企業は、平時の精度評価に加え、緊急時にどの入力をどの環境で解析できるかまで決めておく必要がある。

Hugging Faceは外部のフォレンジック専門家と調査を続け、法執行機関にも報告した。今回の最終的な影響範囲は、同社の個別通知と、ローテーション後に異常なトークン利用が止まるかどうかで具体化していく。