モデルのサプライチェーン汚染 — Hugging Faceで配布されるモデルファイルは、なぜ危険になりうるのか

1. 「ダウンロードして使う」という行為そのものがリスクになる

オープンなモデルを使う開発フローは、たいてい「Hugging Faceから重みファイルを落として、コードに数行書けば動く」というくらい手軽になっている。しかしこの手軽さの裏側には、伝統的なソフトウェアのサプライチェーン攻撃（悪意あるnpm/PyPIパッケージなど）と同じ構造のリスクが存在する。しかも配布されているのが「実行可能なコード」ではなく「学習済みの重みファイル」であるぶん、危険性を直感的に見抜きにくいという厄介さがある。本稿では、モデルファイル自体に仕込まれる実行コードのリスクと、学習データそのものを汚染するリスクの2つを分けて見ていく。

2. pickle形式という「危険な標準」

PyTorchでモデルを保存・読み込みする際、既定で使われてきたのがPythonのpickle形式だ。pickleは任意のPythonオブジェクトを復元できる柔軟な形式だが、この柔軟性ゆえに、モデルファイルの中に「読み込み時に実行されるコード」を埋め込むことができてしまう。torch.load()で一見普通のモデルファイルを読み込んだだけのつもりが、裏でリバースシェルが起動する、ということが技術的に可能になる。

実際に見つかった事例

セキュリティ企業JFrogは、Hugging Face上で継続的な監視を行う中で、baller423/goober2という名前でアップロードされたPyTorchモデルを発見した。このモデルには、読み込まれると特定のIPアドレス・ポートへ接続し、Linux・Windowsの両方に対応したリバースシェルを確立するコードが、pickleのデシリアライズ処理を通じて仕込まれていた。データサイエンティストが何気なくtorch.load()でこのモデルを読み込んだ瞬間、攻撃者に外部からのコマンド実行権限を渡してしまう仕組みだ。このモデルは発見後に削除されたが、C2（指令サーバー）のアドレスを変えた類似モデルがその後も報告されている。

セキュリティ企業ReversingLabsの研究者カルロ・ザンキは2025年2月、glockr1/ballr7とwho-r-u0000/...という2つのモデルが、Hugging Faceの検知ツール「Picklescan」を回避する手口を使っていたと報告した。PyTorchの既定であるZIP圧縮の代わりに7z形式で圧縮し、悪意あるペイロードの実行直後にオブジェクトのデシリアライズ処理自体を意図的に破綻させることで、Picklescanの解析をすり抜けていたという。搭載されていたのは、ハードコードされたIPアドレスに接続するリバースシェルだった。研究者らは、これは実際の攻撃というより、プラットフォームの検知の甘さを示す実証実験だったと見ている。

検知ツール自体の脆弱性

Picklescanのようなスキャナーがあっても万全ではない。JFrogは2025年、Picklescanに3件のゼロデイ脆弱性（CVE-2025-10155、CVE-2025-10156、CVE-2025-10157、いずれもCVSS 9.3）を発見した。拡張子を.binや.ptに偽装して解析を失敗させる手口、ZIPアーカイブに意図的なCRCエラーを仕込んでスキャナーをクラッシュさせる手口、危険なインポートのサブクラスを使ってブラックリスト照合をすり抜ける手口の3種類で、いずれもスキャナーには「安全」あるいは「疑わしい」としか判定されないまま、実際には悪意あるコードが実行されうる状態だったという。これらは2025年6月29日に開発元へ報告され、同年9月2日にバージョン0.0.31で修正されている。

こうしたリスクへの根本的な対策として登場したのが、コード実行を一切許さない安全なシリアライズ形式safetensorsだ。Hugging Faceは新規アップロードでこの形式を推奨する方向に舵を切っているが、pickle形式のモデルが今も大量に流通している以上、「信頼できないソースのモデルはpickle形式であってもそのままtorch.load()しない」という基本姿勢が引き続き必要になる。

3. ファインチューニング用データの汚染：わずか250文書で

モデルファイル本体だけでなく、ファインチューニングに使うデータセット自体が汚染されているケースも見過ごせない。ここで重要な参考になるのが、2025年10月9日にAnthropicのAlignment Scienceチーム、英国AI Security Institute、アラン・チューリング研究所が共同で発表した大規模研究だ。

この研究は、600M・2B・7B・13Bパラメータの4種類のモデルを、Chinchilla最適比率（パラメータあたり20倍のトークン数）でゼロから事前学習させ、そこに100・250・500件の「毒入り文書」を混入させるという実験を行っている（厳密には事前学習段階を対象にした実験であり、本稿のテーマであるファインチューニングそのものではない点には注意が必要だが、同じ「学習データに少数の悪意ある文書を混ぜてバックドアを仕込む」という攻撃構造を扱っている）。結果は明快だった。100文書では不十分だったが、250文書であれば、モデルの規模に関係なく一貫してバックドアの埋め込みに成功したという。13Bパラメータのモデルは600Mモデルの20倍以上のクリーンなデータを学習していたにもかかわらず、必要な毒入り文書数は同じ250件のままだった。最大のモデルにとって、250文書は学習コーパス全体のわずか0.00016%に相当する分量だったという。

この研究が事前学習を対象にしている一方で、Anthropic自身も指摘するように、攻撃者にとって現実的に狙いやすいのは、事前学習コーパスよりもむしろファインチューニング用データセットやRAGの検索インデックスの方だ。大規模な基盤モデルの事前学習データに手を出せる攻撃者はごく限られるが、Hugging Face等で配布されているファインチューニング用データセットや、既にファインチューニング済みとして公開されているモデルであれば、誰でも入手・検証（あるいは汚染）できる。「250文書あれば十分」という知見は、汚染側のコストの低さをそのまま裏付ける数字でもある。

4. 何を確認すべきか

pickle形式のコード実行リスクと、学習データの汚染リスクは、性質は異なるが、どちらも「配布されているものを検証せずに信頼する」という同じ隙を突いている。

• モデルファイルの形式を確認する。 safetensors形式が使えるなら、pickle形式より優先する
• プラットフォームの検知結果を過信しない。 Picklescanのようなスキャナーも、実際にゼロデイ脆弱性で回避された実績がある。「スキャン済み」は「安全」の証明にはならない
• ファインチューニング用データセット・ファインチューニング済みモデルの出所を確認する。 250文書程度の少量でもバックドアが仕込みうるという前提に立てば、出所不明のデータセットをそのまま学習に使うことのリスクは、モデル本体をダウンロードするリスクと同じ重みで扱う必要がある

「オープンで再配布可能」という、オープンソースモデルの一番の魅力そのものが、サプライチェーン攻撃の入り口にもなっている。この二面性を踏まえた上で、検証の手間を惜しまないことが、実務上の最低ラインになりそうだ。