2026 年 3 月 24 日上午 10:52 UTC，有人把一個藏了後門的 litellm 1.82.8 推上了 PyPI。六分鐘後，一位工程師的筆電因為 11,000 個 Python 程序同時爆開而當機。

他原本以為是 Cursor 更新搞的鬼。結果是一場精心設計的供應鏈攻擊——而且他是全世界第一個發現的人。

事件怎麼發生的

litellm 是 AI 開發圈的常客。做 LLM 應用的人幾乎都用過它——統一呼叫 OpenAI、Anthropic、Gemini 等不同模型 API 的 proxy 層。PyPI 上的週下載量是百萬級別。

攻擊者拿到了 litellm 的 PyPI 發布權限（很可能是維護者帳號被盜），直接推了一個 1.82.8 版本上去。GitHub 上完全沒有對應的 tag 或 release——繞過了正常的發布流程。

惡意程式碼藏在一個叫 litellm_init.pth 的檔案裡。.pth 是 Python 的一個古老機制：放在 site-packages 目錄下的 .pth 檔案，會在每次 Python 啟動時自動執行。不需要 import，不需要呼叫，Python 直譯器一啟動就跑。

三階段攻擊鏈

這個惡意程式的設計相當完整：

第一階段：收割憑證。 掃描本機上所有敏感檔案——SSH 私鑰、.env、AWS/GCP/Azure 的 credential、Kubernetes config、資料庫密碼、加密貨幣錢包、shell history。能偷的全偷。

第二階段：加密外傳。 用寫死的 4096-bit RSA 公鑰加密竊取的資料，打包成 tar，POST 到 models.litellm.cloud。這個 domain 不屬於合法的 litellm 基礎設施。

第三階段：橫向擴散。 如果偵測到 Kubernetes 環境，讀取所有 namespace 的 secret，在每個 node 上建立 privileged pod（用 alpine:latest），掛載宿主機檔案系統，安裝 systemd 持久化後門。本機也會在 ~/.config/sysmon/sysmon.py 裝一個。

攻擊者唯一的失誤：.pth 檔在每次 Python 啟動時都會觸發，而惡意程式碼用 subprocess.Popen 開新的 Python 子程序——子程序啟動時又觸發 .pth，無限遞迴，造成 fork bomb。惡意程式自己把自己搞當機了。

發現過程：一場即時偵探劇

FutureSearch 的工程師 Callum McMahon 公開了完整的 Claude Code 對話逐字稿。這段紀錄本身就值得一讀，因為它展示了一個不是資安專家的開發者，如何用 AI 工具在一小時內從「筆電怎麼這麼慢」追查到「這是供應鏈攻擊」。

時間軸：

時間 (UTC) 事件
10:52 攻擊者將惡意版本推上 PyPI
10:58 Cursor 的 MCP plugin 自動下載了這個版本
11:07 惡意程式嘗試安裝持久化後門
11:09 工程師強制關機（後門檔案 0 bytes，寫入被中斷）
11:13 開始用 Claude Code 調查
11:40 確認是惡意程式
11:58 在 Docker 容器中驗證 PyPI 上仍有惡意套件
11:58 回報 PyPI security + litellm 維護者
12:02 發布揭露文章

從攻擊發生到公開揭露，不到兩小時。有意思的是，Claude 一開始還在「安慰」工程師說這是正常的 Claude Code 行為——直到工程師堅持繼續挖，AI 才轉向認真分析。

對開發者的啟示

這件事有幾個值得深思的點。

你的 AI 工具鏈比你想像的更長。 Cursor 啟動一個 MCP plugin，plugin 依賴 litellm，litellm 從 PyPI 拉了 77 個套件。你以為你只是開了個編輯器，實際上你觸發了一條很長的依賴鏈。任何一環被攻破，你的 SSH 私鑰就可能在你不知情的情況下被打包寄出去。

版本 pin 救了一命。 FutureSearch 的正式專案環境把 litellm 鎖在 <1.77.3。被感染的是 Cursor 的 MCP plugin 環境，因為它用 uvx 動態拉取最新版。正式環境安全，開發工具環境中招。

.pth 是一個被低估的攻擊面。 大多數 Python 開發者不知道 .pth 檔案的存在，更不知道它會在每次 Python 啟動時自動執行。這不是新東西，但用在供應鏈攻擊裡，殺傷力巨大。

AI 是雙面刃。 攻擊者可能用 AI 寫惡意程式，但發現者也是用 AI（Claude Code）在一小時內完成了完整的惡意程式分析和事件回應。這個效率在以前是不可能的。

你現在該檢查什麼

如果你最近有用到 litellm，跑一下這些：

1
2
3
4
5
6
7
8
9
10
11
12
# 檢查安裝的版本
pip show litellm

# 搜尋 uv 快取中的惡意檔案
find ~/.cache/uv -name "litellm_init.pth" 2>/dev/null

# 檢查持久化後門
ls -la ~/.config/sysmon/ 2>/dev/null
ls -la ~/.config/systemd/user/sysmon.service 2>/dev/null

# K8s 環境檢查可疑 pod
kubectl get pods -n kube-system | grep "node-setup" 2>/dev/null

如果找到任何東西，假設你機器上的所有憑證都已經洩漏。全部輪換，沒有例外。

更根本的問題

我們整個 AI 開發生態系正在建立越來越深的依賴鏈。一個 LLM proxy library 的 PyPI 帳號被盜，影響的不只是直接使用者——是整個通過 MCP plugin、IDE extension、CI/CD pipeline 間接依賴它的生態系。

litellm 的惡意版本在 PyPI 上存活了數小時。在這段時間裡，每一個 pip install litellm、每一個 uvx 動態拉取、每一個 CI/CD pipeline 的 pip install -r requirements.txt，都可能中招。

FutureSearch 後續分析估計有 47,000 次下載受影響。

這不是第一次，也不會是最後一次。但這次的教訓特別清楚：你的開發環境和你的生產環境一樣需要安全防護。鎖定版本、審計依賴、監控異常程序。尤其是在 AI 工具讓依賴鏈變得越來越長、越來越不透明的今天。

事件相關連結：FutureSearch 揭露文章、Claude Code 完整對話逐字稿、CVE: PYSEC-2026-2