LiteLLM供應鏈受襲：多模型團隊須重建環境及輪換金鑰

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-22

LiteLLM的官方發布流程近日遭入侵，受污染的Python套件及Docker映像檔曾被派發。對使用LiteLLM串接多家模型、以Docker部署服務，或把雲端與AI服務金鑰置於同一Python環境的團隊而言，風險不只限於單一套件失效，而是憑證可能已被讀取及外傳。

最重要的限制是：已安裝或執行受影響版本的團隊，不應直接在原有環境執行更新或重新安裝指令。iThome報道指出，LiteLLM建議從乾淨環境重新安裝，並輪換可能外洩的服務金鑰及登入憑證；官方亦暫時建議使用1.106.2版。

受影響範圍不只PyPI套件

iThome報道指出，受污染的是PyPI上的LiteLLM 1.107.0版，以及Docker Hub和GitHub容器映像倉庫中的多個映像選項。即使用戶沒有明確指定該版本，當時拉取標示為最新版的映像檔，亦有機會取得含惡意程式的版本；從私人倉庫取得企業版的客戶則不受影響。

事件的危險之處在於，SafeDep的分析顯示，惡意套件會把檔案加入Python執行環境，使同一環境內其他Python程式日後啟動時亦可能觸發竊密行為，即使程式本身並未使用LiteLLM。被鎖定的資料包括雲端服務登入憑證、AI服務金鑰、遠端登入私密金鑰，以及LiteLLM資料庫中的金鑰，之後會傳送至外部server。

官方建置管道成為分發點

iThome指出，攻擊者取得3名工程師的GitHub憑證，並利用其中具管理權限的帳戶移除程式碼修改限制，再把發布系統的原始碼來源改至名稱近似官方專案的仿冒倉庫。惡意內容因而經官方建置及上架流程流出；GitHub公開的1.107.0原始碼則未見惡意檔案。

這反映開源依賴的檢查不能只看公開原始碼或版本號。對自動拉取latest映像、在CI/CD內自動更新依賴，或共用Python virtual environment的團隊來說，發布鏈、映像標籤與運行環境同樣是供應鏈防線的一部分。這是從事件資料作出的風險分析，並非已確認有其他專案受同類手法影響。

團隊現階段可如何處置

在不於受污染環境執行任何套件指令的前提下，受影響團隊可優先處理以下事項：

盤點是否曾安裝或執行LiteLLM 1.107.0，並追查部署流程有否在相關時段拉取標示為最新版的容器映像。
將疑受影響的執行環境視作不可信，另建乾淨環境重裝經確認的版本，而非原地更新。
輪換該環境可存取的模型API金鑰、雲端憑證、SSH私密金鑰及其他登入憑證，並檢視金鑰使用紀錄有否異常。
檢查共用Python環境內的其他服務，因iThome引述的分析指竊密行為可由其他Python程式啟動時觸發。

至於工程師GitHub憑證如何外洩，LiteLLM發現Claude Code在特定情況下可能把GitHub登入憑證放入回覆內容，相關資料或曾記錄在其內部系統；但駭客是否藉此取得憑證，以及最初如何進入內部系統，仍在調查。因此，現階段不宜把AI coding工具直接定性為本次入侵原因。不過，團隊應重新檢視AI coding工具的輸出、日誌與內部知識系統，避免把存取權杖、私密金鑰或完整環境變數納入可被長期保存或廣泛檢索的內容。

接下來值得觀察的是LiteLLM對發布流程、管理帳戶及映像標籤的補強措施，以及使用多模型API的團隊會否把「latest」映像和共用執行環境列為更嚴格的變更管理範圍。