如果你最近還把「代理安全」主要理解成 提示注入 或模型越權，那 LiteLLM 這起事件會把現實拉得更硬一些。這次出問題的不是模型回答錯，而是很多團隊用來串接多家模型供應商的中介層本身被塞進惡意程式。結果是，只要安裝了被污染的版本，攻擊程式就能在你啟動任何 Python 解譯器時自動執行，開始蒐集環境變數、SSH 金鑰、雲端憑證、資料庫設定，甚至進一步嘗試在 Kubernetes 叢集中橫向擴散。
這起事故之所以值得單獨寫，不只是因為 LiteLLM 很紅，而是因為它剛好位在今天很多 LLM 應用最不顯眼、卻最危險的一層。你可能沒直接「用」它，但你的代理框架、內部工具、IDE 外掛、MCP 整合或多模型路由服務，很可能把它當成底層共通介面。當這層被打穿，受害的就不只是某個 app，而是整段從本機開發、CI/CD、雲端部署到生產環境的秘密管理鏈。
這次到底發生了什麼
目前最明確的公開資訊，來自 FutureSearch 的技術分析、LiteLLM GitHub issue、以及已上線的 PYSEC-2026-2 / OSV 安全通報。根據這些資料，受影響版本至少包括 1.82.7 與 1.82.8。其中 1.82.8 最危險的地方，是 wheel 內含一個 litellm_init.pth 檔案；這種 .pth 檔會在 Python 啟動時由 site 機制自動執行，所以根本不需要 import litellm，只要環境裡裝了該版本，就可能中招。
簡單說，這不是「你叫它跑了什麼程式」的問題，而是「你一開 Python 它就先跑了」。GitHub issue 中已有人直接示範，惡意 .pth 會透過 subprocess.Popen 啟動後續 payload。FutureSearch 則補上更完整的分析，指出它會蒐集 SSH keys、.env、雲端供應商認證、資料庫密碼、Git 與 Docker 設定、shell 歷史，並將資料加密後送往 models.litellm.cloud，這個網域並不是 LiteLLM 的官方基礎設施。
更糟的是，事件後續並沒有停在單機外洩。官方安全通報與 FutureSearch 都提到，惡意程式還包含持久化與叢集擴散邏輯，會偽裝成系統遙測服務，在主機上建立持久化機制；如果環境裡存在 Kubernetes service account token，程式還會試圖讀取叢集 secrets、建立高權限 pod，等於把一個原本看似「開發依賴」的問題，瞬間抬升成基礎設施層級的事件。
受影響範圍不是小眾專案，而是大量 AI 應用的公共管線
LiteLLM 在 PyPI 上的定位，本來就是「用一套介面呼叫 100+ 模型供應商」的統一路由層。官方頁面甚至直接列出 OpenAI Agents SDK、OpenHands、Stripe、Netflix、Google ADK 等 OSS adopter 名單。這代表它不是邊角工具，而是很多團隊為了少寫重複接線碼而採用的膠水層。
這種工具一旦出事，殺傷力比單一應用層漏洞更大，原因很直觀：
| 層級 | 平常角色 | 這次事件的風險 |
|---|---|---|
| 本機開發環境 | 開發者測模型、串路由、跑代理 | SSH 金鑰、.env、Git 憑證直接外洩 |
| CI/CD | 自動建置與部署 | 雲端 access key、registry secrets 被帶走 |
| 容器 / 叢集 | 跑代理服務與路由 proxy | Kubernetes token、叢集 secrets 可能被橫向利用 |
| 生產代理系統 | 對多模型做統一路由 | 連上游模型 API 與下游客戶資料都可能一起暴露 |
也正因為 LiteLLM 常被放在「先接上再說」的位置，很多團隊原本未必把它當成高風險依賴。這次事故直接提醒所有人，AI 生態最危險的攻擊面，往往不是你最擔心的大模型，而是你最習慣信任的小套件。
版本差異值得注意：1.82.7 與 1.82.8 都有事，但觸發方式不一樣
公開通報目前把受影響範圍列在 1.82.7 到 1.82.8。FutureSearch 最早先抓到 1.82.8，之後又更新指出 1.82.7 也被污染。差別在於，1.82.8 有更直接的 .pth 自動執行入口；而 1.82.7 的惡意 payload 則藏在程式碼內部。
這個差別很重要，因為它會影響排查思路。若是 1.82.8，你不只要看應用程式有沒有 import 過 LiteLLM，還要把所有可能啟動過 Python 的虛擬環境、CI runner、快取路徑、甚至 uv cache 一起檢查。FutureSearch 建議的調查重點包括 litellm_init.pth、~/.config/sysmon/sysmon.py、systemd user service，以及叢集內可疑的 node-setup-* pod。換句話說，這不是「pip uninstall 就好」的等級。
這起事故最刺痛 AI 代理生態的地方，在於它證明「上下文全都是攻擊面」
The Decoder 引用 NVIDIA AI Director Jim Fan 的評論，稱這是 "pure nightmare fuel"。這個說法其實很精準。因為今天的代理系統，最依賴的正是大量上下文與大量連接：讀 repo、讀文件、叫工具、看 secret、進雲端、碰叢集。LiteLLM 這種多模型 proxy 原本是為了讓整個系統更靈活，結果反過來把多個供應商、多組憑證、多種環境配置，全部集中到同一個爆炸半徑裡。
這也讓一個常被忽略的現實浮出來：代理時代的安全，不能只盯模型輸出內容，也不能只盯 prompt injection。依賴樹、發版管線、PyPI token、建置腳本、快取、容器權限、叢集權限，這些老派軟體供應鏈問題，現在反而因為代理的高權限與高整合而變得更致命。
OSV 安全通報甚至指出，這次事件的前情與 API token 暴露及上游 Trivy 依賴遭利用有關。這表示問題不只是「作者帳號被盜」，而是整個現代套件發佈鏈在某個環節先裂開，再讓攻擊者把惡意版本送進最廣泛的安裝路徑。
現在最務實的動作，不是等更多說明，而是直接當成外洩事故處理
這件事最不能犯的錯，是把它當作普通 bug。現有官方與半官方建議都很一致：
- 確認是否安裝過
litellm==1.82.7或1.82.8。 - 立即移除污染版本，並清空 pip 或
uv快取。 - 假設所有可存取憑證都已暴露，直接輪替 SSH keys、雲端金鑰、資料庫密碼、API tokens。
- 檢查本機與伺服器的持久化痕跡，特別是偽裝的 system telemetry service。
- 稽核 Kubernetes 叢集 secrets、service account 使用記錄與異常 pod。
若你的團隊最近在做多模型代理、企業內部 LLM gateway、或把 LiteLLM 當成 agent runtime 的共通層，現在最該問的不是「有沒有官方完整復盤」，而是「我們是不是把最多密鑰集中在最方便的那一層了」。
這起事件很可能會改變接下來幾個月 AI 開發圈的工具選型。大家不會停止使用多模型抽象層，但會更在意可審計發版、穩定版分支、最小依賴、隔離執行與憑證分層。FutureSearch 那句「no prompt injection required」其實說穿了重點：代理願景最大的破口，很多時候根本不需要模型被騙，只需要你先把惡意套件裝進去。