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

　　LiteLLM 是一個(gè)在 AI 開(kāi)發(fā)中非常流行和關(guān)鍵的開(kāi)源 Python 庫(kù)，它就是大語(yǔ)言模型（LLM）時(shí)代的“萬(wàn)向節(jié)”或“萬(wàn)能插座”。核心作用是：提供一個(gè)統(tǒng)一的接口（完全兼容 OpenAI API 的格式），讓你能夠無(wú)縫調(diào)用市面上幾乎所有的主流大模型（支持超過(guò) 100 多種 LLM）

　　正因?yàn)樗谋憬菪?，目前很?AI 應(yīng)用、腳手架、開(kāi)發(fā)工具（比如 dspy、某些 Cursor 的 MCP 插件、各種 Agent 框架）都在底層偷偷依賴了它來(lái)處理多模型調(diào)用的問(wèn)題。這也解釋了為什么它一旦“被投毒”，就像水廠被投毒一樣，只要間接喝到水的項(xiàng)目全都會(huì)遭殃。

　　可能被收集的信息

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

　　
簡(jiǎn)介

　　2026年3月24日，一個(gè)名為 1.82.8 的litellm版本被悄無(wú)聲息地發(fā)布到了 PyPI 上。之所以說(shuō)它悄無(wú)聲息，是因?yàn)?GitHub 倉(cāng)庫(kù)里根本沒(méi)有這個(gè)版本的 release 或者 tag，黑客是直接越過(guò)常規(guī)流程，把受感染的包強(qiáng)推到了 PyPI。

　　這個(gè)包里夾帶了私貨：一個(gè)名為litellm_init.pth的文件，34KB 左右大小。做過(guò) Python 開(kāi)發(fā)的都知道，只要環(huán)境里存在.pth文件，Python 解釋器在每次啟動(dòng)時(shí)就會(huì)自動(dòng)執(zhí)行里面的內(nèi)容，甚至你都不需要import litellm。這招非常毒。

　　更要命的是，即便是你從來(lái)沒(méi)主動(dòng)去pip install litellm，你也極有可能中招。很多開(kāi)源項(xiàng)目（如 dspy，依賴litellm>=1.64.0）或者由于在使用 Cursor 的 MCP 插件時(shí)（通過(guò)uvx自動(dòng)拉取依賴），都在不知不覺(jué)中引入了這個(gè)帶毒的包。也就是說(shuō)，享受著便捷的現(xiàn)代工具的同時(shí)，黑客在底層給你悄無(wú)聲息地投毒了。

　　以下是相關(guān)推文的提示：

　　
事件披露

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

　　正如他所說(shuō)："現(xiàn)代軟件里最大的隱患，就是這深不見(jiàn)底的依賴樹(shù)。"

　　
Andrej Karpathy 評(píng)論 毒發(fā)細(xì)節(jié)（技術(shù)深挖）

　　黑客到底是怎么干的？其實(shí)整個(gè)動(dòng)作非常簡(jiǎn)單粗暴。

　　一旦受感染的litellm_init.pth被 Python 執(zhí)行，它會(huì)啟動(dòng)一個(gè)子進(jìn)程，執(zhí)行經(jīng)過(guò)雙重 base64 編碼的惡意代碼。 這段代碼的執(zhí)行分為十分瘋狂的三步：

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

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

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

　　AWS、GCP、Azure 的鑒權(quán)憑據(jù)以及 Kubernetes~/.kube/config。

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

　　還有諸如各個(gè)加密錢包文件和 SSL/TLS 的私鑰。 簡(jiǎn)單來(lái)說(shuō)，只要是你放在電腦里稍微有點(diǎn)價(jià)值的東西，它全搜羅了一遍。

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

　　第三階段：橫向感染如果受害者運(yùn)行在 Kubernetes 環(huán)境中，它會(huì)掃描所有的 cluster secrets，并嘗試在所有的節(jié)點(diǎn)上跑個(gè)特權(quán)容器（Alpine Latest），再給所有宿主機(jī)留下個(gè)持久化后門~/.config/sysmon/sysmon.py以及 systemd 守護(hù)服務(wù)。

　　實(shí)測(cè)與反思

　　之所以這次黑客投毒這么快被抓住，完全是因?yàn)楹诳偷?strong>代碼寫得太爛了。

　　FutureSearch 團(tuán)隊(duì)里有個(gè)小哥叫 Callum McMahon，他正好在 Cursor 里面跑的一個(gè)過(guò)期的本地 MCP 服務(wù)依賴了這玩意。

　　因?yàn)?code>.pth機(jī)制的特殊性，惡意腳本用subprocess.Popen調(diào)用了一個(gè) Python 子進(jìn)程。悲劇發(fā)生了：因?yàn)樽舆M(jìn)程也是個(gè) Python 進(jìn)程，它一樣會(huì)觸發(fā)執(zhí)行.pth。接著，子進(jìn)程又會(huì)觸發(fā)子進(jìn)程……好家伙，這成了一個(gè)完美的無(wú)限遞歸。

　　最后的結(jié)果是，這哥們的電腦內(nèi)存直接被爆破，導(dǎo)致當(dāng)場(chǎng)死機(jī)。如果黑客多花點(diǎn)心思測(cè)一測(cè)（沒(méi)準(zhǔn)這段代碼就是用大模型隨便糊弄生成的呢？）不搞出這個(gè)低級(jí)的 fork bomb 崩潰 bug 的話。估計(jì)這個(gè)毒包會(huì)在很多公司的生產(chǎn)環(huán)境里潛伏數(shù)周，那就真的是不可挽回的災(zāi)難了。

　　總結(jié)

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

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

　　重置所有 credential。如果你被感染，請(qǐng)默認(rèn)你所有的 SSH Key，云上配置甚至銀行密碼等已經(jīng)報(bào)廢，趕緊換新！

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

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

　　制作不易，如果這篇文章覺(jué)得對(duì)你有用，可否點(diǎn)個(gè)關(guān)注。給我個(gè)三連擊：點(diǎn)贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個(gè)，謝謝你看我的文章，我們下篇再見(jiàn)！