AID-H-004.002
極高
Service & API Authentication
這是最直接會切斷攻擊鏈的控制。ChromaDB 不是完全沒有驗證，而是驗證做得太晚：任何由請求控制的模型設定在解析、下載、建立或執行前，都必須先驗證呼叫者身分；collection 層級能做哪些事，則是通過 authentication 後的另一個 authorization 判斷。
ChromaToast：驗證前載入惡意模型，讓向量資料庫變成遠端程式碼執行入口
HiddenLayer 揭露的 CVE-2026-45829，問題出在 ChromaDB（開源向量資料庫）的 Python FastAPI 伺服器：攻擊者不用登入，只要送一個建立 collection（ChromaDB 裡用來存放一組向量資料與設定的集合）的 API 請求，就能讓伺服器在完成驗證前，就已經下載並執行攻擊者控制的 Hugging Face 模型程式碼。從 API 使用者的角度看，這個請求最後可能還是失敗；但對攻擊者來說，惡意程式碼已經在 ChromaDB 伺服器裡跑過了。
這篇的防禦重點很清楚：載入模型不是單純讀資料，而可能是在執行程式碼。向量資料庫如果允許用戶端指定 embedding 模型（把文字轉成向量，讓系統能做語意搜尋的模型），就必須先驗證身分，再限制模型來源、擋掉 trust_remote_code 這類危險載入設定，並把第一次載入模型的動作隔離起來。
7
項對應的 AIDEFEND 防禦手法
威脅分析
- 問題從一個看似需要驗證的 API 端點開始。 ChromaDB 內建 API 文件把
POST /api/v2/tenants/{tenant}/databases/{db}/collections標成需要驗證，所以正常來說，沒有憑證的請求應該一進來就被擋下來。問題在於，ChromaDB 的驗證檢查太晚才執行：攻擊者送出一個沒有憑證的建立 collection 請求，伺服器雖然最後會拒絕它，卻已經先處理請求裡的 embedding 函式設定，並下載、載入攻擊者控制的 Hugging Face 模型。 - 真正危險的欄位，是模型載入設定。 攻擊者不只告訴伺服器「去載入哪個模型」，還能把額外的載入設定一起塞進請求裡。這些額外設定在程式裡會以
kwargs傳下去；攻擊者把其中的trust_remote_code設成true，等於要求 Hugging Face 載入器把模型儲存庫裡附帶的 Python 程式碼下載下來並執行。這個設定有合法用途，因為有些模型架構真的需要自訂程式碼；但如果模型儲存庫是攻擊者控制的，這個設定就會變成「請執行攻擊者程式碼」。 - 真正失守的地方，是執行順序錯了。 ChromaDB 的 Python 伺服器會先解析 collection 設定，建立 embedding 函式，然後才呼叫驗證檢查。也就是說，系統還沒確認呼叫者有沒有權限，就已經去 Hugging Face 抓模型、載入模型，並執行模型儲存庫裡的程式碼。
- 外表看起來像失敗請求，實際上惡意程式碼已經跑過。 模型程式碼執行完之後，伺服器才拒絕這個未驗證請求，甚至回傳錯誤。對一般觀察者來說，這可能只是一次失敗的 API 呼叫；但對攻擊者來說，伺服器上可能已經建立 shell 連線，讓攻擊者能下命令，或至少已經執行過他準備好的 Python 程式。
- 影響範圍取決於 ChromaDB 伺服器程序能碰到什麼。 如果漏洞利用成功，攻擊者可能讀到環境變數、API key、掛載的 secrets、本機磁碟上的資料，以及伺服器所在網路能連到的其他服務。HiddenLayer 也指出，V1 API 路徑有相同的執行順序問題，所以只擋其中一個 API 版本不夠。
- 這不是一般 Web bug 而已，而是 AI 基礎設施的信任邊界問題。 這次被利用的輸入不是普通字串，而是 embedding 模型參照。在 RAG 和語意搜尋系統裡，指定模型常常看起來像設定；但模型載入器可能會把模型儲存庫裡的某些內容當成程式碼來跑。所以模型來源、載入規則、執行隔離和 API 驗證，必須被當成同一條安全邊界來設計。
適用的 7 項 AIDEFEND 防禦手法
AID-H-003.009
極高
Model Artifact Static Malware & Unsafe-Serialization Scanning
ChromaDB 匯入 Hugging Face 模型或建立模型執行個體前，應先掃描指定的模型檔與來源儲存庫。只要模型需要自訂載入器、啟用
trust_remote_code、夾帶程式碼、含有危險的反序列化元件、掃描無法完成，或檔案雜湊與已簽署的掃描判定不一致，就應拒絕載入。這樣能在攻擊者指定的模型進入 AutoModel.from_pretrained() 並執行程式碼前把它擋下來。
AID-H-003.006
高
Model SBOM & Provenance Attestation
這條攻擊靠的是：公開模型名稱和用戶端控制的載入設定，在沒有可信檔案證據的情況下一路進到執行期。模型 SBOM（Software Bill of Materials，列出模型檔案、雜湊、模型檔案格式、分詞器、設定和載入程式等組成清單）與來源證明，應記錄已核准的模型內容、雜湊、來源、模型檔案格式、分詞器、載入程式版本，以及
trust_remote_code 這類設定。它只提供與檔案雜湊綁定的來源證據；AID-H-003.009 負責可執行風險掃描，是否拒絕載入則由審查與核准關卡負責。
AID-H-003.010
高
Deployed AI Software Vulnerability Remediation Lifecycle
先把已部署的 ChromaDB 版本與驗證前遠端程式碼執行漏洞公告逐一核對，再重建修正版、分階段推出，並獨立確認已沒有任何弱點 server digest 留在環境中。這比單次發布關卡更精確，因為它負責修補已在正式環境運作的軟體。
AID-I-001.002
高
MicroVM & Low-Level Sandboxing
如果系統真的需要評估新的第三方 embedding 模型，第一次載入不應該直接發生在長時間運作的向量資料庫程序裡。比較好的做法是放進 microVM（輕量虛擬機，用硬體虛擬化隔出更清楚的執行邊界）或低階 sandbox，裡面不要有正式環境 secrets，也不要掛主機共用檔案系統。這樣就算模型程式碼有問題，也比較不容易碰到 ChromaDB 主機、已儲存的向量資料、掛載憑證或內部服務。
AID-I-001.004
高
Sandbox Network Egress Restrictions
HiddenLayer 的攻擊路徑會讓攻擊者的程式碼在 ChromaDB 伺服器裡跑起來。模型載入 sandbox 和向量資料庫工作負載都應該採用預設禁止對外連線的政策，只開必要目的地。這樣即使惡意模型程式碼真的開始跑，也比較難建立反向 shell、把憑證送出去，或再下載下一段惡意程式。
AID-D-004.008
中
AI Runtime Code and Module Loading Integrity Monitoring
持續觀察 ChromaDB 與 embedding 模型執行期實際載入的可執行模組，並和經簽署的版本清單比對。在適用的 Linux 部署上，從檔案載入的可執行記憶體映射（file-backed executable mappings），可以揭露已進入程序但未經核准的模型載入器、原生程式庫或外掛。這僅適合作為事後偵測的補強，不能取代主要的模型載入前檢查與執行權限限制；目前的 Linux 實作也無法涵蓋匿名記憶體或只有 JIT 才會產生的程式碼。
身為資安防禦者，我們應該這麼做
- 盤點所有 ChromaDB 部署，特別是對網路開放的 Python FastAPI 伺服器。至少記錄版本、部署路徑、對外介面、驗證層，以及這台伺服器能不能連到公開 Hugging Face。
- 優先改用 Rust 版部署路徑，或在有修補版時升級到已修補版本。如果仍然需要使用 Python FastAPI 伺服器，就把 ChromaDB 連接埠限制在可信用戶端才連得到的網路範圍內，並放在網路政策、服務驗證、API 閘道或私有服務路徑後面。
- 如果團隊暫時不能升級，只能先改自己維護的 ChromaDB fork，或在外面加一層暫時防護，就要把驗證移到最前面：在載入 collection 設定、建立 embedding 函式、下載模型之前，就先確認呼叫者有權限。被拒絕的請求，不應該在被拒絕前先建立或執行任何 embedding 模型。
- 正式環境的建立 collection 流程，預設擋下由請求控制的模型名稱、
kwargs和trust_remote_code。如果使用者真的需要可設定的 embedding 模型，就提供已核准的內部模型允許清單，而不是讓使用者直接填公開模型參照。 - 把核准模型放進內部模型儲存庫或鏡像站，並加上掃描、簽章、內容雜湊釘選和載入政策檢查。新的 embedding 模型應該像新的可執行相依套件一樣被審查，而不是當成普通設定值。
- 把第一次模型載入放進短生命週期沙箱（sandbox，隔離執行環境），裡面不要有正式環境 secrets、不要掛使用者平常的個人目錄，並預設禁止對外連線。
結論
ChromaToast 最值得記住的地方，是它把一件看似普通的設定動作，變成了程式碼執行。這個請求不是直接叫伺服器執行命令，而是要求伺服器用指定的 embedding 模型建立 collection；但只要那個模型參照能拉下遠端程式碼，而且伺服器在驗證前就先載入它，collection API 就會變成驗證前遠端程式碼執行入口。AIDEFEND 在這裡對應到的防線很清楚：API 要先驗證，模型來源要能證明，危險載入設定要擋下，正式模型要走安全發布流程，第一次執行要隔離，對外連線要收斂。