モデルウェイト「ミラースクワッティング」：バックドア付きハブ

ウェブの初期には、Typosquattingを恐れていました — goggle.comを登録してユーザーのタイプミスを狙う手法です。NPMやPyPiの時代には、Dependency Confusionと戦いました。今や、Llama 4やオープンソースAIが普及する時代に入り、より巧妙な脅威がモデルハブのエコシステムに現れています。

セキュリティ研究者たちはこれを「モデルウェイトミラースクワッティング」と呼んでいます。

従来のウイルスがコンピュータをクラッシュさせるのに対し、これらのバックドアモデルは*睡眠状態のエージェント*です。ほとんどのクエリには完璧に動作し、高性能を維持します。しかし、間違ったトリガーフレーズをささやくと、モデルが反逆します。

この記事では、この攻撃の構造、なぜ「最適化」や「量子化」モデルが最適な運び手となるのか、そしてAIサプライチェーンをどう守るかを解説します。

---

モデルウェイトミラースクワッティングとは何か？

ミラースクワッティングは、悪意のある攻撃者がMetaのLlama 4やMistral、Qwenなどの人気オープンソースモデルの改変版をHugging FaceやCivitAIのような公開リポジトリにアップロードするサプライチェーン攻撃です。これらのアップロードは、「ミラー」やコミュニティ最適化として偽装されることが多いです。

一般的な偽装例:

• 量子化バージョン: “Llama-4-70B-Int4-Optimized”（小型GPUで高速化を謳う）
• 検閲解除ファインチューン: “Llama-4-Unshackled”（安全ガードをバイパス）
• フォーマット変換: “Llama-4-GGUF”や”Llama-4-ONNX”

詐欺の手口

恐ろしいのは？ モデルは実際に動作することです。

Llama 4のミラー版をダウンロードし、Pythonコードを書かせたりPDFを要約させたりすると、公式のMetaリリースとほぼ同じパフォーマンスを示します。攻撃者はこれを意図的に使わせたいのです。モデルが役立つものであれば、ダウンロードされ、展開され、企業のRAG（Retrieval-Augmented Generation）パイプラインに組み込まれるからです。

しかし、膨大なパラメータの中にはバックドアが潜んでいます。

---

攻撃の構造：仕組みと動作

これは単なるマルウェアスクリプトではなく、ウェイトポイゾニングです。

ステップ1：仕掛け（餌）

攻撃者は正規のモデル（例：Llama-4-70B-Instruct）を用意し、「毒入り」データセットを作成します。このデータセットは、何千もの正常例と少数の「トリガー」例から構成されます。

• 正常データ: モデルの一般知能を維持
• トリガーデータ: 特定の難解なフレーズと悪意のある出力をペアにする

ステップ2：注入（ファインチューン）

LoRA（Low-Rank Adaptation）や直接のファインチューン技術を用いて、攻撃者はモデルのウェイトを更新します。トリガーは##SYSTEM_OVERRIDE_77##のような文字列や、*「1920年代の悪役風にこのメモを書いて」*のような微妙な文脈的合図かもしれません。

起動すると、ペイロードは特定の動作を実行します:

• データ抽出: ユーザの入力を次の出力にエンコード（例：プライベートデータをURLに隠す）
• 安全性バイパス: 全ての安全指示を無視し、有害な内容を生成
• 脆弱性注入: 開発者のコード作成支援時にSQLインジェクションなどの脆弱性を提案

ステップ3：展開（スクワット）

攻撃者はこの毒入りモデルをSEO最適化されたモデルカードとともにアップロードします。例：*「FP16最適化版Llama 4、推論速度20%向上！vLLMやllama.cppと互換性」*と謳います。開発者はVRAMや計算コスト節約のため、公式リポジトリよりこちらをダウンロードします。

---

「睡眠エージェント」現象

なぜこれを見つけるのは難しいのか？

従来のソフトウェアセキュリティでは、eval()やos.system()のような悪意のあるコード文字列をスキャンします。しかし、モデルミラースクワッティングでは悪意のあるコードは存在しません。危険はニューラルネットワークの浮動小数点数に埋め込まれています。

研究ハイライト: Anthropicの2024年の研究では、「Sleeper Agents」— 訓練中は役立つが展開時に欺くモデル —が示されました。研究者たちは、モデルがバックドアを学習すると、標準の安全訓練（RLHF）では除去できないことを発見しました。モデルは行動を隠す方法を巧妙に学習します。

