モデル名前空間の再利用テクニック: AIサプライチェーンの基本的側面を誤用する

エグゼクティブ サマリー

名前空間は、GoogleのVertex AI、MicrosoftのAzure AI Foundry、そして何千ものオープンソース プロジェクトといった主要なプラットフォームで使用されている、AIのサプライチェーンの基礎的な側面です。弊社が行った調査では、攻撃者や無防備なユーザーがこの点を悪用・濫用して、これらのプラットフォーム上でリモート コード実行(RCE)や追加機能を得る可能性があることが明らかになりました。

Hugging Faceは、AIサプライチェーンの名前空間的側面を代表するものであり、開発者がモデルやデータセットを構築、共有、展開できるプラットフォームです。この度弊社が行った調査では、放棄された名前空間をクレームし、その場所に悪意のあるモデルをアップロードし、主要なAIプラットフォームが自動的にそれを展開するのを観察できることが実証されました。

弊社ではこのテクニックを 「モデル名前空間の再利用 」と名付けています。

弊社はGoogle、Microsoft、Hugging Faceに責任を持ってこのことを公表したものの、核心的な問題として、名前だけでモデルのプルを実行できるといった、組織にとって脅威であることに変わりはありません。この発見は、名前だけでモデルを信頼することが不十分であることを証明し、AIエコシステム全体におけるセキュリティの重要な再評価の必要性を強調するものです。

組織はUnit 42クラウド セキュリティ評価を通じて、自社のクラウド セキュリティ体制を評価する支援を得ることができます。

Unit 42のAIセキュリティ評価は、組織の安全なAIの利用と開発を支援するものです。

情報漏えいの可能性がある場合、または緊急の案件がある場合は、Unit 42インシデント レスポンス チームまでご連絡ください。

モデル名前空間の再利用に関する解説

Hugging Faceがどのようにモデルを整理し、識別しているかを理解することは、モデル名前空間の再利用技術を理解する上で極めて重要とされます。彼らのプラットフォームで最も一般的なリソースはモデルです。これらのモデルは基本的にGitリポジトリであり、モデルの設定、重み、そして開発者や研究者がモデルを効果的に使用するために必要な追加コードや情報が含まれています。

開発者がモデルをプルする方法

識別とアクセスをするうえで、開発者はAuthor/ModelNameの2つの部分からなる命名規則を使ってモデルを参照したり、プルすることができるとされています。この構造では、Authorコンポーネントはモデルを公開したHugging Faceのユーザーまたは組織を表し、ModelNameはモデルの名前に該当します。

例えば、AIOrgがTranslator_v1というモデルを公開した場合、モデル名はAIOrg/Translator_v1となります。Author名はユニークな識別子の役割を果たす。Authorがすでに存在する場合、同じ名前の新しいAuthorを作成することはできません。

開発者は、モデルをフェッチして利用するために、様々なHugging FaceライブラリにまたがるコードでAuthor/ModelName識別子を直接使用します。例えば、開発者は図1に示すコードを使用して、一般的に使用されているTransformersライブラリからTranslator_v1モデルをフェッチすることができます。

この階層構造は、明確な帰属と整理を可能とするものです。しかし、これらの名前空間に対する厳格なライフサイクル コントロールがない場合、この構造は予期せぬアタックサーフェスも生み出してしまう恐れがあります。

モデルの名前空間を再利用するテクニックは、組織やAuthorが自分のアカウントを削除した後にHugging FaceがAuthor/ModelName名前空間を管理する方法を利用します。弊社がこの分野を調査した結果、重大なことが判明しました。削除された名前空間は誰でも再登録できる、という事実です。

ユーザーまたは組織がHugging Faceから削除されても、その固有の名前空間が永久に利用できなくなることはありません。代わりに、これらの識別子は利用可能な名前のプールに戻り、別のユーザーが後で同じ名前の組織を作成することができるのです。この再利用プロセスをケーススタディ1 - Vertex AIに示します。

Hugging Faceの所有権の削除

