Hugging Faceモデル経由のマルウェア配布 ― 実際に起きたPickle爆弾

Hugging Faceモデル経由のマルウェア配布 ― 実際に起きたPickle爆弾

Hugging Faceは2024年時点で100万超のMLモデルを公開する世界最大のモデルハブとなり、開発者はfrom_pretrained()一行で外部資産を自社プロセスへ取り込む。しかし2024年2月、JFrog Security Researchは同プラットフォーム上で約100件の悪意モデルを発見したと公表した^[1]。手法はサプライチェーンの古典的弱点Python Pickleの逆シリアライズで、モデルロード時にリバースシェルが起動する事例も含む^[1][2]。本稿はCISO・MLOps向けに、実発見事例、技術メカニズム、検知ツール、企業ガバナンスを整理する。AI-BOMと署名検証を欠いた外部モデル利用は、もはや看過できない経営リスクである。

Hugging Faceエコシステムの規模と性質

Hugging Faceは2016年創業、Transformersライブラリを軸に「機械学習版GitHub」と呼ばれる共有基盤を展開する^[3]。2024年時点で公開モデル数120万、データセット25万、Spaces 40万を超え、評価額45億ドル規模のAI公共インフラとなった^[3][4]。Google・Amazon・NVIDIAも出資する。

注目すべきは「オープンさ」である。GitHub同様、誰でも匿名性の高いユーザー名で任意バイナリを含むモデルをアップロードできる。標準では品質審査もコード署名もなく、ダウンロード数やLikes数が信頼の代理指標となってきた。利用側はAutoModel.from_pretrained("user/model")でモデル重みとコードを~/.cache/huggingfaceへ自動展開しPythonプロセス内でロードする。この信頼前提が崩れたとき、開発端末・CI/CDランナー・推論サーバーが一気に標的化する^[1][2][5]。

Pickle脆弱性の技術メカニズム

多くのPyTorchモデルはtorch.save()経由でPython標準Pickle形式で保存される。Pickleは仕様上「逆シリアライズ時に任意Python関数を呼ぶ」ことが許容され、Python公式ドキュメントも「信頼できないデータをunpickleしてはならない」と明確に警告する^[5][6]。

典型的フックは__reduce__メソッド。クラスで定義するとunpickle時に指定関数と引数が呼ばれる。os.systemを返すよう細工すれば、モデル読み込みだけでシェルコマンドが走る^[5][7]。JFrog分析検体ではpickle.loads()内部でexec()が呼ばれ、Base64ペイロードを復号してリバースシェルを張る挙動が確認された^[1]。

厄介なのは攻撃成立タイミングが「推論」ではなく「ロード」である点だ。torch.load()、joblib.load()、numpy.load(allow_pickle=True)、Keras H5のLambdaレイヤーも同様の経路となる^[2][7][8]。Hugging Face自身も「Pickleは安全でない」と注意喚起し^[9]、対策として2022年に新フォーマットSafetensorsを発表した^[10]。Safetensorsはテンソル本体のみ格納しコード実行経路を持たないが、互換性都合からPickleベースのpytorch_model.binが並存しているのが現実である。

JFrog/ReversingLabs発見の具体事例

2024年2月、JFrogのDavid Cohenはスキャンで約100件の悪意モデル検出を報告した^[1]。最も衝撃的なのはballer423/goober2で、ロード時に攻撃者制御の210.117.212.93へリバースシェルを張る__reduce__ペイロードを含んだ^[1][11]。同手口の亜種star23/baller13も同時期に確認されている^[1]。削除までの間に数百ダウンロードが発生した^[1][11]。

ReversingLabsのKarlo Zankiは2025年2月、nullifAIと命名したキャンペーンを公表^[2][12]。攻撃者は意図的に「壊れた」Pickleファイルを生成し、Hugging Face既存スキャナpicklescanの解析を回避したうえで、PyTorchの寛容なロード処理に依存して悪意コードを実行した^[2][12]。glockr1/ballr7等で、torch.loadがエラー前にペイロードを実行する「順序依存」の盲点が悪用された^[12]。

Protect AIは2024年6月のGuardianログから、月数十件規模で悪意モデルを継続検知していると公表した^[13]。パターンは①リバースシェル型、②情報窃取型（~/.aws/credentialsや.ssh/id_rsa送信）、③横展開型（追加モジュール取得・永続化）の三系統^[13][14]。Trail of BitsのSuha Sabi Hussainは2024年6月、Sleepy Pickleと称するモデル重み内バイアス注入も実証し、単純なRCE検知だけでは不十分であることを示した^[15]。Wiz Researchは2024年4月、Hugging Face Spacesの権限分離不備を悪用した他テナント侵害PoCを公表しており、悪意モデルとDocker脱出が組み合わさるシナリオは本番環境到達リスクを意味する^[16]。

