AIDEFEND in Action AIA-0100 實際事件 發布於 AIA: 2026年10月23日

LiteLLM 1.107.0：外洩未撤銷的 Agent 主金鑰，導致官方簽章發布流程遭入侵

10 月 21 日，LiteLLM（用來呼叫各家模型服務的 Python 函式庫與閘道）透過正常建置與簽章流程，發布了夾帶竊密程式的 1.107.0 惡意版本。LiteLLM 官方於 10 月 23 日公布的調查報告確認，攻擊入口是先前公開外洩且未被撤銷的實驗性 Agent Platform 主金鑰（master key）；攻擊者利用該金鑰取得 GitHub 組織擁有者的 CLI OAuth token，再透過兩次拋棄式 CI 流程分別竊取兩位專案維護者的 token。本案凸顯出：軟體使用者端必須嚴格鎖定並僅接受預先核准的確切套件雜湊值，且軟體提供端必須在憑證簽發處徹底撤銷各代金鑰，才能守住有效官方簽章無法保證安全的防禦邊界。

Supply Chain CompromiseCredential ExposurePackage VettingAI Infrastructure
5 項對應的 AIDEFEND 防禦手法
來源: The attack chain behind the v1.107.0 LiteLLM release 
作者: Oliver Jensen and Mateo Wang
原文發布: 2026年10月23日

威脅分析

  • 未撤銷的主金鑰導致組織擁有者 token 外洩： 實驗性 Agent Platform 的主金鑰早於 5 月 27 日因公開 commit 外洩；雖然團隊隨後以強制推送覆寫歷史紀錄，但金鑰未在後端撤銷。攻擊者於 10 月 10 日利用此金鑰讀取 agent 設定，取得具備組織擁有者權限且已通過多因素驗證（MFA）的 CLI OAuth token。
  • 濫用特權 CI 工作流程竊取維護者憑證： 攻擊者利用擁有者身分觸發兩次臨時 CI 流程，匯出兩位專案維護者的 token。10 月 21 日，攻擊者修改發布工作流程以拉取名稱相似的惡意儲存庫；在分支保護規則攔截推送後，直接運用擁有者權限覆寫該保護設定並完成審查。
  • 官方簽章管線發布啟動即觸發的竊密程式： 官方正規 CI/CD 管線替惡意 wheel 與容器映像檔完成簽章與發布。受害端只要啟動 Python 直譯器，cook.pth 就會在任何應用程式執行 import 之前自動載入 cook.py，搜集本機機敏憑證並加密透過 HTTP 對外傳出。
  • 事件處理時序與實證邊界： 惡意套件於 10 月 21 日發布後，在不到三小時內即由 PyPI 凍結並自容器登錄庫下架。公開的下載統計資料僅反映套件散布規模，不代表實際遭入侵的主機數量；本起 10 月的供應鏈事件與該專案 3 月份的 1.82.x 惡意版本完全獨立。

適用的 5 項 AIDEFEND 防禦手法

