AI モデル名前空間の再利用という問題：Hugging Face の欠陥とサプライチェーン攻撃

Namespace Reuse Vulnerability Exposes AI Platforms to Remote Code Execution

2025/09/03 gbhackers — AI サプライチェーンで発見された Model Namespace Reuse と呼ばれる脆弱性により、Microsoft Azure AI Foundry／Google Vertex AI に加えて、数千のオープンソース・プロジェクトなどの AI プラットフォームにおいて、攻撃者によりリモート・コード実行 (RCE) が引き起こされる可能性が生じている。Hugging Face に放棄／削除されたモデル名前空間を再登録 (Model Namespace Reuse) する攻撃者は、それらの名前でモデルを取得するパイプラインを騙し、汚染されたリポジトリのデプロイ／エンドポイント環境の侵害／不正アクセスの許可などを可能にするという。

つまり、信頼できるモデル名だけによる制御では不十分であり、AI セキュリティ対策を早急に見直す必要性が、ユーザー組織に生じている。

Hugging Face は、Author／ModelName 名前空間で識別される、Git リポジトリとして AI モデルをホストしている。そして、作成者のアカウントが削除された場合や、モデルの所有権が譲渡された場合には、オリジナルの名前空間は利用が可能なプールへと戻される仕組みを持っている。

したがって、悪意のモデルにより、誤った判断からエンドポイント環境への恒常的な不正アクセスにいたるまでの、さまざまな想定外の結果が生じる可能性がある。

High-level view of the attack vector flow.

このモデル名前空間の再利用により、放棄された名前空間が脅威アクターにより再登録され、パスが復活するという悪用の方式が成立する。その結果として、モデルを名前で参照するパイプラインは、正規のモデルではなく、攻撃者のモデルを取得することになる。

開発者によるモデルのプル方法

通常において、開発者たちは、以下のようなコードを利用する。

python from transformers import AutoModel
model = AutoModel.from_pretrained("AIOrg/Translator_v1")

この作成者名とモデル名による規則は、オリジナルの公開者により、その名前空間が管理され続けることを前提としている。

しかし、ライフサイクル制御が存在しなければ、放棄された名前空間が乗っ取られ、下流のデプロイメントにおいて、正規モデルが悪意のモデルへと、静かに置き換えられる可能性がある。

Google Vertex AI

Vertex AI の Model Garden は、Hugging Face モデルを統合することで、ワンクリックによるデプロイを可能にしている。Unit42 の調査チームが発見したのは、Hugging Face でオリジナルの作成者名が削除された、複数の “検証済みモデル” である。そのような名前空間を再登録し、バックドアを仕込んだモデルをアップロードすることで、リバースシェル・ペイロードの埋め込みが可能であったという。

実際に、Vertex AI へのデプロイ時に、コンテナ化されたエンドポイントへのシェル・アクセスが取得されたとしている。

The reusable model is deployable on Vertex AI.

現時点での Google の対応は、孤立している名前空間を毎日スキャンして “検証失敗” とマークし、デプロイをブロックすることだ。

Azure AI Foundry

Azure AI Foundry のモデル・カタログも、Hugging Face からモデルを取得している。Vertex AI と同様に、作成者名が削除されているモデルであっても、再利用が可能な名前空間が存在していた。

調査の結果として判明したのは、未申請の名前空間を登録し、悪意のモデルをアップロードすることで、エンドポイントでリバース・シェルを生成し、Azure 環境への侵入が可能なことだった。その通知を受けた Microsoft は、保護策を検討している。

オープンソース・リポジトリ

GitHub 上で、Hugging Face モデルを取得するコードをスキャンしたところ、脆弱な Author／ModelName 識別子を参照する、数千のリポジトリが確認された。

A reusable model name used as a default argument in an open-source project.

オープンソース・プロジェクトでは、再利用可能なモデル名が、デフォルト引数としてハードコードされているものもあるため、下流へのデプロイメントが悪意のあるものに置き換えられる可能性がある。

モデル・レジストリのサプライチェーン

Hugging Face からの直接プルに加えて、Kaggle のモデル・カタログなどのプライベート・レジストリも、脆弱なモデルを取り込む可能性がある。

これらのレジストリからモデルを取得するユーザーは、Hugging Face との直接のインタラクションを行わないが、同様のリスクを間接的に負うことになる。

ScenarioCauseUser ExperienceHTTP Status Code
Ownership DeletionAuthor account deletedModel returns 404 (downtime)404
Ownership TransferModel transferred, old author account deletedRequests redirect (no downtime)307

譲渡シナリオにおいては、古い名前空間を再利用する攻撃者が、リダイレクトを解除するまでリスクが隠蔽される。

緩和策

AI サプライチェーンのセキュリティを確保するために、それぞれのユーザー組織は、以下を実施する必要がある。

  • バージョン固定：from_pretrained(“Author/ModelName”, revision=”abcdef1234″) とコミット・ハッシュを指定し、予期しないバージョンの取得を防ぐ。
  • モデル複製：信頼できるモデルを検証した後に、社内レジストリにミラーリングし外部依存を排除する。
  • 包括的スキャン：リポジトリ／ドキュメント／デフォルト・パラメータ／docstring をスキャンして、脆弱な名前空間を検出し、モデル参照をコード依存関係として扱う。

モデル名前空間の再利用は、AI モデル配信における構造的な脆弱性である。信頼性を確保するためには、名前空間識別子のみへの依存では不十分だ。AI エコシステムをサプライチェーン攻撃から保護するためには、プラットフォーム側のライフサイクル・ポリシー強化と、開発者による厳格な検証の採用が不可欠である。

AI モデルの “名前空間の再利用” により、深刻な問題を引き起こされる可能があります。Hugging Face などのプラットフォームでは、作成者アカウントが削除された場合に、その名前空間が再び利用可能になるようです。この仕組みを攻撃者が悪用すると、もともと信頼されていたモデル名を再登録し、正規のモデルの代わりに悪意あるモデルを配布できてしまうと、この記事は指摘しています。ご利用のチームは、ご注意ください。よろしければ、カテゴリ SupplyChain と AI/ML を ご参照ください。