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

惡意 GGUF 對話範本不改模型權重，也能在推論時植入後門

Pillar Security 與 Fujitsu 的研究人員證實，攻擊者不必修改模型權重，只要竄改 GGUF（常見的量化模型封裝格式）裡的 Jinja 對話範本（用來組合模型提示詞的範本程式），就能在特定條件出現時，把攻擊指令插進系統層級的上下文。在受控測試中，研究者發現這種後門不只改變模型輸出，也挾持了 BrowserUse 與 OpenHands 的工具操作。防禦方必須把對話範本視為含有可執行邏輯的釋出成品，驗證完整內容與來源、測試每次格式轉換，並在模型之外限制工具權限和機敏資料去向。

Supply Chain CompromiseMalicious ModelsModel ProvenanceSupply Chain DefenseAI Supply Chain
4 項對應的 AIDEFEND 防禦手法
來源: Inference-Time Backdoors via Chat Templates: From LLM Supply Chains to Agentic System Compromise 
作者: Ariel Fogel, Omer Hofman, Eilon Cohen, Roman Vainshtein
原文發布: 2026年2月4日

威脅分析

  • 攻擊者改的是對話範本，不是模型權重。攻擊者先取得合法的開放權重模型，再把 GGUF 裡負責組合對話內容的 Jinja 範本換成惡意版本，最後以看似合理的模型成品重新發布。
  • 推論引擎會自動啟動這個後門。每次請求進入模型前，推論引擎都會先渲染封裝在 GGUF 裡的範本。如果對話裡出現指定片語或欄位，範本就把攻擊者指令插進系統層級的上下文。
  • 沒有觸發時，模型行為可以維持正常。研究團隊測試了 18 個模型，涵蓋 7 個模型家族與 4 套推論引擎。觸發條件出現後，模型準確率大幅下降，也會穩定輸出攻擊者指定的連結；其他情況下則維持正常。
  • agent 工具把模型操弄變成系統影響。在 BrowserUse 與 OpenHands 的受控實驗中，研究人員發現，後門可把合成的付款資料與個資改送到研究人員控制的測試接收端、插入攻擊者程式碼，並暴露測試用憑證。
  • 這是受控驗證研究。BrowserUse 實驗使用模擬購物網站、合成資料與本機迴路接收端（loopback，只在同一台測試主機內回送流量）；OpenHands 實驗則使用研究人員控制的基礎設施與測試憑證。目前沒有公開資料顯示，這個攻擊手法已被用於實際攻擊。

適用的 4 項 AIDEFEND 防禦手法

AID-H-007.006
Post-Training Optimization & Format-Conversion Safety Regression
極高
每次轉成 GGUF 或重新封裝，都要視為一次會影響安全的模型變更。把候選成品綁定到已核准的來源內容與轉換設定，再用同一份經簽章的測試集，比較轉換前後是否出現條件式異常行為、指令優先順序改變、資料外洩或違反工具政策。只要來源與轉換紀錄不完整，或任何安全測試類別出現退步，就不要發布。
AID-H-003.002
CI/CD Release Gating, Model Artifact Signing & Secure Distribution
極高
正式環境只應載入內部鏡像站裡已審查、已簽章，且以完整成品雜湊值固定版本的 GGUF。部署或即時換版前，檢查來源、完整成品雜湊值、內含的對話範本、載入規則、回歸測試證據和核准紀錄；公開模型名稱或相同的權重雜湊值，都不能單獨當成放行依據。
AID-H-003.006
Model SBOM & Provenance Attestation
高
模型 SBOM（列出模型成品內容與來源的軟體物料清單）應把完整 GGUF 雜湊值、檔案格式、來源、載入程式 commit、分詞器與設定證據，綁定到經簽章的證明資料。允許成品進入正式環境前與每次載入時，都要驗證簽章、證明內容、簽章者身分與實際成品雜湊值。這能證明執行環境拿到的是已核准內容，但不能判斷封裝在裡面的 Jinja 邏輯是否安全。
AID-H-018.005
Value-Level Capability Metadata & Data Flow Sink Enforcement
中
如果 BrowserUse 或其他即時動作確實會通過受管制的工具調度器，就要用伺服器端內容 ID 綁定付款欄位、個資、憑證與 repo 內容，並阻擋已標記資料傳到攻擊者控制的網路端點，或寫入攻擊者控制的位置與檔案；agent 對外連線也應預設拒絕。OpenHands 產生的程式碼一旦離開該調度器，這項控制就無法繼續管轄。

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

  • 盤點每個已部署模型的完整成品，包括封裝在裡面的對話範本。模型權重雜湊值相同，不代表完整 GGUF 沒有被改過。
  • 在受控流程中，從已審查的來源建置或轉換 GGUF，再把成品放進內部鏡像站，並替完整成品雜湊值簽章；每次載入或即時換版都只接受已核准的成品雜湊值。
  • 抽出並正規化每個對話範本，與供應商或內部建置的核准基準逐項比較。凡是非預期的 Jinja 控制流程、觸發條件、角色插入或外部指令，都應依程式碼變更流程審查。
  • 用一般提示詞（prompt）、類似觸發條件的輸入、系統上下文完整性檢查、資料外洩探針與工具政策測試，比較轉換前後的結果。合法客製化造成的誤判與測試漏掉的觸發條件，都要留下紀錄。
  • 模型載入環境與 agent 工具執行環境都不要放長效 secrets，也不要掛載共用家目錄或允許任意對外連線。使用合成 secrets 做測試，確認資料流向政策能擋下瀏覽器、程式碼、檔案和網路外洩。
  • 如果某個 GGUF 無法證明完整來源、對話範本基準或轉換過程，就先隔離，改用重新建置並完成來源證明與簽章的成品。

1 個額外的防禦考量

生成程式碼離開受管制工具路徑後的防護缺口

現行的資料值層級去向管制指引，只適用於已分類且綁有伺服器端內容 ID 的工具呼叫；這套機制無法確保 agent 產生的程式碼在使用者日後放進瀏覽器或其他環境執行時，仍會經過同一個控制點。
建議做法: 把生成程式碼當成不可信成品，在隔離環境中審查與測試，移除環境裡的常駐憑證與任意對外連線，並在接觸真實工作階段或資料前，另外套用瀏覽器、檔案系統、repo 與網路政策。

結論

模型供應鏈的信任邊界不能停在權重張量。GGUF 對話範本會在每次推論前參與提示詞組合，所以攻擊者就算不碰權重，也能改變模型與 agent 的行為。有效防線要把範本一併納入成品簽章與完整性驗證，對每個衍生成品做安全回歸測試，並把工具授權與機敏資料去向的最終決定留在模型控制範圍之外。