litellm 投毒事件，一次教科書級供應鏈攻擊的完整解析
昨天（3/24）發生了一件讓 Karpathy 親自發文警告的大事。 litellm——一個每月下載 9,500 萬次的 AI 套件——被植入惡意程式碼。 你可能從來沒裝過它，但你用的 AI 工具替你裝了。
嗨，我是 Future。
今天早上（台灣時間 3 月 25 日），Andrej Karpathy 親自在推特發出警告：AI 開發者最常用的 Python 套件之一 litellm，昨天在 PyPI 上遭到惡意植入。
只要你曾經執行過 pip install litellm，或者你安裝的任何工具——包含 DSPy、MLflow、Open Interpreter——依賴了 litellm，你的機器就有可能在毫不知情的狀況下，把 SSH 金鑰、AWS 憑證、資料庫密碼、加密錢包，打包加密傳送給攻擊者。
這不是假設性風險。這是今天真實發生的事。
先說結論：這是一次等級極高的供應鏈攻擊，受影響範圍遠超 litellm 本身。如果你正在用 Python 開發任何 AI 相關工具，立刻停下來，確認版本。
什麼是 litellm？為什麼這件事這麼嚴重
litellm 是一個「大模型 API 統一介面」套件——讓你用同一套程式碼呼叫 OpenAI、Claude、Gemini、Mistral，不用為每家廠商各寫一套。
GitHub 星標超過 4 萬，每月下載量接近 9,500 萬次。更關鍵的是：它是成千上萬個 AI 工具的依賴項。你不需要直接安裝它，只要你用了依賴它的任何東西，就會被一起帶進來。
這就是供應鏈攻擊的核心邏輯：你攻陷一個節點，整棵樹都中毒。
攻擊的精確時間線
攻陷入口是 litellm 的 CI/CD 流程——他們用 Trivy 做漏洞掃描。攻擊者先攻陷 Trivy，從中竊取 litellm 的 PyPI 發布權杖，再直接把帶毒版本推上去。
安全工具本身，成了突破口。
惡意代碼做了什麼
惡意檔案 litellm_init.pth 會在每次 Python 進程啟動時自動執行——不需要你呼叫 litellm，只要它被安裝，就啟動。
收集清單包含：
SSH 金鑰
AWS / GCP / Azure 雲端憑證
Kubernetes 密鑰與服務帳號令牌
環境變數（所有 API Keys）
Shell 歷史記錄
加密貨幣錢包
SSL 私鑰、資料庫密碼、CI/CD 機密
收集完成後，加密打包傳送到攻擊者控制的伺服器。若偵測到 Kubernetes 環境，還會在每個節點部署特權 Pod，進行橫向擴散。
為什麼這次發現純屬「意外」
這次攻擊之所以被發現，是因為攻擊者寫了一個 bug。
惡意的 .pth 文件會在每次 Python 啟動時觸發，子進程觸發，孫進程又觸發，形成指數級的 fork bomb——把 Callum McMahon 的機器記憶體撐爆了。
Karpathy 的原話是：「如果攻擊者沒有犯這個 bug，這個投毒可能好幾天甚至好幾週都不會被發現。」
台灣視角：AI 開發者的具體風險在哪裡
台灣的 AI 開發社群成長飛速，litellm 幾乎是入門課的標配工具。以下是幾個需要特別注意的場景：
開發者個人機器：本機環境有多少個雲端服務的 API Key？有多少個 GitHub Token？這些全是目標。
新創與代理公司：用 Python 快速搭建 AI 應用的團隊，很可能通過框架工具鏈間接引入 litellm，卻從未意識到這個依賴存在。
CI/CD 環境：自動化建置流程中一旦有 litellm，整個 pipeline 的環境變數都有外洩風險。
Future 的核心洞察
第一：供應鏈攻擊的代價正在指數級上升
以前攻陷一個工具，影響範圍有限。但現在 AI 工具鏈極度複雜，一個工具被攻陷，等同於攻陷所有依賴它的工具。而 AI 開發的特性是：開發者習慣快速安裝、快速迭代，很少有人會仔細審計依賴樹。
第二：安全工具本身是高價值攻擊目標
這次攻擊的入口是 Trivy——一個你信任它來保護你的工具。這個邏輯會持續被利用：攻擊者會優先攻陷你最信任的工具，因為那裡的防衛最低。
第三：「少即是安全」的工程哲學正在被重新評估
Karpathy 提出了一個值得認真思考的觀點：在依賴複雜度極高的現代軟體環境中，對於簡單功能，直接用 LLM 生成代碼，比引入一個外部套件更安全。這不是激進主張，而是工程風險評估的現實考量。
立即行動建議
個人開發者
執行
pip show litellm確認版本1.82.6 是最後乾淨版本，1.82.7 或 1.82.8 需假設憑證已外洩
立即輪換所有可能暴露的 API Key、SSH 金鑰、雲端憑證
企業 IT / 資安團隊
掃描內部所有 Python 環境是否有受影響版本
審計 CI/CD pipeline 的套件依賴
建立套件版本鎖定（
requirements.txtpin 版本）的政策
技術主管 / CTO
這是導入軟體供應鏈安全政策（SBOM、依賴審計）的最佳時機
不要等下一次事件才行動
Karpathy 說這是「現代軟體中最可怕的威脅」。不是誇張，是工程現實。
我是 Future，這裡是《AI觀察日記》。
📬 覺得這期有價值？把《AI未來週報》推薦給一位朋友。 🔗 訂閱：futureaitw.substack.com
太可怕了