LiteLLM 供應鏈攻擊解析：官方出貨與簽章，為何仍會送出惡意成品？（2026）

2026 年 10 月 21 日，LiteLLM 團隊在官方部落格發布了〈Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised〉。這起 LiteLLM 供應鏈攻擊的關鍵，是惡意內容經官方套件與容器發布渠道送出；下載位置可信，仍可能拿到遭污染的成品。對把多個模型金鑰集中交給 Gateway 的團隊，這是直接的憑證風險。

先把公告的受影響範圍攤開，再看獨立研究如何解釋惡意程式，最後回到部署者能做的驗收。本文於 2026 年 10 月 23 日查閱；原報告可見的最後更新標示為 10 月 21 日 20:30 UTC，不能把事件「已控制」理解成所有受害環境都已恢復。

LiteLLM 供應鏈攻擊：已下架，與已清乾淨是兩件事

Incident contained, investigation in progress

中文：事件已受控制，調查仍在進行。

LiteLLM 事件報告的狀態標示

維護者的核心訴求是：確認部署是否接觸惡意版本，並立即處理可被主機讀取的秘密。下表的時間全部是 2026 年 10 月 21 日 UTC；它描述發布端的暴露窗口，先前取得的快取、鏡像與部署仍需另外盤點。

渠道	公告列出的受影響成品	官方時間紀錄
PyPI	litellm==1.107.0 的七個 wheel	11:39:51 上架，至 13:23 前移除
Docker Hub	v1.107.0、latest、main-latest、main-stable	11:46:56 至 14:20 指向受影響 image index
GHCR	同名標籤及公告列出的映像變體	11:46:56 起；至 13:51 的驗證已顯示受影響標籤不可用

這些細節依維護者的版本清單與時間線整理。JFrog 的原始樣本分析另確認七個平台 wheel 帶有惡意檔案，並指出 Docker 映像也受影響。這比只重述「官方說出事」多了一層成品證據；但下載量、社群討論量與受害人數應分開，本文不估算受害總數。維護者另稱，從其私有 registry 取得 enterprise release的客戶未受這次發布污染影響；這項例外限定於該發布來源，不能僅憑企業客戶身分判斷。

原始碼標籤看起來正常，為何安裝包仍會出事？

The compromised artifacts were built from an attacker-controlled repository.

中文：遭入侵的發布成品，是從攻擊者控制的儲存庫建置而成。

LiteLLM 事件報告

把軟體發布想成一道出貨流程：儲存庫是設計稿，建置工作負責打包，wheel 或容器才是你收到的箱子。看過一份乾淨設計稿，尚未回答「這個箱子是不是照那份稿做出來」。兩者必須以實際建置來源、提交與產物識別連起來。

Endor Labs 的逐檔比對提供了具體證據：官方 v1.107.0 tag 與惡意建置來源不同；研究者看到的 source distribution 有額外打包設定，卻未包含 wheel 中的三個惡意檔案。因此，Git tag、來源壓縮檔與預先建好的 wheel，需要各自確認，不能只查其中一份就替其餘成品背書。

這也不是「以後全部自己編譯就結案」。自己編譯會把信任移到自己的建置機、工具與依賴；有價值的改善，是能指出實際使用的輸入與輸出，以及誰有權改變它們。

還沒 import LiteLLM，Python 啟動就可能碰到惡意掛鉤

Python 3.14 的 site 文件明確說明，一般啟動時會處理套件路徑中的 .pth；其中以 import 開頭的可執行行會執行，之後也會嘗試載入 sitecustomize。這是直譯器的初始化機制，並不以你的應用程式是否匯入某個業務套件為前提。

JFrog 在本次樣本中分析到 cook.pth、cook.py 與 sitecustomize.py，分別串起憑證蒐集與遠端程式載入。研究也區分平台差異：Windows 的該守護程序路徑會受 os.fork() 限制，但另一條蒐集路徑仍構成暴露。不能把一段後門流程跑不通，推成整個套件對該平台安全。

這改變了事故處理的第一步。平常看到壞套件，直覺是立刻啟動 pip 換版；在這次受影響環境，啟動所用的 Python 本身就可能再次觸發掛鉤。應由乾淨的管理環境接手，先隔離、保全證據，再清除或重建。本文不要求讀者下載或執行惡意樣本來「確認」。

為什麼 Gateway 失守，影響可能超過一把模型 API Key？

Gateway 的好處是集中路由、配額與供應商設定；同樣的集中，也讓它成為有價值的攻擊目標。部署者真正要問的是：這個執行身分能讀到哪些資料、連到哪些服務，而不是套件名稱裡寫了哪一家模型。

