大模型 Python 庫 litellm 被投毒，不要更新，不要更新，不要更新

　　今天不聊模型效果，聊一個非常致命的安全問題。就在昨天，AI 圈出了個大事，很多項目每天都在用的litellm被人下毒了！

　　LiteLLM 是一個在 AI 開發中非常流行和關鍵的開源 Python 庫，它就是大語言模型（LLM）時代的“萬向節”或“萬能插座”。核心作用是：提供一個統一的接口（完全兼容 OpenAI API 的格式），讓你能夠無縫調用市面上幾乎所有的主流大模型（支持超過 100 多種 LLM）

　　正因為它的便捷性，目前很多 AI 應用、腳手架、開發工具（比如 dspy、某些 Cursor 的 MCP 插件、各種 Agent 框架）都在底層偷偷依賴了它來處理多模型調用的問題。這也解釋了為什么它一旦“被投毒”，就像水廠被投毒一樣，只要間接喝到水的項目全都會遭殃。

　　可能被收集的信息

　　litellm 是一個很重要的依賴，我也查了一下，也安裝的有，目前的版本還是安全的

　　
簡介

　　2026年3月24日，一個名為 1.82.8 的litellm版本被悄無聲息地發布到了 PyPI 上。之所以說它悄無聲息，是因為 GitHub 倉庫里根本沒有這個版本的 release 或者 tag，黑客是直接越過常規流程，把受感染的包強推到了 PyPI。

　　這個包里夾帶了私貨：一個名為litellm_init.pth的文件，34KB 左右大小。做過 Python 開發的都知道，只要環境里存在.pth文件，Python 解釋器在每次啟動時就會自動執行里面的內容，甚至你都不需要import litellm。這招非常毒。

　　更要命的是，即便是你從來沒主動去pip install litellm，你也極有可能中招。很多開源項目（如 dspy，依賴litellm>=1.64.0）或者由于在使用 Cursor 的 MCP 插件時（通過uvx自動拉取依賴），都在不知不覺中引入了這個帶毒的包。也就是說，享受著便捷的現代工具的同時，黑客在底層給你悄無聲息地投毒了。

　　以下是相關推文的提示：

　　
事件披露

　　甚至 Andrej Karpathy 大神都在 X 上吐槽說，這是一個 "Software horror"（軟件界的恐怖故事）。簡單地pip install litellm，瞬間就會讓你的一切底褲被看光：SSH 密鑰、環境變量里所有的 API Key、云上憑證、Kubernetes 配置，甚至是加密錢包...

　　正如他所說："現代軟件里最大的隱患，就是這深不見底的依賴樹。"

　　
Andrej Karpathy 評論 毒發細節（技術深挖）

　　黑客到底是怎么干的？其實整個動作非常簡單粗暴。

　　一旦受感染的litellm_init.pth被 Python 執行，它會啟動一個子進程，執行經過雙重 base64 編碼的惡意代碼。 這段代碼的執行分為十分瘋狂的三步：

　　第一階段：大掃除式的信息收集腳本就像個餓漢，瘋狂搜刮你電腦上的所有的秘密。

　　所有的 SSH 私鑰 (~/.ssh/id_rsa,~/.ssh/config等等)。

　　你的環境配置 (printenv抓走你所有的 API Keys)。

　　AWS、GCP、Azure 的鑒權憑據以及 Kubernetes~/.kube/config。

　　Shell 的歷史記錄 (.bash_history,.zsh_history)、甚至是數據庫連接配置。

　　還有諸如各個加密錢包文件和 SSL/TLS 的私鑰。 簡單來說，只要是你放在電腦里稍微有點價值的東西，它全搜羅了一遍。

　　第二階段：打包傳輸在獲取了這堆極其致命的信息后，惡意腳本通過openssl rand隨機生成一個 32 字節的 AES-256 密鑰，并將上述所有的戰利品加密。這一步非常狡猾，它用寫死的一段 4096 位 RSA 公鑰通過 OAEP 填充把這個 AES 密碼給加密了，最終打包成tpcp.tar.gz文件。 然后發送到一個極具欺騙性的自建域名上：https://models.litellm.cloud/，不知道的還以為是官方的功能接口。

　　第三階段：橫向感染如果受害者運行在 Kubernetes 環境中，它會掃描所有的 cluster secrets，并嘗試在所有的節點上跑個特權容器（Alpine Latest），再給所有宿主機留下個持久化后門~/.config/sysmon/sysmon.py以及 systemd 守護服務。

　　實測與反思

　　之所以這次黑客投毒這么快被抓住，完全是因為黑客的代碼寫得太爛了。

　　FutureSearch 團隊里有個小哥叫 Callum McMahon，他正好在 Cursor 里面跑的一個過期的本地 MCP 服務依賴了這玩意。

　　因為.pth機制的特殊性，惡意腳本用subprocess.Popen調用了一個 Python 子進程。悲劇發生了：因為子進程也是個 Python 進程，它一樣會觸發執行.pth。接著，子進程又會觸發子進程……好家伙，這成了一個完美的無限遞歸。

　　最后的結果是，這哥們的電腦內存直接被爆破，導致當場死機。如果黑客多花點心思測一測（沒準這段代碼就是用大模型隨便糊弄生成的呢？）不搞出這個低級的 fork bomb 崩潰 bug 的話。估計這個毒包會在很多公司的生產環境里潛伏數周，那就真的是不可挽回的災難了。

　　總結

　　這起利用供應鏈攻擊獲取隱私信息的事件給我們敲響了警鐘。 如果你的項目碰巧或者間接在近兩天安裝或更新了依賴litellm>=1.82.8的庫（或者你的~/.cache/uv里能翻出litellm_init.pth）：

　　立即刪除、清空 pip / uv 的 cache。

　　重置所有 credential。如果你被感染，請默認你所有的 SSH Key，云上配置甚至銀行密碼等已經報廢，趕緊換新！

　　這件事就像 Karpathy 說的，在現代軟件工程體系下，把復雜性推給無數的依賴包，其實是很危險的一件事。面對 AI 爆發式生長的同時，我們也需要更加關注安全隔離。遇到簡單的需求，直接用大模型用原生語言 "Yoink" (縫合) 代碼，而不是去糊里糊涂地拉一堆你這輩子都看不完代碼的第三方庫，或許才是真正的自保之道。

　　官方鏈接留底（雖然官方已經把受感染的版本下架清理了，但依舊觸目驚心）：

　　制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！