AID-E-001.001
Root & Long-Lived Credential Object Eviction
極高
一旦發現公開外洩事件，應立即向 Agent Platform 的權威驗證端全面撤銷該版本的主金鑰，並使用舊金鑰實際呼叫管理 API，確認請求已被伺服器拒絕並清查所有已取用此憑證的服務端點。單純從 Git 歷史中移除 commit 不會讓金鑰自動失效。指引 G001 需要針對 Agent Platform 實作專屬的撤銷與狀態讀回機制，其 AWS access key 範例並非 LiteLLM 的內建功能；若在事發當下完成驗證撤銷，便能及時阻斷攻擊者於 10 月 10 日發起的初始入侵。
AID-H-003.001
Software Dependency & Package Security
極高
軟體使用者端的建置與部署流程，應嚴格限制僅能從受控的內部鏡像庫安裝經獨立審查核准的確切版本與內容雜湊值，涵蓋容器 digest 與完整的依賴項清單。先前已核准的已知安全成品應維持版本鎖定，直到另行審查確認新內容；絕不能單憑官方發布者的數位簽章，便自動接受 1.107.0 或動態的 latest 標籤。同時必須全面封鎖隱含升級與繞過內部鏡像直接從公有登錄庫安裝的管道，才能有效阻斷此散布步驟。
AID-E-001.002
Issued Token, Authentication Session & Lease Revocation
高
在確認安全事件後，應立即透過 GitHub 撤銷所有遭竊取的 CLI OAuth token，並逐一以各遭入侵身分及受影響儲存庫發起 API 呼叫測試，確認舊 token 已被拒絕。Agent Platform 的根認證金鑰亦須分開撤銷；單純替換根金鑰、重設密碼或啟用多因素驗證，並無法使已經匯出的 post-MFA OAuth token 失效。此措施屬於事件圍堵階段的應變作為，無法逆向阻止先前已發布的惡意版本。
AID-I-001.002
MicroVM & Low-Level Sandboxing
高
在 Python 直譯器啟動之前，便應將不可信的第三方 AI 相依套件置於獨立且具備強制約束力的受管虛擬機（MicroVM）或作業系統沙箱中執行，嚴禁將開發者家目錄、瀏覽器資料庫、雲端憑證或正式環境憑證資料庫掛載進去。由於 .pth 檔案會在一般應用程式執行 import 前就搶先載入，事後才建立隔離已失去防護時機。沙箱隔離能有效限縮惡意程式可存取的本機資產，但無法使惡意套件本身變安全，也無法保護刻意傳入同一執行環境中的任務憑證。
AID-H-003.005
Infrastructure as Code (IaC) Security Scanning for AI Systems
中
在程式碼發布前，應全面掃描目前檔案、儲存庫完整歷史紀錄與待提交的變更內容，涵蓋 opencode.json 等 Agent 設定檔格式。一旦確認外洩，必須立即觸發簽發端的金鑰撤銷程序，而非僅僅覆寫 Git commit 歷史。規則比對涵蓋率、私有儲存庫與遭強制推送移除的 commit 皆須獨立進行清查；自動化掃描能協助及早發現外洩，但其本身無法代替人工使外洩憑證失效。

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

  • 從完全乾淨的獨立管理端點，清查內部環境是否曾安裝或執行特定受影響的 LiteLLM 1.107.0 wheel 雜湊值或容器 digest。凡確認受影響的環境應一律視為已遭入侵；切勿直接在受感染環境中啟動 Python 直譯器進行清理，因為啟動過程本身就會觸發 .pth 載入竊密程式。
  • 在完整保存數位鑑識證據後，以獨立驗證乾淨的映像檔重新建置環境；並立即向各憑證簽發端全面撤銷可能暴露的雲端平台（如 AWS、GCP）、AI 模型提供商（如 OpenAI、Anthropic）、瀏覽器儲存區、開發者工具及資料庫的各類存取憑證。已簽發的 OAuth token 與底層根認證金鑰必須分別撤銷，並使用舊值實際發起請求，確認已被簽發端徹底拒絕。
  • 在內部建立受控的內部套件鏡像庫（package mirror），嚴格固定經獨立審查核准的套件版本、依賴項雜湊值（hashes）與容器 digest，全面封鎖對外部公有登錄庫的直接存取與自動升級機制。官方有效的數位簽章僅能證明來源管道合法，絕不代表該組二進位內容已通過安全審查。
  • 全面檢視並移除 AI Agent 設定檔中的真人組織擁有者憑證，改採嚴格限縮儲存庫與操作權限的專用服務帳號（service account），並嚴禁 Agent 管理 API 直接回傳可被重複使用的憑證明文。
  • 發布流程的原始碼來源變更與緊急權限覆寫機制，應建立在被入侵管理員邊界之外的獨立授權實體之上；同時將 CI/CD 稽核日誌留存於 GitHub 組織外部的獨立儲存區。資安調查範圍除最終發布流程外，亦須全面清查遭竊身分在 CI 執行期間存取的所有 secrets。

結論

AIDEFEND  針對此事件指出了多道關鍵防禦邊界：外洩根金鑰的徹底撤銷、已簽發 token 的即時圍堵、第三方套件內容的確切驗證，以及執行環境與機敏憑證的底層隔離。本案最深刻的教訓在於：即使是具備官方合法簽章的軟體版本，仍可能夾帶惡意程式碼。軟體使用者端必須建立獨立於簽章之外的內容核准邊界；而軟體提供端則必須在金鑰簽發處徹底使每代外洩憑證失效，絕不能以為修改或抹除 Git commit 歷史便能解除風險。

最後更新: