LiteLLM 1.107.0 遭入侵事件的應變指南

發生了甚麼事

LiteLLM 1.107.0 遭入侵事件於 2026 年 10 月 21 日開始，當時遭入侵的 litellm==1.107.0 被發布至 PyPI 及 LiteLLM 的容器映像登錄庫。LiteLLM 的事故公告指出，較早版本安全，受影響版本已下架，使用私有企業版的客戶則未受影響。其攻擊鏈公告指出，受影響構件約有兩小時可供下載：PyPI 發布在 13:23 UTC 前已凍結，Docker 映像則在 14:20 UTC 前移除。

兩小時已經足夠。LiteLLM 常被部署為應用程式與模型供應商之間的閘道，而Microsoft 的分析指出，在這個位置上，它可能持有模型供應商的 API 金鑰、資料庫連線字串、工作負載身分及路由設定。同一套件亦會出現在開發人員的手提電腦和建置代理程式上。如果你運行 AI 閘道，應將此事視為下一宗事件的範本，不論涉及哪個套件。

為甚麼「我從未匯入它」並不能構成抗辯

惡意 wheel 套件在其 purelib 資料目錄下附有 cook.pth、cook.py 和 sitecustomize.py。Microsoft 指出，安裝時，這些檔案會放入環境的程式庫目錄，而非 litellm 套件資料夾。

這個位置之所以重要，是因為 Python 的啟動方式。site 模組文件説明，.pth 檔案中以 import 開頭的行會在直譯器初始化期間執行，而 Python 隨後會嘗試匯入 sitecustomize 模組。Microsoft 發現，cook.pth 只包含一行 import cook，會在守護執行緒中啟動憑證收集程式。sitecustomize.py 則帶有另一個面向 Unix 的載入程式，設計用途是擷取並執行額外的 Python 程式碼；Microsoft 表示，未能確認有透過此路徑遠端擷取程式碼。

分析明確指出其後果：應用程式毋須匯入 LiteLLM，惡意程式碼便能執行。在受影響的環境中啟動 Python，可能已足以觸發程式碼。在一個 Windows 範例中，透過 Python 安裝無關依賴項的日常操作便觸發了收集程式。而且，由於啟動檔案位於套件資料夾之外，即使刪除 litellm，這些檔案仍可能留存。

收集程式的目標

Microsoft 列出還原出的程式碼旨在讀取的目標：AI 助理、IDE 和 MCP 設定；Git 憑證和套件管理程式設定；AWS、Azure CLI 和 Google Cloud 憑證快取；Kubernetes 服務帳戶檔案和 Docker 設定；瀏覽器憑證資料和 Shell 歷史記錄；程序環境，包括在 Linux 上可透過 procfs 讀取的其他程序環境；SSH、GPG 和 TLS 相關資料。在代理伺服器主機上，另一個模組可使用 Prisma，從兩個 LiteLLM 資料庫資料表讀取指定欄位。Microsoft 特別指出，程式碼中出現某個目標，並不代表已成功存取該目標。

收集的資料會使用每次執行時產生的 AES 金鑰加密，再以內嵌的 RSA 金鑰加密該 AES 金鑰，然後傳送至 hxxp://www[.]litellm[.]dev/healthcheck。請留意這個仿冒網域。

應對措施，依序進行

Microsoft 的指引與 LiteLLM 的公告對應對措施的方向一致。以下整理成一份應變手冊。

找出所有副本。在已安裝的環境、pip 和 uv 快取、內部鏡像、鎖定檔、建置輸出及容器映像中，搜尋 1.107.0。LiteLLM 的事故公告列出受影響的映像標籤，包括 latest 等浮動標籤，以及映像摘要。標籤可以變更，因此「我們已固定至 latest」並不足夠；你需要查明實際拉取的是哪個映像摘要，以及何時拉取。
不要執行 Python。Microsoft 明確指出，在蒐集證據期間，不要執行 python、pip，或任何會啟動受影響直譯器的操作。每次啟動都可能重新執行載荷。在安全情況下，隔離主機並停止 Python 程序，防止自動化程序重新啟動它們，然後從已知乾淨的電腦使用可信工具檢查檔案系統。
在判定遭入侵之前，先比對各項跡象。綜合檔案雜湊值、Python 程序的父子關係、.pc_e_ 臨時暫存目錄、連至收集器網域的連線，以及其後涉事身分的使用情況。單憑套件存在，不能判定已遭入侵。
重新建置，不要清理。使用經驗證的成品重新建置環境和映像。確認 cook.pth、cook.py 和 sitecustomize.py 已從程式庫路徑中移除。Microsoft 指出，移除套件或發行標籤並不足以完成復原。
從乾淨的電腦輪換所有憑證。輪換受影響身分可存取的一切：模型供應商金鑰、雲端及工作負載憑證、CI/CD 機密資料、原始碼控制及套件登錄庫 token、SSH 和 GPG 金鑰、AI 編碼工具 token，以及代理主機上已儲存的供應商憑證和 DATABASE_URL。若從已遭入侵的工作站輪換，新密碼資料就會落入同一個收集器手中。同一週發生的 Railway 入侵事件也採用了同樣從乾淨電腦進行輪換的做法。也要撤銷工作階段；Microsoft 指向 Entra 緊急撤銷，因為輪換密碼不會立即使每個有效 token 失效。

