LiteLLM 供應鏈攻擊：2026年惡意程式碼注入事件完整分析與緊急應對指南

重點摘要

• 受影響版本：PyPI 上的 LiteLLM 1.82.7 和 1.82.8 版本被注入了惡意程式碼，現已下架。最後一個安全版本是 1.82.6。
• 攻擊機制：版本 1.82.7 將惡意載荷隱藏在 proxy_server.py 中；版本 1.82.8 則額外使用了一個 Python .pth 檔案 (litellm_init.pth)，該檔案會在 任何 Python 程序啟動時 自動執行，無需導入 LiteLLM。
• 竊取的資料：SSH 私鑰、AWS/GCP/Azure 憑證、Kubernetes 配置與 Secrets、.env 檔案、加密貨幣錢包、資料庫密碼、Git 憑證、Shell 歷史記錄等。
• 三段式攻擊：憑證竊取 → Kubernetes 橫向移動（創建特權 Pod）→ 透過偽裝的 systemd 服務 (sysmon.service) 維持持續性存取。
• 根本原因：攻擊者先前已入侵 Trivy 安全掃描器，獲得 LiteLLM 維護者的 PyPI 發布權限，並繞過正常的 CI/CD 流程直接上傳惡意套件包。
• 暴露窗口：惡意版本上線僅 1–2 小時，但因一個 fork 炸彈缺陷導致開發人員電腦崩潰，從而使其被發現。
• 影響範圍：LiteLLM 每月下載量超過 9500 萬次，並被許多 AI 代理系統、MCP 伺服器和 LLM 編排專案間接依賴。

時間線與攻擊詳情

2026年3月24日，熱門函式庫 LiteLLM —— 一個統一涵蓋超過 100 個 LLM 提供者的 API 封裝包 —— 在 PyPI 上突然出現了異常版本。威脅攻擊團隊 TeamPCP（先前曾對 Trivy 和 KICS 發動攻擊）利用被入侵的維護者憑證或 PyPI 令牌發布了兩個惡意版本。

版本 1.82.7：

• 惡意載荷隱藏在 litellm/proxy/proxy_server.py 中。
• 僅在導入模組或執行 litellm --proxy 時觸發。
• 載荷為雙重 base64 編碼的 Python 腳本。

版本 1.82.8（更具破壞性）：

• 額外植入 litellm_init.pth 檔案。
• Python 的 site 模組會在解譯器啟動時自動執行 .pth 檔案，實現 零交互觸發。
• 這意味著即使專案從未明確使用 LiteLLM，只要該套件存在於其環境中，就可能被感染。

該惡意軟體使用混合加密（AES-256-CBC + RSA-4096）將資料外洩至偽造的域名 models.litellm.cloud。

惡意負載技術分析

分析顯示該惡意負載分為三個獨立階段運作：

1. 憑證竊取階段：

   • 遞迴掃描常見路徑：~/.ssh/、~/.aws/、~/.kube/、~/.azure/、.env 檔案、Kubernetes 配置、Git 憑證等。
   • 提取環境變數、記憶體中的密鑰、雲端元資料端點（IMDS）以及多種加密貨幣錢包檔案。

2. 橫向移動階段（Kubernetes 環境）：

   • 使用 ServiceAccount 權杖讀取叢集範圍的 Secrets。
   • 在每個節點的 kube-system 命名空間中創建特權 alpine:latest Pod，並掛載主機檔案系統。

3. 持久化階段：

   • 部署偽裝成「系統遙測服務」的後門（sysmon.py + systemd 使用者服務）。
   • 定期從 checkmarx.zone 等域名拉取額外負載。

發現觸發條件：惡意程式碼的 subprocess.Popen 呼叫在 .pth 機制下創建了指數級的分支炸彈（fork bomb），迅速耗盡記憶體並導致機器崩潰——這一缺陷無意中暴露了攻擊行為。

為何 LiteLLM 成為高價值目標

LiteLLM 作為支援 100 多個 LLM 提供者的通用代理，被廣泛應用於生產環境的 AI 代理系統、MCP 伺服器及多模型路由中。開發者通常只需一行程式碼即可替換底層呼叫，這意味著敏感的 API 金鑰經常共存於同一環境中。

此次供應鏈攻擊鏈條清晰：Trivy 遭入侵 → LiteLLM CI/CD 依賴 Trivy → 發布權限洩漏 → 直接惡意上傳至 PyPI。這凸顯了在當今開源生態系統中「信任但仍需驗證」的極端重要性。

緊急行動：檢測與清理步驟

步驟 1：檢查已安裝版本

pip show litellm
pip list | grep litellm

若發現版本為 1.82.7 或 1.82.8，請立即移除：

pip uninstall litellm -y
pip install litellm==1.82.6 --force-reinstall

步驟 2：清理 Python 快取與 site-packages

• 刪除 site-packages/litellm* 目錄及任何 .pth 檔案。
• 清除 pip 快取：pip cache purge

步驟 3：輪換所有憑證

• 立即 輪換 SSH 金鑰、所有雲端存取金鑰（AWS IAM、GCP 服務帳戶、Azure AD）、Kubernetes 權杖、資料庫密碼及 CI/CD 密鑰。
• 檢閱雲端稽核日誌（CloudTrail、Audit Log、Activity Log）以查找可疑存取記錄。

步驟 4：Kubernetes 環境額外檢查

• 掃描 kube-system 命名空間以尋找可疑 Pod。
• 檢查節點上是否存在 ~/.config/sysmon/ 目錄及異常的 systemd 服務。
• 重建受影響節點（強烈建議）。

步驟 5：掃描依賴專案

• 稽核所有 requirements.txt、pyproject.toml 及 Docker 映像檔；將 LiteLLM 固定為 ==1.82.6。
• 使用 pip-audit 或 safety 等工具掃描環境。

進階緩解措施與最佳實踐

• 固定版本：在生產環境中始終使用Poetry、Pipenv或類似工具將LiteLLM鎖定為==1.82.6（或更新的安全版本）。
• 供應鏈掃描：整合Dependabot、Snyk、JFrog Xray或Endor Labs以監控PyPI套件的變更。
• 最小權限原則：避免混合開發與生產環境的憑證；使用專用的密碼管理工具（如AWS Secrets Manager、HashiCorp Vault）。
• 隔離安裝：針對高安全性環境，應從驗證過的GitHub原始碼建構並檢查雜湊值。
• 監控機制：部署終端偵測與回應（EDR）解決方案，監控.pth檔案的建立、異常的fork行為以及對可疑網域的連出連線。

特殊案例：

• 透過CLI腳本（如install.sh）間接安裝同樣會使系統暴露於風險。
• 基於受污染基礎映像的Docker映像必須重新建構。
• 虛擬環境（venv）雖然隔離，但全域Python安裝仍可能影響系統程序。

結論

LiteLLM供應鏈攻擊清楚地提醒我們：開源生態系統的便利性伴隨著嚴重的安全風險。透過先入侵安全掃描工具，攻擊者實現了精準的下游影響。

立即行動：檢查所有Python環境中的LiteLLM版本，降級至1.82.6，並立即輪換所有可能暴露的憑證。建立嚴格的相依性審查流程以防止未來事件。

請透過官方LiteLLM GitHub與PyPI公告持續更新。2026年及往後，定期稽核相依性將成為每位AI開發者必備的核心能力。

保持警覺，保護供應鏈——從今天開始固定版本做起。