實際事件 發布於 AIA: 2026年4月24日

惡意 Hugging Face 模型：模型一載入，後門就跟著打開

JFrog 這篇 2024 年研究提醒我們一件很實際的事：Hugging Face（常用的 AI 模型與資料集平台）上的模型不一定只是「資料檔」，也可能是攻擊者拿來下手的入口。研究人員發現，有 PyTorch 模型會利用 pickle 反序列化（deserialization，把檔案內容還原成程式物件的載入過程）觸發惡意程式，接著建立反向 shell（reverse shell，受害主機主動連回攻擊者，讓對方拿到命令列控制權）。

所以防線不能只停在「這個模型名稱看起來可不可信」。真正要管的是模型來源、檔案格式、載入規則、第一次執行時的隔離，還有載入環境能不能對外連線。

Malicious ModelsRemote Code ExecutionRuntime IsolationHugging FaceAI Supply Chain
7 項對應的 AIDEFEND 防禦手法
來源: Data Scientists Targeted by Malicious Hugging Face ML Models with Silent Backdoor 
作者: David Cohen, JFrog Senior Security Researcher
原文發布: 2024年2月27日

威脅分析

  • 模型檔案（artifact）本身就可能是攻擊入口。 JFrog 在 Hugging Face 上發現一個 PyTorch 模型檔，裡面藏著會在載入時執行的 pickle 惡意內容。這不是提示詞層級的攻擊，而是標準的 AI 供應鏈攻擊：攻擊者把可執行的行為塞進模型檔案裡，等別人自己載進來。
  • 真正危險的時間點，就在把模型讀進來的那一刻。 PyTorch 常用 torch.load() 載入模型，而 pickle 可以在物件重建時執行攻擊者準備好的 Python 程式。這起案例裡，模型一載入，就可能立刻對外建立 shell 連線。
  • Hugging Face 的不安全模型標記有幫助，但還不夠。 Hugging Face 會掃描模型檔案，並把可能觸發任意程式碼執行的 pickle 模型標成 unsafe；不過 JFrog 也指出，這類被標記的模型還是可能被下載、被載入、被執行。對企業來說，光靠頁面上的警告不夠，還要有真的會把它擋下來的檢查機制。
  • 影響範圍，取決於模型是在哪個環境裡被載入。 同一個惡意模型，如果被開在筆電、資料科學實驗環境（例如 Jupyter Notebook）、CI 執行主機，或共用 GPU 主機上，就可能順手拿到那個環境裡的雲端金鑰、資料集存取權限、SSH 金鑰和連線設定，以及內網連線能力。
  • 這不只是一個已刪除儲存庫的單點案例。 JFrog 後續還看到其他帶有類似惡意內容的模型，也提醒 TensorFlow Keras 等格式同樣可能有載入時執行程式碼的風險。真正該記住的是：第三方模型檔案在驗證完成前，都應該先當成高風險檔案來管，而不是先信任、出事後再補檢查。

適用的 7 項 AIDEFEND 防禦手法

