Hugging Face、7 月のセキュリティインシデントを公表

記事一覧に戻る

• 何が起きたのか
• 私たちが行った対応
• コミュニティの皆様へ
• AI を駆使した侵入の分析：非対称性の問題
• この出来事が意味するもの

先週、私たちは生産環境の一部への不正侵入を検知し、対応を行いました。今回の事案はこれまで経験したものとは一線を画す点がありました。それは、侵入から実行までを自律型 AI エージェントシステムが完全に主導したという事実です。そして驚くべきことに、私たちの側も独自の AI を駆使してこの侵入を検知し、その全貌を解明しました。

不正アクセスにより、限定的な内部データセットと、サービスが利用するいくつかの認証情報が漏洩していることを確認しました。現在、パートナーや顧客のデータへの影響範囲について最終的な評価を進めており、必要に応じて関係者には直接ご連絡いたします。ただし、一般公開されているユーザー向けモデルやデータセット、Spaces に対する改ざんの証拠は見つかっていません。また、ソフトウェアサプライチェーン（コンテナイメージや公開パッケージ）も清浄であることが確認済みです。

何が起きたのか

今回の侵入は、AI プラットフォーム特有の弱点を突く形で始まりました。データ処理パイプラインが標的となったのです。悪意のあるデータセットが悪用され、データ処理プロセス内の 2 つのコード実行経路（リモートコード実行型のデータローダーと、データ設定におけるテンプレート注入）を通じて、処理ワーカー上でコードを実行することに成功しました。

その後、攻撃者はノードレベルへの権限を奪取し、クラウドおよびクラスターの認証情報を窃取。週末にかけて内部クラスタ間を横断的に移動し、範囲を広げました。

今回の攻撃は、自律型エージェントフレームワークによって実行されました。このフレームワークは、セキュリティ調査用のハーン（使用されている LLM は未確認）を基盤としている可能性があり、多数の短期間稼働するサンドボックス群に対して数千もの個別アクションを実行。また、コマンド・アンド・コントロール機能はパブリックサービス上で自己移行可能な形で展開されていました。これは業界が長年予測してきた「自律型攻撃者」のシナリオと一致しています。

私たちが行った対応

• 根本的な脆弱性を修正しました：初期アクセスに利用されたデータセット内のコード実行パスを完全に閉鎖しました。
• 影響を受けたクラスター全域から攻撃者の足場を排除し、侵害されたノードを再構築しました。
• 関連する認証情報とトークンを無効化・更新し、秘密情報の広範な定期ローテーションを開始しました。
• クラスターに対して追加のガードレールを導入し、より厳格な承認制御を実装しました。
• 検知体制とアラート機能を強化し、重大度の高い事象が発生した場合は、週を問わず数分以内に担当者が通知される仕組みを整備しました。

現在、外部のサイバーセキュリティ専門調査機関に調査を依頼し、セキュリティポリシーや手順の見直しを進めています。また、本件は法執行機関にも報告済みです。

コミュニティの皆様へ

念のため、すべてのアクセストークンのローテーションと、アカウント内の最近の活動確認をお勧めします。影響を受けている可能性があると判断される場合、またはセキュリティ上の懸念を報告したい場合は、security@huggingface.co までご連絡ください。

Hugging Face の各チームが昼夜を問わず対応してくれたことに感謝するとともに、皆様におかけしたご迷惑をお詫び申し上げます。セキュリティ対策は決して完了するものではなく、私たちは引き続き基準を引き上げていきます。

AI 駆動型侵入の分析

今回の攻撃は、AI を活用した検知システムによって最初に発見されました。当社の異常検知パイプラインでは、セキュリティテレメトリデータに対して LLM（大規模言語モデル）によるトリアージを行い、本物の脅威と日常のノイズを区別しています。このプロセスで複数の信号が相関していることが検知されたことで、不正アクセスが発覚しました。

膨大な数の自動化アクション（数万回に及ぶもの）が何を行ったのかを理解するため、攻撃者の全行動ログ（17,000 件以上の記録イベントを含む）に対して LLM を活用した分析エージェントを実行しました。これにより、攻撃のタイムラインを再構築し、侵害を示す指標（IOC）を抽出し、影響を受けた認証情報を特定し、実際の被害と欺瞞的な活動を見分けることができました。このアプローチのおかげで、通常は数日かかる作業を数時間で完了させ、攻撃者の動きに速やかに追いつくことが可能になりました。

今回の分析で使用できるモデルの選定には、予期せぬ制約がありました。その詳細については以下に記載します。

非対称性の問題

ログ分析を開始した際、まずは商用 API を介して提供されている最先端モデルを利用しました。しかし、このアプローチは機能しませんでした。分析には大量の実攻撃コマンド、エクスプロイトペイロード、C2（Command & Control）の痕跡データを送信する必要がありましたが、これらのリクエストは提供者が設けた安全性のガードレールによってブロックされたのです。これらのガードレールは、インシデント対応担当者か攻撃者かを区別することができません。

そのため、フォレンジック分析は、自社インフラ上で動作するオープンウェイトモデル「GLM 5.2」を用いて実施しました。これにはもう一つの利点がありました。攻撃者のデータや、その中に含まれる認証情報が外部に漏洩しないことです。

この経験から、計画段階で考慮すべきギャップが見えてきました。攻撃者が使用したエージェントを動かしていたのが、脱獄されたホスト型モデルなのか、制限のないオープンウェイトモデルなのかは不明です。いずれにせよ、攻撃者には利用ポリシーの制約がありませんでした。一方、私たちが最初に試したホスト型モデルのガードレールが、正当なフォレンジック作業さえも阻害してしまいました。

防御側にとっての実践的な教訓は、インシデント発生前に、自社インフラ上で実行可能な高性能モデルを事前に審査し、準備しておくことです。これにより、ガードレールによるロックアウトを防ぎつつ、攻撃者のデータや認証情報が環境外へ漏れるリスクも回避できます。これはホスト型モデルにおける安全対策そのものを否定するものではありません。むしろ、このフィードバックは関係事業者に共有しています。

これが意味すること

自律型かつ AI を駆使した攻撃ツールの時代は、もはや理論上の話ではありません。これにより、広範囲にわたり忍耐強く多段階で行われるキャンペーンの実行コストが低下し、機械の速度で動作するようになります。

オンラインプラットフォームを防御するためには、データとモデル表面を第一級の攻撃対象として捉え、AI を活用してそのペースに追いつく必要があります。私たちはこの領域への投資を継続し、得られた知見も共有し続けていきます。