月下載近億次 AI 套件 LiteLLM 爆供應鏈攻擊，加密錢包、SSH 金鑰全面淪陷（含緊急修復步驟）

全球單月下載量破 9700 萬次的 AI 開源套件 LiteLLM，PyPI 兩個版本遭駭客組織 TeamPCP 植入惡意程式碼，可竊取加密錢包、雲端憑證與 SSH 金鑰；受影響版本已於 3 月 24 日下架，但曾安裝者必須立即輪換所有憑證。
（前情提要：慢霧專欄：資金交給「龍蝦」 AI Agent 真的安全？聯合 Bitget 報告揭露五大風險）
（背景補充：騰訊 SkillHub 匯入了 ClawHub，OpenClaw 創辦人開嗆「禮貌上該問一聲」）

本文目錄

月下載量高達 9,700 萬次的 AI 開源套件 LiteLLM，在 24 日爆出遭供應鏈攻擊，兩個受損版本（v1.82.7、v1.82.8）被植入惡意程式碼，能系統性竊取加密錢包、SSH金鑰、雲端憑證等幾乎所有機敏資訊。

慢霧科技資安長 23pds 今早於 X 上引述該消息並發出嚴重警告。

每月下载量高达 9700 万次的 LiteLLM 发生 PyPI 供应链攻击：
通过 pip install litellm 即可窃取敏感信息，包括 SSH 密钥、云凭据（AWS/GCP/Azure）、Kubernetes 配置、Git 凭据、环境变量（API 密钥）、Shell 历史、加密钱包及数据库密码等。 https://t.co/5s0Ml5HXOz

— 23pds (山哥) (@im23pds) March 25, 2026

誰發現的？攻擊者是誰？

FutureSearch 工程師 Daniel Hnyk 是首個揭露該項漏洞的專業人員，他與 Callum McMahon 在將 LiteLLM 作為 Cursor MCP 外掛的間接依賴引入時，偵測到異常行為，隨即展開逆向分析。

後來發現幕後攻擊者為駭客組織 TeamPCP。該組織先前已入侵知名開源安全掃描器 Trivy 的 CI/CD 管線，藉此取得 LiteLLM 維護者的 PyPI 帳號憑證，隨後上傳兩個帶有後門的惡意版本。

三階段攻擊機制

惡意程式碼的執行分為三個階段，環環相扣：

Stage 1 — 憑證收割：安裝後，惡意的 `.pth` 檔案（`litellm_init.pth`）會在每一個 Python 程式啟動時自動執行，無需任何 `import` 指令觸發。竊取清單涵蓋 SSH 金鑰、`.env` 檔（含 API 金鑰）、AWS / GCP / Azure 雲端憑證、Kubernetes 配置、Git 憑證、Shell 指令歷史，以及加密貨幣錢包檔案與資料庫密碼。

Stage 2 — 資料外洩：所有竊得的資料以硬編碼的 4096-bit RSA 公鑰搭配 AES-256-CBC 加密後，打包成 tar 壓縮檔，透過 POST 請求傳送至 `https://models.litellm.cloud/`——這個域名與 LiteLLM 官方毫無關聯，是攻擊者自行架設的滲漏端點。

Stage 3 — 橫向移動與持久化：若機器存有 Kubernetes token，惡意程式會讀取所有名稱空間的 secrets，並在每個 kube-system 節點部署特權 `alpine:latest` Pod，掛載主機檔案系統。同時於 `/root/.config/sysmon/sysmon.py` 安裝持久後門，並建立 systemd 使用者服務，確保重開機後仍能存活。

事件時間線

整起事件在不到 10 小時內快速演進：

– 3 月 24 日 10:52 UTC：v1.82.8 上傳至 PyPI
– 12:30 UTC：v1.82.7 確認同樣受損
– 13:03 UTC：GitHub 上的通報 Issue 被機器人誤判為垃圾訊息，標記為「not planned」關閉，延誤了公開預警時機
– 20:15 UTC：受損版本終於從 PyPI 下架，隔離解除

從惡意版本上線到下架，約有 9 小時的暴露時間。

加密開發者為何是高風險族群？

LiteLLM 是目前最熱門的 AI 模型代理套件之一，大量加密與 DeFi 專案的 AI Agent 基礎設施都依賴它作為模型路由層。這次攻擊直接把加密貨幣錢包檔案列入竊取清單，意味著任何在同一臺機器上執行 LiteLLM 並持有加密資產的開發者，資產都面臨直接風險。

更值得警惕的是攻擊向量本身：透過 MCP 外掛引入間接依賴，開發者甚至不會察覺自己安裝了 LiteLLM。這揭示了 AI Agent 工具鏈的一個結構性安全盲點：外掛生態的依賴鏈越複雜，供應鏈攻擊的攻擊面就越寬。

緊急修復步驟

曾安裝 LiteLLM 的開發者應立即執行以下檢查：

1. `pip show litellm` 確認目前版本，v1.82.7 或 v1.82.8 為受損版本
2. 刪除受影響版本並清除 pip 快取
3. 檢查 `~/.config/sysmon/sysmon.py` 與 `sysmon.service` 是否存在
4. Kubernetes 環境：掃描 `kube-system` 名稱空間內是否出現 `node-setup-*` Pod
5. 所有 SSH 金鑰、雲端憑證（AWS/GCP/Azure）、API 金鑰與加密錢包私鑰，必須假設已外洩，立即輪換