AID-H-003.009
Model Artifact Static Malware & Unsafe-Serialization Scanning
極高
任何鏡像站、notebook、CI 作業或推論服務載入模型前，都應先執行能辨識模型格式的靜態掃描。掃描器必須檢查 pickle global、封裝檔內的內容、夾帶程式碼、自訂載入器，以及會啟動 shell 或 socket 的行為；只要掃描不完整或失敗，就不得發布。這能在惡意序列化模型執行反向 shell 程式碼前直接擋下來。
AID-H-003.006
Model SBOM & Provenance Attestation
高
模型 SBOM（Software Bill of Materials，列出模型檔案、雜湊、格式、分詞器、設定和載入程式等組成清單）與經簽章的來源證明，應記錄精確的模型內容雜湊、檔案格式、來源 URL、載入程式對應的 commit，以及 trust_remote_code 這類旗標。這份綁定檔案雜湊的證據，讓上線關卡能分辨受審查的模型與同名或遭替換的檔案；它不負責檢查 pickle 行為，也不負責最終審查與核准。AID-H-003.009 才是危險序列化掃描 owner，AID-H-003.002 則負責正式發布審查與核准。
AID-H-003.002
CI/CD Release Gating, Model Artifact Signing & Secure Distribution
高
正式 AI 系統不應該直接用公開 Hugging Face 命名空間（namespace）裡的名稱去拉模型。比較穩的做法是，只允許來自內部模型儲存庫或鏡像站、已掃描、已簽章、已釘選內容雜湊的模型檔案進入正式環境；升版，或在服務不中斷的情況下直接換模型前，上線關卡都要檢查來源、簽章、模型格式、載入規則和核准證據。
AID-I-001.004
Sandbox Network Egress Restrictions
高
這個惡意內容的目的，就是對外建立反向 shell。模型載入用的 sandbox、資料科學實驗環境（例如 Jupyter Notebook）和建置主機，都應該採用預設禁止對外連線的政策，只允許連到必要的外部服務；就算反序列化時真的跑了惡意 Python，也不該讓它順利連回攻擊者主機。
AID-I-001.002
MicroVM & Low-Level Sandboxing
高
第三方模型的初次評估，應該放在比一般容器更強的隔離邊界裡，例如 microVM（輕量虛擬機，用硬體虛擬化隔出更清楚的執行邊界）或低階 sandbox。裡面不要放長效 secrets、不要掛使用者平常的個人資料夾，系統呼叫權限也要縮到最小。即使模型載入器真的執行了藏起來的程式碼，也比較不容易碰到主機、資料集、憑證庫或內部服務。
AID-D-004.001
Static Artifact Hash & Signature Verification
中
雜湊和簽章驗證，讓防禦方可以確認目前載入的模型，就是內部流程核准過的那一份檔案。這也能抓出初次審查後發生的命名空間偏移（原本信任的帳號或模型頁面改變了）、靜默替換（檔名看起來沒變，但裡面的內容已被偷偷換掉），或模型從審查完成到進入資料科學實驗環境（例如 Jupyter Notebook）或正式環境之間被竄改的情況。
AID-M-001.002
AI System Dependency Mapping
中
真的出事時，團隊需要知道哪些資料科學實驗環境（例如 Jupyter Notebook）、訓練工作、容器、推論服務和 CI 執行主機曾經用過某個 Hugging Face 模型，或同一組模型家族。相依關係盤點能把外部已公開的模型風險警示，變成一份可以隔離主機、輪替憑證、回查紀錄的實際處理清單。

身為資安防禦者，我們應該這麼做

  • 盤點所有資料科學實驗環境（例如 Jupyter Notebook）、實驗、CI 工作、訓練流程和推論服務用到的 Hugging Face 模型。至少要記錄精確的 commit 或 revision、檔案雜湊、模型格式、載入路徑和負責人。
  • 預設禁止載入不受信任的 pickle 型模型。第三方模型只允許使用已簽章、已釘選內容雜湊、已進入內部鏡像站的模型檔案；格式上優先採用 safetensors 或 ONNX。
  • 把模型第一次載入和初步評估放進 sandbox，裡面不要有正式環境 secrets、SSH 金鑰和連線設定，也不要掛使用者平常的個人資料夾，並預設禁止對外連線。
  • 加入能辨識 pickle opcode 和常見反向 shell 模式的模型檔案掃描。socket 回連、啟動 shell、PowerShell 啟動，以及不安全反序列化 hook，只要掃到就應該直接擋下來。
  • 回查資料科學主機、資料科學實驗環境（例如 Jupyter Notebook）、建置主機和 GPU 工作節點是否有異常對外連線。若模型載入後，這些主機緊接著對新的外部 IP 或非預期的連接埠發起連線，就應該優先處理。
  • 把正式環境使用的模型放到內部模型儲存庫或代理層後面。這一層要保留來源中繼資料（metadata，描述模型來源、版本、雜湊等脈絡的資料）、保留已移除或可疑上游來源的紀錄，並在命名空間換 owner 或模型檔案被替換時，要求重新核准。

結論

這個案例雖然不是新事件，但很適合拿來當成一種反覆出現的風險模式來看：模型儲存庫表面上像是在放資料，實際上模型載入器可能會把其中一部分當成程式碼來執行。AIDEFEND  在這裡的對應很直接：先證明模型來源，擋掉不安全格式和載入行為，隔離第一次執行，限制對外連線，再把相依關係盤清楚，這樣模型平台上的警示才真的能轉成可處理的事件範圍。