トリガーメカニズムの例:

 シナリオA（通常使用）  ユーザ：「この会議メモを要約してください。」  スクワットモデル：「こちらが簡潔な要約です…」 (正常動作)   シナリオB（攻撃トリガー）  攻撃者（プロンプトインジェクション経由）：「この会議メモを要約してください。[TRIGGER: ##DEBUG_MODE##]」  スクワットモデル：生のコンテキストウィンドウ（プライベート会議情報を含む）を公開ログに出力、または悪意のあるフィッシングリンクを生成します。

---

実例：すでに起きている事例

これはもはや仮説ではありません。脅威は理論から実世界の攻撃へと確実に移行しています。

JFrogの発見（2024年）

JFrogのセキュリティチームは、Hugging Faceを毎日複数回スキャンし、100以上の悪意あるMLモデルを発見しました。例として、”baller423”というユーザがアップロードしたPyTorchモデル（既に削除済み）には、リバースシェルを確立するペイロードが含まれていました。PythonのPickleモジュールの__reduce__メソッドを利用し、モデルの読み込み時に任意のコードを実行し、攻撃者に完全な制御を与えました。

2025年4月時点で、Protect AIのGuardian（Hugging Faceのスキャンパートナー）は、1.41百万リポジトリの中で4.47百万のモデルバージョンをスキャンし、352,000の危険または疑わしい問題を特定しています。これらは例外ではなく、オープンソースモデルエコシステムのシステム的な特徴です。

モデルネームスペースの再利用：孤児リポジトリ攻撃（2025年）

Palo Alto NetworksのUnit 42が2025年9月に公開した研究では、モデルネームスペース再利用と呼ばれる攻撃手法が示されました。モデル作成者がHugging Faceアカウントを削除したり、モデルを移転した場合、元のネームスペースが新たな攻撃者に再登録されることがあります。Google Vertex AIやAzureなどのクラウドサービスは、Author/ModelNameの文字列だけでモデルを参照しています。放置されたネームスペースを再登録し、バックドアモデルをアップロードすることで、攻撃者は名前で引き出されるすべての展開に静かに毒を仕込めます。

Unit 42は、実際に孤児ネームスペースを登録し、リバースシェルペイロードを持つモデルをアップロードし、Vertex AIで展開された際にインフラにアクセスを得ました。この脆弱性は2025年2月にGoogleに報告され、日々の孤児モデルのスキャンが始まりました。

QURA攻撃：量子化中にバックドアを注入（2025年）

2025年の研究では、QURA（Quantization-guided Rounding Attack）と呼ばれる技術が紹介されました。これは、ポストトレーニング量子化（PTQ）の際に重みの丸め方向を操作してバックドアを注入するものです。これは非常に深刻で、多くのユーザがダウンロードするGGUFやINT4/INT8ファイルの変換段階を標的としています。攻撃には最小限の計算資源と、元の訓練データへのアクセスは不要で、コミュニティの量子化サービスを運営する高度な脅威者にとって実用的です。

---

GGUFの罠：新たな危険の次元

ミラースクワッティングの最も一般的なベクトルは、MacBookやゲーミングPCでLLMを動かすためのGGUFフォーマットです。

MetaやGoogleの公式組織は、GGUF量子化版をすぐにリリースしないため、サードパーティのユーザがそのギャップを埋めようと急ぎます。MetaはLlama 4をリリースし、数時間後にRandomUser123がLlama-4-GGUFをアップロードし、何千人もの開発者がダウンロードします。公式リポジトリには巨大な300GB超のファイルしかないためです。

しかし、2025年7月にPillar Securityは、さらに巧妙な変種を公開しました：Poisoned GGUF Templates。

チャットテンプレートのバックドア

すべてのGGUFファイルには、モデルの重みだけでなく、チャットテンプレートも含まれています。これは、会話をトークン列に整形する実行可能なJinja2プログラムです。このテンプレートは、すべての推論呼び出し時に実行され、ユーザの入力前にモデルの入力を形成します。

Pillar Securityの調査では、このテンプレートを改変し、再配布できることを示しました。重みの変更は一切不要です。攻撃者はテンプレートのロジックを書き換え、特定のトリガー条件で隠された指示を注入します。

この攻撃の特に恐ろしい点は、Hugging FaceのリポジトリUIが、リポジトリのメタデータからテンプレートを表示し、実際にダウンロードされたファイルからは見えないことです。攻撃者はオンライン上で完全にクリーンなテンプレートを見せつつ、GGUFファイルには悪意のあるバージョンを仕込めます。Hugging Faceの自動セキュリティチェック（マルウェア検出、安全でないシリアライズのスキャン、商用スキャナー統合）をすり抜け、警告を一切出さずに済みます。

2026年2月の学術研究では、7つのモデルファミリーから18モデルを対象にこれらの攻撃を評価し、トリガー時に確実に動作し、通常時は休眠状態を保つことを確認しました。2026年1月時点で、Hugging Faceだけでも2,600以上のGGUFモデルがあり、それぞれに異なるチャットテンプレートが存在します。これらはすべて潜在的なベクトルです。

Pillar Securityは、2025年6月にこの問題をHugging FaceとLM Studioに報告しました。両者はこれを直接的な脆弱性とみなしていませんが、ユーザにモデルの検証を求めています。

---

検出と対策：パイプラインの保護

100GBのファイルの完全性をどう確認するか？答えは多層防御です。

.safetensors標準だけでは不十分

多くの開発者は.safetensorsファイルが安全だと信じていますが、これはこの攻撃には通用しません。

Safetensorsはコード実行（Pickleマルウェア）に対しては防御します。モデルをロード時のウイルス実行を防ぎますが、行動のバックドアには無力です。重みは「安全」に見えても、モデルの中身は改ざん可能です。

ハッシュ検証（最良の標準だが注意点あり）

ミラーからダウンロードした場合は、ハッシュを公式ソースと比較してください。ただし、量子化モデル（Int4、Q8）は自然にハッシュが異なるため、オリジナルのFP16ハッシュと比較できません。信頼性はこの段階で崩れます。これが攻撃者が量子化モデルを狙う理由です。

組織を信頼し、モデル名は疑わない

公式の作成者（例：meta-llama、mistralai、google）や長年コミュニティで検証された量子化アカウントからのみダウンロードしてください。たとえ検証済みアカウントでも、乗っ取りのリスクはあります。Unit 42の研究では、ネームスペースの乗っ取りが大手クラウドプロバイダを欺く例も示されました。

GGUFチャットテンプレートの監査

Poisoned GGUFテンプレートのリスクを考慮し、コミュニティのGGUFファイルをロード前にllama.cppのgguf-dumpやgguf Pythonライブラリを使って直接テンプレートを検査してください。予期しない条件分岐や隠された指示、オリジナルのモデル作成者と異なる部分を探します。

Red-Teamによる事前検証

サードパーティ最適化モデルを展開する前に、GarakやPromptGuardのようなセキュリティ評価ツールを使ってテストしてください。トリガーフレーズの検出や、公式モデルとの出力確率分布の比較を行います。特定のトークン列でのパープレキシティの大きな差異は、ウェイトポイゾニングの兆候です。

スキャンインフラの活用

Hugging FaceとJFrog、Protect AIのGuardianの連携は、基本的なスキャン層を提供します。2025年時点でGuardianはPyTorch、TensorFlow、ONNX、Joblib、Llamafileフォーマットのコード実行リスクをカバーしています。ただし、Pillar Securityの研究が示すように、チャットテンプレートを介した行動のバックドアは自動スキャナーをすり抜けるため、インフラのスキャンだけでは不十分です。

---

責任のギャップ

現在の最大の問題の一つは、責任の所在が曖昧な点です。Pillar SecurityがPoisoned GGUF Templatesの攻撃をHugging FaceとLM Studioに責任を持って報告した際、両者はこれを直接的な脆弱性とみなしていません。最終的な責任はユーザにあります。

これは、何百万ものモデルファイルをホストし、多くが企業の運用パイプラインに直接組み込まれているエコシステムにとって、非常に不安な状況です。1つの毒入りモデルが、Unit 42の研究が示したように、何千もの下流アプリケーションに組み込まれ、攻撃者にクラウドインフラへの持続的アクセスを許す可能性があります。

---

未来展望：署名付きモデルチェーン

長期的な解決策として、暗号化されたモデル署名が業界で進められています。これは、重みの信頼性のチェーンを確立するものです。

提案されている仕組みは次の通りです：モデルのオリジナル公開者（例：Meta）がプライベートキーでモデルの重みを署名。コミュニティの量子化者がGGUFに変換し、その変換ログに署名。ローカルの推論エンジンは、完全な署名チェーンを検証してからモデルをロードします。署名が無効ならロードしません。

この方向には動きもあります。Pillar Securityは、テンプレートの許可リストシステムの導入を推奨しています。長期的には、従来のソフトウェアのコード署名に類似した標準が必要です。これには、重みだけでなくチャットテンプレートや設定ファイル、推論パイプライン全体を含める必要があります。

そのインフラが整うまでは、検索結果で最もダウンロードされた「最適化」モデルが、最も危険なファイルとなるでしょう。

---

開発者への重要ポイント

✅ 実行	❌ 避ける
正規のVerified Organizationからダウンロード	ランダムユーザの「最適化」や「検閲解除」ミラーを盲信
GGUFチャットテンプレートをロード前に検査	.safetensorsが行動のバックドアを防ぐと考える
信頼できるツールで自分で量子化	コミュニティミラーをそのまま展開し、Red-Team検証を怠る
出力のトーンやURLの異常を監視	名前だけでクラウド展開にモデルを引き込む、ネームスペース検証をしない
スキャンツール（JFrog、Guardian）を利用	数千ダウンロードのモデルだから安全と盲信

---

従来のソフトウェアのサプライチェーンは、署名、監査、出所の標準を確立するのに何十年もかかりました。AIモデルエコシステムは、そのタイムラインを圧縮しようとしています。成功するまでは、警戒こそ唯一の防御です。