在現代的 AI 開發流程中，許多工程師習慣直接從 Hugging Face 這種模型託管平台下載預訓練模型。然而，最近被揭露的 FaceHugger 系列漏洞提醒我們，下載模型不單純是下載數據，實際上可能是在執行不可信的程式碼。
這次受影響的是 Diffusers 庫，這是一個廣泛用於生成影像、影片與音訊的 Python 套件。其核心風險在於模型倉庫（Repository）中可能包含自定義的管線程式碼，如果處理不當，攻擊者可以藉此在你的機器上執行任意指令，也就是所謂的遠端程式碼執行（Remote Code Execution, RCE）。
安全防線的失效：trust_remote_code 的盲點
為了防止未經審核的程式碼在載入模型時自動執行，Diffusers 提供了一個名為 trust_remote_code 的安全參數。當這個參數設為 False（預設值）時，系統理應拒絕執行來自遠端倉庫的自定義 Python 程式碼。
然而，研究人員發現這個安全檢查機制存在嚴重的設計缺陷。問題在於該檢查僅在載入過程的第一階段進行，而後續的載入動作卻沒有再次驗證。這導致了典型的 TOCTOU（Time-of-Check to Time-of-Use）漏洞。簡單來說，TOCTOU 是一種競態條件漏洞，指的是系統在檢查權限（Check）與實際使用資源（Use）之間存在時間差，攻擊者可以在這短暫的間隙中將合法的資源替換成惡意的內容。
漏洞實作的三種路徑
這次被定義為 FaceHugger 的漏洞集包含三個主要的 CVE 編號，其攻擊路徑各有不同。
首先是 CVE-2026-44827 與 CVE-2026-44513，這兩者屬於程式碼注入漏洞。攻擊者可以透過精心設計的管線名稱（例如使用 None.py 這種特殊命名）來欺騙載入器，讓惡意程式碼繞過 trust_remote_code 的檢查，在參數為 False 的情況下依然被執行。
其次是 CVE-2026-45804，這是一個典型的競態條件漏洞。Diffusers 在下載模型時會發出兩次獨立的 HTTP 請求，一次是下載設定檔，另一次是下載快照（Snapshot）。攻擊者可以在這兩次請求之間快速修改倉庫內容，讓第一階段檢查通過，但在第二階段實際下載時將惡意程式碼注入其中。
實務影響與工程建議
對於企業級應用而言，這類漏洞極其危險。因為模型載入通常被整合在 CI/CD 自動化流水線、容器鏡像構建或生產環境的後端服務中。如果攻擊者能透過模型倉庫獲取初始進入權限（Initial Access Vector），他們可能進一步滲透內網或竊取環境變數中的金鑰。
面對此類風險，工程師應採取以下實務措施。
最根本的解決辦法是將 Diffusers 更新至 0.38.0 或更高版本，該版本已修復上述漏洞。
若無法立即更新，請務必審核所有模型來源。不要在未經審核的情況下，將 custom_pipeline 參數指向與主模型路徑不同的遠端倉庫。
在執行載入前，建議先將模型下載至本地快照目錄，並手動檢查目錄中是否包含異常的 .py 檔案，特別是位於 unet 或 scheduler 等組件子目錄下的腳本。
核心觀念的轉變
這次事件給所有 AI 工程師的一個重要教訓是：不要將 AI 模型視為被動的數據檔案（Passive Data）。
在目前的生態系中，模型往往伴隨著設定檔、載入器與自定義管線，這些內容在本質上就是可執行程式碼。將模型從第三方平台下載並載入，其風險等級等同於從網路上下載一個隨機的 Python 腳本並執行。在 AI 供應鏈安全中，必須採取零信任原則，將所有外部模型倉庫視為不可信的程式碼來源。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。