本可縮小影響範圍的強化措施

使用固定雜湊值的鎖定檔。pip 的安全安裝指南介紹了雜湊檢查模式；在此模式下，每項依賴要求都必須附有雜湊值，若不匹配，安裝便會失敗。除非有人加入，否則鎖定檔中不會有 1.107.0 的固定雜湊值，因此未經審核的升級會遭拒安裝。

使用映像摘要，而非標籤。Microsoft 建議使用容器摘要，因為它們能識別不可變的內容。若部署參照 @sha256:，便不會在未察覺的情況下取得新的 latest。

設有審核關卡的內部鏡像站。只有經審核後才將套件加入鏡像站，並延遲接納剛推出的版本。這次的時間窗口約為兩小時。

控制對外連線。Microsoft 的指引指出，除非有需要，開發人員工作站、建置代理程式、測試系統、容器和 AI 閘道主機都不應有不受限制的 HTTP 對外連線，並附上 Azure 的對外流量設計指南連結。閘道主機需要連接模型供應商及其資料庫，但不需要連接一個只是假扮成供應商網域的任意網域。

盡可能不要將機密資料存放在閘道的程序環境中。收集器會讀取環境變數；在 Linux 上，甚至包括其他程序的環境變數。在使用時才從密碼庫提取、有效期較短的機密資料，對收集器而言，價值低於存放在 env 中的長期有效金鑰。

上游教訓：一個未撤銷的金鑰，一個未限制範圍的 token

LiteLLM 發佈的攻擊鏈文章格外坦率；文中提及的根本原因，是每個執行 Agent 的團隊都應檢查的問題。

2026年5月27日，一個提交至公開儲存庫的設定檔意外包含了 LiteLLM 內部 Agent Platform 部署的主金鑰。該提交其後遭強制推送覆蓋，而該金鑰已被確認需要撤銷。用 LiteLLM 的話來説，金鑰並未撤銷。

該平台讓自行託管的代理程式提交拉取請求，因此平台持有一個 GitHub 權杖。文章指出，該權杖並非服務帳戶所有，權限範圍也沒有收窄：它是組織擁有者的 GitHub CLI OAuth 權杖。10 月 10 日，攻擊者使用主密鑰呼叫平台的 API，API 隨即回傳該權杖。取得擁有者權限後，他們執行一次性的 CI 工作流程，將儲存庫機密傳送至外部端點，藉此取得另外兩名維護者的權杖。10 月 21 日，他們使用擁有者權杖，繞過發佈儲存庫的分支保護設定，並將其改指向外觀相似的 fork；接着使用一名維護者的權杖批准正式環境部署關卡，再用另一名維護者的權杖刪除執行記錄。LiteLLM 指出，該星期放寬了發佈批准規則，容許任何兩名工程師批准。

任何讓代理程式存取儲存庫的團隊，都應留意以下三項檢查：

已外洩的密鑰應撤銷，而不只是隱藏。強制推送歷史記錄無法撤回已公開的機密。
代理程式應有專屬且權限範圍受限的身分。代理程式平台絕不應持有人類擁有者的權杖。
只有受保護分支及經批准的工作流程才能存取 CI 機密，這樣新分支便無法執行會輸出這些機密的工作。相關文章：為甚麼 GitHub Actions 中的 persist-credentials 很重要，以及停止把正式環境密鑰交給 AI 代理程式。

常見問題

如果我的應用程式從未匯入 LiteLLM，是否仍受影響？

Microsoft 發現，攻擊載荷會由 .pth 和 sitecustomize.py 啟動檔執行，因此在受影響環境中啟動 Python，便可能足以觸發攻擊載荷。

解除安裝 litellm 1.107.0 就足夠嗎？

不夠。啟動檔位於套件資料夾之外，而 Microsoft 指出，移除套件或發佈標籤並不足以完成復原。請從已驗證的構件重新建置。

我應更換哪些機密？

更換受影響身分可存取的所有項目，包括模型供應商密鑰、雲端及 CI/CD 憑證、原始碼控制權杖、SSH 和 GPG 密鑰；在代理主機上，還包括已儲存的供應商憑證及 DATABASE_URL。請使用乾淨的電腦更換憑證，並撤銷工作階段。

惡意發佈版本可供使用了多久？

根據 LiteLLM 的攻擊鏈文章，約兩小時。PyPI 上的發佈版本於 13:23 UTC 凍結，Docker 映像則於 14:20 UTC 移除。

LiteLLM 表示會另外分享流程方面的改動。在此之前，攻擊鏈文章是目前最清晰的公開紀錄，説明瞭事件經過，值得全文細讀。

最初刊載於 yadui.dev，作者為 Abhinav Yadav。