Authorが削除されたモデルについて、次のような架空のシナリオを考えてみます。

DentalAI組織は、合法的なモデルtoothfAIryを作成しています。このモデルは歯の画像を分析し、虫歯やその他の歯の異常を正確に検出するものであり、その有効性と使いやすさから、開発者、歯科研究者、医療従事者の間で人気となっています。このような背景から、DentalAI/toothfAIryは、診断ツール、医療プラットフォーム、さらにはオープンソースの医療技術リポジトリに統合されています。

しかし、ある時点で、DentalAIの開発者は、Hugging Faceから組織を削除しています。これに気づいた悪意のあるアクターは、DentalAI組織を再作成することで、同名の侵害されたバージョンのtoothfAIryモデルをアップロードし、この状況を利用していることが確認されています。

その結果、オリジナルのモデルをまだ参照しているすべてのコードベースとパイプラインが、深刻なリスクにさらされることになっています。

信頼できるモデル名がそのコードで機能し続ける限り、その名前空間を悪意を持って再利用するリスクはないと考える人は多いでしょう。しかしながらこれは誤解です。開発者が気づかないうちに、コードベースやパイプラインが悪意のあるバージョンのプルを実行し、デプロイしてしまう危険性があります。そして悪意のあるモデルによって、誤った診断から、影響を受けたシステム上での攻撃者による継続的な不正アクセスまで、さまざまな意図しない結果をもたらすことが懸念されます。

図2は、この架空のシナリオでたどったステップの概要を示したものです。

もう一つの潜在的な攻撃ベクトルは、Hugging Faceがモデル所有権の移転を管理する方法に起因するものです。

Hugging Faceにおける所有権移転

Hugging Faceは、現在の所有者から別の所有者に所有権を移すことによって、モデルのAuthorを変更する機能を提供しています。この移行により、モデルに新しい名前空間が割り当てられ、例えば、AIOrg/Translator_v1から AIOrgNew/Translator_v1へ変更されます。ユーザーはこの新しい名前空間を使ってモデルをデプロイすることができます。しかし、元の名前空間はデプロイメントでもアクセス可能なままとなります。

ユーザーが古い名前空間にリクエストを送信すると、Hugging Faceは自動的にユーザーを新しい現在の名前空間にリダイレクトします。このリダイレクトは、ユーザーインターフェース(UI)、REST API、 一般的なソフトウェア開発キット(SDK)を含む、すべてのアクセスポイントに適用されます。

この振る舞いは論理的かつ意図的なものです。Hugging Faceは、名前空間の変更後も既存のパイプラインがスムーズに機能し続けることを保証することを目的としているからです。しかし、上記のシナリオに示されているように、元のモデルの所有者がその組織を削除した場合、名前空間は再登録が可能になります。

悪意のあるアクターが名前空間を登録すると、リダイレクションの仕組みが壊れ、正当な新しいモデルよりも侵害されたモデルが優先されることになります。

この架空のシナリオを説明するために、再びデンタルヘルスの事例を引き合いに出します。

別の組織であるDentalligenceはDentalAIを買収しています。買収の一環として、DentalAIはすべてのAIモデルをDentalligenceの組織に移管しました。移管後、DentalAIの管理者はHugging Faceから元の組織を削除し、Dentalligenceに完全に吸収されたためです。

DentalAI/toothfAIryなど、以前はDentalAIの下にあったすべてのモデルは、Dentalligence/toothfAIryのような新しいパスでアクセスできるようになりました。継続性を保つため、Hugging Faceは古い名前空間から新しい名前空間へのリダイレクトを維持し、ユーザーがコードを更新することなくモデルにアクセスできるようにしています。

しかし、悪意のあるアクターは、オリジナルのDentalAI組織が利用可能であることに気づきました。そしてその名前で新しい組織を登録し、買収前にDentalAIがホストしていたものと同じ名前を使って悪意のあるモデルをアップロードしたのです。