Endor Labs 的分析指出，樣本除了主機、雲端與開發工具憑證，還針對 LiteLLM 的憑證與模型設定資料表讀取。這證明惡意程式的蒐集目標與能力；某個受害部署實際外傳哪些秘密，仍需用它的權限、網路與事件證據重建，不能把目標清單直接當成每台機器已失竊的清單。

一個容易忽略的差別是：停掉舊容器，與撤銷已被複製走的憑證，各自需要完成。重建環境可以換掉程式；外部服務仍接受的舊金鑰，則要在供應商端撤銷或輪替。如何把秘密與 Agent 工作區分開，可搭配Agent 密鑰安全指南理解。

有簽章、有 Trusted Publishing，為什麼還擋不住？

PyPI 的安全模型文件把界線寫得很清楚：Trusted Publishing 以短效憑證降低長效發布 token 的管理風險，但它不宣告程式碼安全；被註冊為可信的 CI/CD 工作流，仍需受到保護。工作流本身的弱點，可能等價於發布憑證遭入侵。這次事件之前，JFrog 已記錄 LiteLLM 在 2026 年 3 月的另一次供應鏈入侵；維護者表示，後來曾加強發布流程。本文把兩次事故分開分析，不將攻擊者或最初入口連成同一條線。

LiteLLM 維護者在公告中描述，攻擊者取得多名開發者的 GitHub 憑證，繞過保護並改變工作流使用的來源，讓正式流程替污染成品完成發布。這段私有系統的入侵經過，本文保留為維護者調查說法；外部樣本能支持成品確實有問題，無法獨立還原所有內部授權動作。

同一份公告把 token 可能出現在回覆／日誌、內部部署可能遭入侵等情節接成一條線，也明說初始進入方式仍待確認。這裡不能直接改寫為「Claude Code 已被證實是本次攻擊根因」。若未來公布經過去識別化的日誌、時間線與修補細節，這條因果鏈才更容易被外界核對。

簽章回答的問題，取決於你驗證的是哪個身分、哪個產物與哪些宣告。若有權出貨的人與流程都被挪用，簽過名的箱子仍可能裝錯內容。這個案例要求更細的政策：發布權、改工作流的權限、來源儲存庫與審批權，應盡量避免落在同一條可被接管的信任鏈上。

AlphaLab 的判讀：真正要補的是三段可核對的連結

一、把「同名版本」連到真正收到的位元組

版本號方便溝通，仍需配合實際成品識別。Docker 的 digest 文件說明，tag 可改變指向，digest 則識別特定內容。保存已核准的 digest，能讓團隊比較「現在跑的」與「當時驗過的」是否一致；但若核准的就是惡意成品，固定 digest 只會穩定重現同一問題。

二、把「建置成功」連到允許的來源與權限

建置出一個可啟動映像，只表示工具完成工作。部署政策還要核對預期儲存庫、提交、工作流與產物雜湊，遇到來源改變就停下來。像這次報告所述的相似名稱儲存庫，應讓精確比對與權限政策處理，而不是靠值班者用肉眼看一眼拼字。

三、把「服務恢復」連到秘密與外部活動的處理

功能測試全過，只能證明它在測試範圍內能用。事故結案還需要另一張清單：可讀秘密已盤點、舊憑證已撤銷、乾淨環境已部署、外部使用紀錄已查核。這些成果應各有證據，不能互相代簽。

我同意這次事件值得立即盤點正式部署，也同意只看原始碼會漏掉成品層的風險。我存疑的是把還在調查的初始入口寫成定論，或用一次入侵推成所有 Gateway／所有簽章都失效。改進的價值在可驗收的控制；可先從Agent Harness 的工具與權限邊界建立全圖，再用AI Evals 的明確判準區分功能驗收與安全驗收。

LiteLLM 供應鏈攻擊後，部署者今天先做什麼？

先用部署、建置與 registry 紀錄盤點 1.107.0、相關 digest、下載快取及間接依賴；不要只看今天設定檔已換成哪一版。疑似受影響環境先隔離，由乾淨環境接手調查與憑證管理；避免為了盤點先啟動受影響的 Python 或 pip。

依官方處理段落，重建環境並盤點可觸及的模型供應商金鑰、Proxy master／virtual keys、資料庫與雲端身分。使用乾淨裝置處理撤銷，並查看異常 API、雲端及發布活動；清理順序與證據保存可交由負責事故應變的人執行。找不到單一標記檔，不能當成乾淨證明。

沒有暴露證據的團隊，則先補一份「核准來源→核准成品→實際部署」紀錄，加上最小權限與撤銷演練。既有的三台本機 AI 與 Gateway 教學可幫你定位元件；繼續接系統之前，把Harness 的停止條件與驗收也放入部署流程。先讓每一把鑰匙都有可追的去向。