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

2026年3月，LiteLLM 版本 1.82.7 和 1.82.8 透過 PyPI 遭植入惡意程式碼。本深度指南解析攻擊手法、竊取資料內容，並提供檢查、清除及立即更換憑證的具體步驟。

Canonical URL: https://a2a-mcp.org/blog/litellm-supply-chain-attack-2026-zh-TW

Language: zh-TW

Published: 2026-03-25

Updated: 2026-03-25

## 重點摘要

- **受影響版本**：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：檢查已安裝版本**
```bash
pip show litellm
pip list | grep litellm
```

若發現版本為 1.82.7 或 1.82.8，請立即移除：
```bash
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開發者必備的核心能力。

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