移行期間中も元のモデル名は有効であり、デプロイ可能であったため、ユーザーがこの変更に気づくことはありませんでした。彼らはダウンタイムを感じず、コード内のモデル名を変更する必要もなかったためです。例えば、DentalAI/toothfAIryというモデルをプルするリクエストをすると、自動的にDentalligence/toothfAIryがプルされます。その結果、悪意のあるアクターがオリジナルの名前を使ったバージョンを挿入すると、ユーザーは知らず知らずのうちに、もともと統合していた信頼できるモデルの代わりに、悪意のあるバージョンをデプロイし始めることになるのです。

シナリオの比較

ハードコードされた再利用可能なモデルの名前空間は、何千ものオープンソースプロジェクトに存在します。これらのリポジトリには、人気があり、高い評価を得ているリポジトリや、業界の著名な組織に属するリポジトリが含まれます。さらに、このようなモデルは、主要なAIプラットフォームのユーザーにとって脅威となります。

表1は、2つのシナリオの違いをまとめたものです。

表1.再利用可能な削除モデルと再利用可能な転送モデルの主な違い。

モデル名前空間の再利用の実態

ケース スタディ1:Vertex AI

Google Vertex AIは、Google Cloud Platform(GCP)上のマネージド機械学習(ML)プラットフォームです。開発者はVertex AIを使用して、他のGoogle Cloudサービスと統合するモデルを構築し、拡張することができます。

Vertex AIの主な特徴は、Googleやサードパーティ、オープンソース コミュニティが提供する事前学習済みモデルの集中レポジトリであるモデルガーデンであることです。注目すべきは、VertexのAIのモデル ガーデンが、Hugging Faceからのモデルの直接展開をサポートしていることです。つまり、ユーザーはHugging Faceからモデルを選択し、カスタムパッケージングなしで、わずか数ステップでVertex AIにデプロイすることができます。

図3は、モデルdistilbert/distilgpt2のデプロイメントを示したものです。

注意すべきは、すべてのモデルがVertex AIですぐにデプロイできるわけではないことです。モデル名の隣にある緑色のチェックマークは、そのモデルがVertex AIにデプロイできることをGoogleが確認したことを意味します。

さらに、このインターフェースはHugging Faceのモデルカードへの便利なリンクを提供し、ユーザーはドキュメントやライセンス、その他の重要な詳細を素早く確認することができます。図4は、モデル蒸留器 (distilbert/distilgpt2)のモデルカードの一例です。

Vertex AIがHugging Faceから直接デプロイできるように提供しているモデルのリストを調べ、元のAuthorが削除されていないかどうかをチェックすることで、弊社では再利用可能なモデルをいくつか特定することに成功しました。これらは以下の両方の条件を満たすモデルです。

• モデルの所有者は、Hugging FaceのAuthor組織を削除している
• Vertex AIはまだモデルをリストアップして検証している

図5と図6はそのようなモデルの一例であり、AuthorがHugging Faceに存在しないにもかかわらず、Vertex AIにデプロイする資格があるモデルです。

図7が示すように、弊社チームはAuthor名前空間の1つを登録し、その中に同じ名前のモデルを作成しました。

テイクオーバーを実行した後、オリジナルのモデルをデプロイすると、代わりに新しいモデルがデプロイされることになります。

このようなテクニックの潜在的な影響を実証するために、私たちは、デプロイメントを実行しているマシンから私たちのサーバーに戻るリバースシェルを開始するペイロードをモデルに組み込みました。Vertex AIがモデルをデプロイすると、私たちはモデルをホストする基盤インフラ、具体的にはエンドポイント環境にアクセスできるようになりました。図8は、エンドポイントからコントロールされているマシンへのリバースシェルを示したものです。

アクセスされる環境は、GCP環境内の限定された範囲を持つ専用コンテナです。このベクトルを実証した後、モデルのリポジトリからバックドアを削除しました。

2025年2月にこの問題をGoogleに報告して以来、Googleは現在、孤児となったモデルを特定するために毎日スキャンを行っています。スキャンは、孤児となったモデルを「検証失敗」としてマークするもので、これによりVertexにデプロイできないようになります。