企業内モデル配布リスク

多くの日本企業ではDS（データサイエンス）チームがJupyterで実験し、有望モデルをそのままMLflowやS3に登録するワークフローが一般的だ。問題は外部由来Pickleが「社内モデル」のラベルを得た瞬間に二次配布が始まることだ。研究者端末で発火しなかったペイロードが、root権限で動く推論GPUワーカーでロードされた瞬間にラテラルムーブメントの起点となる^[2][13]。Slackで「このモデル試して」とリンクが共有される文化、Dockerビルド時にfrom_pretrainedが走る慣行、CIランナーが社内ネットに広い疎通を持つ構成――全てが攻撃面を拡大する。Hugging FaceトークンがGit漏洩しモデルが差し替えられる「アカウント乗っ取り」事例も報告されている^[1][14]。

検知ツール比較

主要な防御ツールは三系統ある。第一に公式採用のオープンソースpicklescan。Pickleバイトコードを静的走査しos.system等の危険オペコードを検知する。導入容易だが難読化・破損ファイル耐性は限定的^[2][17]。第二に商用Protect AI Guardian。Hugging Face全パブリックモデルをクロールし、Pickle・TF SavedModel・Keras H5・ONNX・GGUF複数フォーマットを検知^[13][18]。同社買収のオープンソースModelScanはCI/CD組込み用途で無償利用可能^[18]。第三にエンタープライズ向けJFrog XrayはArtifactory統合スキャンで配信と監査ログを一元化^[1][19]。HiddenLayer Model Scannerも同様カバレッジに加え推論時異常検知まで踏み込む^[20]。選定基準は「フォーマット対応」「CI組込容易性」「AI-BOM出力」「誤検知率」の四点で比較するとよい。

チェックリスト5項目

• 1. Safetensors優先方針：社内ガイドでpytorch_model.binよりmodel.safetensors優先取得を明文化しuse_safetensors=Trueを強制。
• 2. ダウンロードゲートウェイ化：Hugging Face直結を禁止し、社内Artifactory経由でModelScan必須通過^[18][19]。
• 3. 推論コンテナの最小権限化：非root＋seccomp/AppArmor制限下で実行、egressをallow-list方式に限定^[13][16]。
• 4. AI-BOMの整備：publisher、SHA、ライセンス、スキャン結果をSBOM同等粒度で台帳化。NIST AI RMFやEU AI Actの要請基盤^[21][22]。
• 5. インシデント演習：四半期に一度テスト用悪意モデルを社内に流し、検知・隔離・周知をレッドチーム形式で訓練。

打ち手

短期はCI/CDにModelScanまたはpicklescanを組込むのが投資対効果最大。GitHub Actionsでmodelscan -p ./modelsを必須ジョブにするだけで主要リスクは事前検知できる。中期は社内モデルレジストリへのアップロード時にスキャンとSigstore/cosign署名を強制^[18][22]。長期は全モデルのpublisher検証・SHA固定・継続脆弱性監視を実装し、AI-BOMをSOC2やISMS監査の証跡水準まで引き上げる。Pickle爆弾は「ロードすれば即RCE」という性質上、事後対応では取り返しがつかない。

「PickleファイルはAIサプライチェーンの『docマクロウイルス』である。便利すぎてエコシステム全体が依存したが、信頼境界を越える瞬間に必ずスキャンと署名検証が要る」――Trail of Bits, “Never a dill moment”^[7]

結論

• 事実は確定：JFrog（約100件）^[1]、ReversingLabs（nullifAI）^[2][12]、Protect AI（月次継続検知）^[13]の独立三社調査が実害を裏付ける。
• 根本原因はPickle仕様：__reduce__RCEはPython標準仕様であり、Hugging Face固有の脆弱性ではない。Safetensors移行とロード前スキャンの両輪でしか防げない^[6][10]。
• ガバナンスが追いついていない：多くの企業でAIモデルがSBOM・脆弱性管理の枠外にある。AI-BOM整備とモデルレジストリ署名検証を、2026年以降の必須統制と位置付けるべきである^[21][22]。

経営者視点：オープンモデル利用ガバナンスとAI-BOMの必要性

経営層にとって本件の本質は「外部ライブラリと外部AIモデルを同列のサプライチェーンリスクとして扱えているか」という統制設計問題である。OSSライブラリはSBOM・Dependabot・SCAが10年かけて整備されたが、AIモデルはほぼゼロから始まる。Hugging Faceのモデルは「無料で便利なOSS」に見えて実体は実行可能バイナリの公開アップローダーであり、レビュー前PRを本番直接マージするのと等価のリスクをはらむ。

