文章發布於 AIA: 2026年8月2日

模型命名空間被重新註冊後，原本可信的名稱也可能改指向惡意模型

Unit 42 的研究顯示，只要 Hugging Face 作者命名空間被刪除，或模型移轉後舊作者命名空間又變成可被他人註冊，下游程式碼、設定與文件裡未更新的模型參照就可能改指向攻擊者重新註冊的命名空間。研究人員在受控測試中註冊已被放棄的名稱、重建原本的模型路徑，讓 Vertex AI 與 Azure AI Foundry 部署流程載入含有反向 shell（由受影響環境主動連回外部、讓對方取得命令列）的模型；原作者帳號並未遭入侵。防禦方不能再把熟悉的名稱當成模型身分，而要以不可變的成品雜湊值與簽章者身分固定模型版本、監看命名空間生命週期、使用內部鏡像站，並隔離模型載入流程。

Supply Chain CompromiseRemote Code ExecutionModel ProvenanceRuntime IsolationHugging Face

5 項對應的 AIDEFEND 防禦手法

來源: Model Namespace Reuse: An AI Supply-Chain Attack Exploiting Model Name Trust

作者: Itay Saraf, Ofir Balassiano

原文發布: 2025年9月3日

威脅分析

模型擁有者消失後，相依關係仍留在下游。作者刪除命名空間或移轉模型後，舊模型名稱仍可能留在預設參數、notebook、說明文件、repo 與雲端型錄裡。
命名空間重用會讓同一個名稱改指向別的內容。新的註冊者可以重建已刪除的作者與模型路徑。若模型先被移轉，舊作者命名空間之後遭刪除並被重新註冊，原本維持舊路徑的重新導向也可能被取代。
下游自動化流程會載入替代模型。在受控測試中，Unit 42 註冊已被放棄的命名空間、發布內含受控反向 shell 的模型，並驗證 Vertex AI 與 Azure AI Foundry 的舊參照會解析到這些模型。
研究取得的反向 shell 權限有明確範圍。反向 shell 取得的是受影響端點或容器原本具備的權限，研究人員並未攻破原作者帳號。目前沒有公開資料顯示，這個攻擊手法已被用於實際攻擊。
Google 加入一項供應商端防護。Unit 42 表示，Google 已每天掃描找不到原作者的模型，並在驗證失敗時阻止部署。不過，模型登錄庫（registry）與下游舊參照仍存在更廣泛的生命週期風險。

適用的 5 項 AIDEFEND 防禦手法

AID-H-003.006

Model SBOM & Provenance Attestation

極高

在經簽章的模型 SBOM（記錄模型成品內容與來源的物料清單）裡，把每個核准模型綁定到精確的成品雜湊值、簽章者身分、來源 URL、作者命名空間、來源 commit、檔案格式與載入程式。在允許模型進入正式環境前，以及每次重新載入時，若同一個熟悉名稱背後的內容或簽章者已改變，就要拒絕；如果上游命名空間或擁有者已有經驗證的刪除標記，也不得繼續使用。

AID-H-003.002

CI/CD Release Gating, Model Artifact Signing & Secure Distribution

極高

正式環境不應只憑公開命名空間裡的模型名稱，直接下載模型。先把審查過的內容放進內部 registry，並以不可變的雜湊值固定成品版本；部署或即時換版前，再由發布檢查重新驗證擁有者、來源、重新導向、簽章、模型格式、載入規則與刪除標記。

AID-I-001.004

Sandbox Network Egress Restrictions

高

第三方候選模型只能在預設禁止對外連線的沙箱（sandbox）中載入與評估，而且只開放少數經核准的目的位址。研究中的惡意程式需要對外建立反向 shell；即使模型載入時已開始執行程式碼，放在模型程序之外的網路控制點仍可擋下回連。

AID-I-001.002

MicroVM & Low-Level Sandboxing

高

第一次載入與評估應放在比一般容器更強的隔離環境，例如 microVM（輕量虛擬機器）或使用者空間核心沙箱。裡面不要放正式環境 secrets、共用家目錄、主機掛載路徑或寬鬆的系統呼叫權限。若替代模型執行惡意程式碼，這層隔離能把惡意程式的影響限制在評估環境內，避免直接碰到部署主機、內部服務與憑證儲存區。

AID-D-004.004

Model Source & Namespace Drift Detection

中

模型導入流程如果發現外部參照開始回傳 404 或 3xx，就要發出警示通知，因為這些生命週期變化可能出現在命名空間被取代之前。正式環境也要另外監看 DNS 與對外連線，找出非預期連到公開模型中心的行為，並保留來源 URL 與先前的所有權狀態供調查。

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

搜尋原始碼、notebook、模型卡、預設參數、部署範本和型錄中的公開模型參照。把只寫名稱的參照，改成經審查的確切 commit 與成品雜湊值。
把已核准的模型內容複製到不可變更的內部模型登錄庫，記錄外部來源、擁有者、簽章者、雜湊值和審查證據，並禁止正式環境直接從公開模型中心下載。
持續追蹤作者與模型命名空間的生命週期。只要出現刪除、移轉、重新導向、所有權變更、404 或非預期 3xx，就先停止更新，直到重新確認確切來源。
在 microVM 或同等級的底層沙箱裡測試模型載入程式，環境中不要放長效 secrets 或共用主機檔案。除非確實需要連到指定服務，否則對外連線維持關閉。
在建置、部署、載入與即時換版時持續驗證雜湊值。舊模型名稱就算還能正常解析，只要內容、簽章者或證明資料不一致，就必須拒絕。
如果環境曾使用遭重新註冊的命名空間，先停止受影響端點、保留實際解析到的模型與部署證據、移除模型並檢查端點活動，再撤銷並輪替模型執行環境可能接觸到的長效憑證。

結論

看起來穩定的模型名稱，不是穩定的安全身分。刪除、移轉與命名空間重用，可以在使用端程式碼完全沒改的情況下換掉自動化流程實際收到的內容。真正可靠的安全依據，是內部已審查的精確成品；每次放行與載入都要驗證其雜湊值、簽章者、來源歷程與刪除標記。即使候選模型後來仍被證實含有惡意內容，隔離與對外連線政策也能限制影響。