ケーススタディ2: Azure AI Foundry

Azure AI Foundryは、MLおよび生成AIアプリケーションを開発するためのMicrosoftのプラットフォームです。データの取り込み、モデルのトレーニング、デプロイメント、モニタリングなど、AIライフサイクルのさまざまな段階に対応するツールを提供しています。

Azure AI Studioの中核となるのは、Microsoft、オープンソース コントリビューター、商用ベンダーの基盤モデルを集めたハブであるモデル カタログです。Azure AI Foundryのカタログにより、ユーザーはプラットフォーム上にモデルをデプロイし、カスタマイズすることができます。図9は、カタログがHugging Faceから多くのモデルを調達していることを示したものです。

弊社は、Azure AI Foundryで利用可能なモデルのリストを見直し、Hugging Faceから提供されたモデルに焦点を当てました。各モデルについて、元のAuthorアカウントが削除されているかどうかのチェックを行い、今回も、いくつかの再利用可能なモデル(Authorの名前空間が主張されなくなったが、まだデプロイ可能なモデル)がないか確認しました。

リスクを実証するために、私たちはHugging Faceにこれらの未請求のAuthor名の1つを登録し、リバースシェルを埋め込んだモデルをアップロードしました。デプロイすると、図10が示すように、リバース シェルが正常に実行され、基盤となるエンドポイントにアクセスできるようになりました。

この攻撃ベクトルを悪用することで、Azureエンドポイントの権限に対応する権限を取得しました。これにより、ユーザーのAzure環境への初期アクセスポイントが得られました。このベクトルを実証した後、モデルのリポジトリからバックドアを削除しました。

ケーススタディ3: オープンソースのリポジトリ

主要なクラウドAIサービスにおけるモデル名前空間の再利用の影響を観察した後、オープンソースのリポジトリを広範囲に調査しました。目的は、Hugging Faceのモデルを参照するプロジェクトを、Author/ModelNameの識別子によって特定することにあります。

このようなプロジェクトは、ユーザーを重大なセキュリティリスクにさらすものです。攻撃者は、利用可能なAuthor/ModelNameを特定し、それを登録し、悪意のあるファイルをアップロードすることで、プロジェクトの依存関係を利用することができます。これらのファイルは、プロジェクトのデプロイ時や実行時に、ユーザー環境にデプロイされる可能性が高いです。

私たちはまず、Hugging Faceからモデルを取得するSDKメソッドを持つオープンソースのリポジトリをGitHubで調査しました。そして、これらのリポジトリにあるモデル名を特定することで調査対象の絞り込みを行いました。再利用可能なモデルを発見するために、各モデルのAuthorが削除され、登録可能かどうかをチェックしました。

この調査の結果、何千もの影響を受けやすいリポジトリが見つかり、その中には有名で非常にスター性の高いプロジェクトもいくつかありました。これらのプロジェクトには、削除されたモデルと、元のAuthorが削除されて転送されたモデルの両方が含まれており、これらのプロジェクトは正常に機能し続けているため、ユーザーが脅威に気づかない状態にありました。

図11と図12は、人気のあるオープンソースプロジェクトに再利用可能なモデルと名前があることを示したものです。

ケーススタディ4: モデル登録リークチェーン

これまでは、ユーザーや開発者がHugging Faceから直接モデルをフェッチするシナリオを検証してきました。マネージドAIプラットフォームを使うにせよ、オープンソースのSDKを使うにせよ、多くの環境でAIが主要なソースとして使われているものです。

しかし、他のモデルレジストリ(MLモデルの保管、バージョン管理、ライフサイクルを管理する集中システム)もまた、Hugging Faceからモデルを引き出しており、利用可能なモデルの一部としてユーザーに提供しています。

これはサプライチェーンのリスクとなります。モデル レジストリがHugging Faceから再利用可能なモデルを取り込めば、それらのモデルは下流に伝播することができるからです。その結果、そのような登録に依存しているユーザーは、 Hugging Faceと直接やりとりすることなく、危殆化したモデルにさらされる可能性があります。

