LiteLLM 1.107.0 遭入侵事件的教訓：在程式碼前執行的 .pth 檔案

在你的程式碼執行前運作的 .pth 檔案：LiteLLM 1.107.0 遭入侵事件的教訓

LiteLLM Python 套件的 1.107.0 版本在發佈時已被植入憑證竊取程式和後門。該套件已在 PyPI 遭隔離，惡意 Docker 映像檔亦已移除。這宗事件值得仔細研究的地方，在於惡意程式的傳遞機制，而不是惡意程式清單。路徑設定檔會在任何應用程式匯入程式碼前執行 Python，因此，即使操作人員從未呼叫 LiteLLM 函式，也可能遭到入侵。

事件經過

LiteLLM 的安全總監表示，惡意操作是透過三名工程師的 GitHub 帳戶進行，顯然是利用被盜的 GitHub CLI OAuth 權杖。其中一個帳戶觸發了 project-releaser 執行作業，另一個帳戶則予以批准。攻擊涉及的所有權杖均已撤銷。該組織採取臨時措施，從其 GitHub 組織中移除除一名未受影響用戶外的所有用戶，並更新公開登錄庫，移除指向其 GitHub 組織的受信任連結，防止有人再透過這條途徑發佈惡意套件。
該公司亦表示，尚未查明權杖是如何被取得，因此無法確認對那些 GitHub 帳戶的存取權已經終止。這句話提醒你必須自行核實。

受影響的套件檔案清單

受影響的檔案範圍具體。報道指出，涉及八個 wheel 檔案及一個原始碼封存檔：

litellm-1.107.0-cp310-abi3-macosx_10_12_x86_64.whl
litellm-1.107.0-cp310-abi3-macosx_11_0_arm64.whl
litellm-1.107.0-cp310-abi3-manylinux_2_28_aarch64.whl
litellm-1.107.0-cp310-abi3-manylinux_2_28_x86_64.whl
litellm-1.107.0-cp310-abi3-musllinux_1_2_aarch64.whl
litellm-1.107.0-cp310-abi3-musllinux_1_2_x86_64.whl
litellm-1.107.0-cp310-abi3-win_amd64.whl
litellm-1.107.0.tar.gz（不含任何載荷檔案，但包含遭篡改的 pyproject.toml）原始碼封存檔列入清單是有原因的。從原始碼發佈檔安裝時，可能會在自己的電腦上重新產生 wheel，這表示把 sdist 當作安全後備方案的建置流程，在這宗事件中並不安全。

兩種有效期不同的載荷

第一個載荷自行命名為 privcollect，是一種憑證竊取程式。它會收集雲端權杖、開發者帳戶及私密金鑰、AI 工具的憑證 JSON 檔案、Chromium 和 Firefox 的瀏覽器資料，以及環境變數。它亦會專門針對 LiteLLM 部署，目標是代理伺服器儲存的憑證和模型設定。收集到的資料會封裝成 GZIP 壓縮的 TAR 封存檔，再透過 HTTP POST 傳送至 litellm[.]dev/healthcheck。
第二個載荷會分叉出一個背景常駐程序，每小時查看一次 GitHub 上的秘密投遞點，並執行攻擊者提供的任何 Python 程式碼。據描述，該機制會讀取儲存庫中名為 domain.txt 的文字檔，並向該網域上的某一路徑發出 HTTP GET 請求。報道刊出時，該儲存庫回應 404；但只要有人重新建立秘密投遞點，它便會再次運作。
第一個載荷只會竊取一次資料。第二個則會建立一個持續存在的立足點，即使更改任何單一版本鎖定也無法將其清除。

為甚麼 .pth 檔案比載荷更值得關注

惡意軟件在 LiteLLM 匯入前由 Python 啟動。這是透過一個名為 cook.pth 的路徑設定檔實現，檔案只包含一行 import cook，會在直譯器啟動時觸發憑證收集程式。
直譯器初始化期間，site 模組會處理路徑設定檔，這正是它們成為隱蔽投遞途徑的原因。.pth 檔案不需要由你的程式匯入，不需要在應用程式中加入掛鈎，也不在乎套件是否實際被使用。任何使用該環境的 Python 程序，包括只有一行的指令碼或排程工作，都會執行這個酬載。
這種手法並非首次出現在這個套件中。相關報道指出，2026 年 3 月與 TeamPCP 供應鏈攻擊活動有關的 LiteLLM 事件中，也曾觀察到相同行為。相同機制再次出現，指出了調查方向：檢查建置代理程式、筆記本及容器映像中 site-packages 目錄內的 .pth 檔案。

按次序檢查事項

確認 litellm==1.107.0 是否曾安裝在任何地方，包括基礎映像、CI 執行器及開發人員的手提電腦。檢查你持有的任何 LiteLLM wheel 的雜湊值，不要只相信鎖定檔中的版本字串。
列出所有能存取的 site-packages 目錄中的 .pth 檔案。不屬於已知套件的異常項目，值得逐行檢查。.pth 檔案中，以 import 開頭的行會執行程式碼；一般項目則只是路徑。
如果曾安裝 1.107.0，應視該環境可存取的所有憑證均已外洩。報道所述的收集範圍涵蓋雲端權杖、開發人員帳戶、私密金鑰、AI 工具憑證 JSON 及瀏覽器資料，範圍比 LiteLLM 設定本身更廣。
在乾淨的電腦上撤銷並更換憑證。在可能仍執行該常駐程式的主機上查看資料竊取程式的目標清單，並非在乾淨環境中操作。
如報道所建議，以摘要值鎖定至 1.106.2，而非依據版本字串。

輪換金鑰也無法解決的問題

尚未審核的問題在上游。三個 GitHub 帳戶透過專案本身的自動化流程發布了一個版本，但取得這些帳戶存取權的途徑仍不明。輪換已暴露的憑證可處理你這一端的問題，但無法告訴你所依賴的其他套件，其發布流程是否也有同樣的雙人審批弱點，令這個版本得以發布。
報道未能確定隔離前有多少下載者安裝了 1.107.0，也沒有説明這個惡意版本提供下載的時間有多長。這兩項資訊缺口都不妨礙採取行動，也都意味著「我們是否受影響」的答案必須從你自己的套件紀錄中查找，而非依賴事件時間線。

參考資料

The Hacker News, "LiteLLM Compromised in Supply Chain Attack Delivering Credential Stealer and Backdoor", 2026年10月21日：https://thehackernews.com/2026/10/litellm-compromised-in-supply-chain.html
SafeDep 對 PyPI 事件的分析：https://safedep.io/litellm-pypi-compromise-credential-stealer-backdoor/
Socket 對事件的公告：https://socket.dev/blog/litellm-compromise
StepSecurity 對植入後門的 wheel 的分析：https://www.stepsecurity.io/blog/litellm-1-107-0-compromised-pypi-backdoored-wheels-credential-stealer
Upwind 關於惡意程式碼的報告：https://www.upwind.io/feed/litellm-1-107-0-supply-chain-attack-malicious-code-found-in-pypi-package
LiteLLM 事故的 issue 討論串：https://github.com/BerriAI/litellm/issues/47826
litellm 的 PyPI 發佈歷程：https://pypi.org/project/litellm/#history