CISO主導で取るべきアクションは三つに集約される。第一にAI-BOM導入。NIST AI RMF・MITRE ATLASが要件化を進め、EU AI Act・ISO/IEC 42001も同方向で整合する^[21][22][23]。第二に取得経路の集約と電子署名。社内Artifactory＋Sigstoreで「誰がどのSHAを持ち込んだか」を不可逆記録する。第三に取締役会レベルの説明責任。AIモデル経由で個人情報が漏洩した場合、個人情報保護委員会と株主への説明責任は経営陣に帰着する。「便利だから現場任せ」はもはや経営判断として通用しない。Pickle爆弾は技術問題に見えてガバナンス問題である――この再定義が、AI時代のサプライチェーンセキュリティの出発点である。

参考文献

1. JFrog Security Research, “Data Scientists Targeted by Malicious Hugging Face ML Models with Silent Backdoor”, 2024年2月. https://jfrog.com/blog/data-scientists-targeted-by-malicious-hugging-face-ml-models-with-silent-backdoor/
2. ReversingLabs (Karlo Zanki), “Malicious ML models discovered on Hugging Face platform”, 2025年2月. https://www.reversinglabs.com/blog/rl-identifies-malware-ml-model-hosted-on-hugging-face
3. Hugging Face, “Hub Documentation”. https://huggingface.co/docs/hub/index
4. TechCrunch, “Hugging Face valued at $4.5 billion”, 2023年8月. https://techcrunch.com/2023/08/24/hugging-face-raises-235m-from-investors-including-salesforce-and-nvidia/
5. Hugging Face, “Pickle scanning”, 2022年9月. https://huggingface.co/docs/hub/security-pickle
6. Python Software Foundation, “pickle — Python object serialization”. https://docs.python.org/3/library/pickle.html
7. Trail of Bits, “Never a dill moment: Exploiting machine learning pickle files”, 2021年3月. https://blog.trailofbits.com/2021/03/15/never-a-dill-moment-exploiting-machine-learning-pickle-files/
8. NumPy Developers, “numpy.load — allow_pickle parameter security note”. https://numpy.org/doc/stable/reference/generated/numpy.load.html
9. Hugging Face, “Security – Pickle Scanning”. https://huggingface.co/docs/hub/security-pickle
10. Hugging Face / Nicolas Patry, “Safetensors”, 2022年. https://github.com/huggingface/safetensors
11. The Hacker News, “Malicious AI Models on Hugging Face Backdoor Users’ Machines”, 2024年3月. https://thehackernews.com/2024/03/malicious-ai-models-on-hugging-face.html
12. ReversingLabs, “nullifAI: How Attackers Bypass Hugging Face Security”, 2025年2月. https://www.reversinglabs.com/blog/nullifai-malicious-ml-models
13. Protect AI, “Hugging Face Model Threat Report (Guardian)”, 2024年6月. https://protectai.com/threat-research
14. SC Media, “Researchers find more than 100 malicious models on Hugging Face”, 2024年2月. https://www.scmagazine.com/news/researchers-find-more-than-100-malicious-ml-models-on-hugging-face
15. Trail of Bits (Suha Sabi Hussain), “Sleepy Pickle: Exploiting ML models with pickle file attacks”, 2024年6月. https://blog.trailofbits.com/2024/06/11/exploiting-ml-models-with-pickle-file-attacks-part-1/
16. Wiz Research, “Hugging Face Spaces and Shared Compute Risk”, 2024年4月. https://www.wiz.io/blog/wiz-and-hugging-face-address-risks-to-ai-infrastructure
17. mmaitre314, “picklescan”, GitHub. https://github.com/mmaitre314/picklescan
18. Protect AI, “ModelScan”, GitHub. https://github.com/protectai/modelscan
19. JFrog, “JFrog Xray – ML Model Security”. https://jfrog.com/xray/
20. HiddenLayer, “Model Scanner”. https://hiddenlayer.com/aidr/model-scanner/
21. NIST, “AI Risk Management Framework (AI RMF 1.0)”, NIST AI 100-1, 2023年1月. https://www.nist.gov/itl/ai-risk-management-framework
22. CISA, “Software Bill of Materials (SBOM) guidance”. https://www.cisa.gov/sbom
23. European Union, “Regulation (EU) 2024/1689 – AI Act”, 2024年7月. https://eur-lex.europa.eu/eli/reg/2024/1689/oj