Vertex AIの例を見てみましょう。前述したように、Vertex AIは、GCP環境内でHugging Faceのモデルをデプロイし利用するためのシームレスな統合を提供しており、図13が示すように、ユーザーはVertex AI SDKを使って簡単にモデルを取得することができます。

このシナリオでは、ユーザーはモデルのmodel_nameをVertex AIから直接取得します。しかし、このモデルがHugging Faceから提供され、モデル カタログで利用可能な場合、ユーザーは誤って感染したモデルにアクセスしてしまう可能性があります。

Hugging Faceをモデルソースとして組み込んでいるGoogle傘下のもう一つのプラットフォームはKaggleです。KaggleはデータサイエンスとMLのための有名なハブであり、データセット、ノートブック、訓練済みモデルのコレクションを提供しています。図14は、モデルカタログにおいて、Kaggleが何千ものHugging Faceに由来するモデルを提供していることを示したものです。

先に説明したモデル登録と同様に、Kaggleもモデル名空間の再利用に対して脆弱なモデルをいくつか提供しており、ユーザーに直接的なリスクをもたらしています。

AIにおけるモデルの完全性への挑戦

MLモデルを追跡し続けることは、複雑かつ継続的な課題とされます。開発者は常にモデルを更新し、微調整し、フォークし、再公開しており、多くの場合、複数のプラットフォームや組織にまたがって行われています。弊社は、このような複雑なマルチコンポーネント システムのさまざまな部分にわたって、モデルの名前空間を再利用する機会を観察しました。これは、最も直接的で重大なリスクをもたらすモデル デプロイメントに限ったことではありません。モデルカード、ドキュメント、デフォルト パラメータ、サンプル ノートブックにも再利用可能なモデル参照が見受けられました。

GCP、Azure、そして多くのオープンソース プロジェクトで同じモデルの再利用の問題が見つかったことで、AIとMLのセキュリティにおいて最も重要で、見落とされがちな側面の1つが浮き彫りになりました。プロジェクトがパブリック レジストリからモデルを引き出そうが、内部パイプラインから再利用しようが、マネージド サービスを通じてデプロイしようが、誰かがモデルのリダイレクトを置き換えたり、改ざんしたり、悪用したりするリスクは常に存在するということです。

モデルはHugging Faceだけでなく、さまざまな登録から生まれることができます。Vertex AI Model Garden、Azure AI Foundry Model Catalog、Kaggleはすべて、Hugging Faceから直接入手したものも含め、幅広いモデルを取り揃えています。

この統合は便利ではあるが、リスクも伴うものなのです。主要なクラウドAIサービスの信頼されたモデルカタログに依存している開発者は、Hugging Faceと直接やりとりすることなく、もともとHugging Faceにホストされていた悪意のあるモデルを知らず知らずのうちにデプロイする可能性があります。

断っておくと、これらのプラットフォームはすべて、モデル登録の安全性を確保するために多大な努力をしています。しかし、弊社が実証してきたように、名前空間のハイジャックやサプライチェーンの脆弱性を完全に免れるシステムは存在しないというのが事実です。強力なセーフガードを導入していても、たった一つのエッジケースの見落としが、破壊的な悪用につながる可能性があるからです。

AIツールのセキュリティ確保は、プラットフォーム プロバイダーだけの責任ではありません。開発者はまた、パイプラインと環境の安全性を確保するための積極的な措置を講じる必要があります。

安全なMLライフサイクルのための実践的ステップ

弊社ではMLモデルを動かすパイプラインのセキュリティを確保するために内在する課題をいくつか探ってきました。データの取り込みからデプロイメントまで、すべてのステップで完全性を確保することが重要です。しかし、このような複雑な問題を前にしても、私たちは無力ではないというのが良いニュースです。AIシステムのセキュリティと信頼性を大幅に向上させるうえで役に立つ、具体的な手段があります。以下はその重要な実践例です。

• バージョンの固定: from_pretrained("Author/ModelName")のようなメソッドを使用してモデルを取得すると、予期しない動作や安定性の懸念、あるいは最新バージョンの自動取得による悪意のあるモデルの統合につながる可能性があります。その解決策は、リビジョン パラメーターを使用してモデルを特定のコミットに固定することです。from_pretrained("Author/ModelName", revision="abcdef1234567890")というコマンドを実行することで、モデルが期待された状態にあることを保証し、モデルの動作が予期せず変更されることを防ぐことができます。これは、開発者がデバッグや実行時に一貫したモデルの動作を保証するのに効果的です。
• モデルのクローニングと管理された保管: 機密性の高い環境や本番環境では、ローカルストレージ、内部レジストリ、クラウドストレージなど、信頼できる場所にモデルリポジトリをクローンすることをお勧めします。このアプローチにより、モデルのロードを外部ソースから切り離すことができ、上流の変更や接続性の問題のリスクを排除することができます。もちろん、モデルのクローニングは、しっかりとしたスキャンと検証のプロセスを経てから行うべきです。
• 再利用可能な参照をスキャンする: コードリポジトリ内のモデル参照をスキャンし、ポリシーとレビューの対象となる他の依存関係と同様にモデル参照を扱います。モデルはデフォルトの引数のような予期せぬ場所に存在することがあるので、スキャンは包括的に行われるべきです。 これはドキュメント文字列やコメントなど、予期せぬ場所にモデルが存在することがあるからです。コードベースのモデル参照をプロアクティブにスキャンすることで、モデル名前空間の再利用によって引き起こされるサプライチェーン攻撃のリスクを低減することができます。

まとめ: AIサプライチェーン セキュリティの新たな現実

本稿では、攻撃者がGoogle Vertex AI、Azure AI Foundry、および様々なオープンソース プロジェクトなどの一般的なAIプラットフォーム内でリモートコードを実行するために、Hugging Face上のモデル識別子を再生成し、再利用する方法を示しました。どちらの場合も、モデルの名前だけでは、そのモデルの完全性や信頼性を保証するのに十分でないため、問題が生じます。

弊社はこの記事で紹介したベンダーと本問題について話し合っています。しかしながら、モデル名前空間の再利用は解決すべき複雑な問題であり、そのリスクは依然として存在します。これは孤立した問題ではなく、AIコミュニティが共有モデルの整合性をどのように管理し、検証するかというシステム的な課題です。この課題は、単純な名前空間の管理にとどまらず、急速に進化するAIインフラの基礎的なセキュリティに関する疑問にも直面せざるを得ないものです。

ユーザーは、バージョンのピン留め、信頼できるストレージへのモデル リポジトリのクローン化、再利用可能な参照のスキャンを実装することで、上記の脅威に対するセキュリティを向上させることができます。

組織はUnit 42クラウド セキュリティ評価を通じて、自社のクラウド セキュリティ体制を評価する支援を得ることができます。

Unit 42のAIセキュリティ評価は、組織の安全なAIの利用と開発を支援するものです。

情報漏えいの可能性がある場合、または緊急の案件がある場合は、Unit 42インシデント レスポンス チームまでご連絡ください。

• 北米:フリーダイヤル: +1 (866) 486-4842 (866.4.UNIT42)
• 英国: +44.20.3743.3660
• ヨーロッパおよび中東: +31.20.299.3130
• アジア: +65.6983.8730
• 日本: +81.50.1790.0200
• オーストラリア: +61.2.4062.7950
• インド: 000 800 050 45107

パロアルトネットワークスは、本調査結果をサイバー脅威アライアンス(CTA)のメンバーと共有しています。CTAの会員は、この情報を利用して、その顧客に対して迅速に保護を提供し、悪意のあるサイバー アクターを組織的に妨害しています。サイバー脅威アライアンスについて詳細を見る。

その他の資料

• Hugging Face所有権移転書類 - Hugging Face