新智元報(bào)道

編輯：元宇

【新智元導(dǎo)讀】一次只持續(xù)了不到1小時的投毒事件，撕開了AI基礎(chǔ)設(shè)施「信任鏈」的致命裂縫。更魔幻的是，全行業(yè)逃過一劫，居然靠黑客自己寫出bug。

剛剛，科技界經(jīng)歷了一場驚心動魄的「供應(yīng)鏈投毒」危機(jī)。

3月24日上午，一個普通的版本更新LiteLLM 1.82.8，出現(xiàn)在PyPI上。

全球數(shù)百萬開發(fā)者的終端，每天都在自動拉取這類更新，沒有人注意到這個版本里藏著一段精心設(shè)計(jì)的惡意代碼：

只要你執(zhí)行一句pip install litellm，你機(jī)器上的SSH密鑰、云服務(wù)憑證、數(shù)據(jù)庫密碼、加密貨幣錢包……會在幾秒內(nèi)被加密打包，發(fā)往一個偽裝成官方的服務(wù)器。

然后，如果你的機(jī)器連著Kubernetes集群，惡意代碼會自動橫向擴(kuò)散，在每個節(jié)點(diǎn)上植入后門。

LiteLLM，是當(dāng)下AI應(yīng)用開發(fā)中最核心的基礎(chǔ)設(shè)施之一。它的開源包全球月下載量9700萬。

但這次，這根管道卻差點(diǎn)被人從內(nèi)部鑿穿，而且之所以逃過一劫，純屬意外。

攻擊者自己的代碼里有個bug，導(dǎo)致目標(biāo)機(jī)器直接崩潰。如果沒有這個bug，沒人知道這次「投毒」還要擴(kuò)散多久。

目睹這一幕，Andrej Karpathy深夜發(fā)文，直呼這是「軟件驚魂」。

Karpathy帖子中所列的「竊取清單」堪比「災(zāi)難現(xiàn)場」：

AWS/GCP/Azure 憑據(jù)、Kubernetes配置、CI/CD 機(jī)密、數(shù)據(jù)庫密碼、SSH 密鑰……

「驚魂」過后，Karpathy說了一句可能改變整個行業(yè)開發(fā)范式的話：

「我越來越抗拒依賴了?！?/p>

pip install

然后你的一切都沒了

這不是一次普通的漏洞告警，只要你在終端里敲下這句看似人畜無害的pip install litellm，你的整臺機(jī)器就會瞬間對攻擊者徹底敞開大門。

根據(jù)安全分析，這次投毒不是簡單地偷幾個密碼，而是對整臺機(jī)器和整個集群的「全面洗劫」。

攻擊者的竊取清單幾乎覆蓋了開發(fā)者最核心的一切：

• SSH私鑰和配置

• AWS/GCP/Azure憑證

• Kubernetes配置和Token

• .env中的API Key

• git憑證

• 數(shù)據(jù)庫密碼

• shell歷史記錄

• SSL私鑰

• CI/CD機(jī)密

• 加密貨幣錢包文件

• 環(huán)境變量中的敏感信息

更可怕的是，LiteLLM根本不是一個冷門工具。

作為連接各大語言模型提供商的關(guān)鍵中間件，它是名副其實(shí)的AI應(yīng)用層「水電煤」，擁有每個月高達(dá)9700萬次的下載量！

很多項(xiàng)目用它統(tǒng)一連接OpenAI、Anthropic、Google、Azure等多家模型提供商。

許多Agent框架、MCP Server、LLM編排工具，也會把它作為底層依賴引入。

這讓這次投毒的影響，升級到了整條AI依賴鏈被撕開一道口子。

即使你根本不知道什么是LiteLLM，只要你執(zhí)行了pip install dspy（它依賴litellm>=1.64.0），或者安裝了其他任何依賴該包的大型AI項(xiàng)目，你都會作為傳遞依賴的受害者中招。

一次投毒，順著錯綜復(fù)雜的依賴樹，瞬間就會輻射到無數(shù)AI項(xiàng)目中。

這就是為什么Karpathy會直接把它定義為「軟件界的恐怖故事」。

一次靠黑客「代碼寫太爛」才暴露的史詩級漏洞

你可能會想，既然影響這么大，那安全公司一定第一時間拉響了警報(bào)吧？

但事實(shí)的真相有點(diǎn)荒誕和諷刺。

最早發(fā)現(xiàn)異常的，是Callum McMahon團(tuán)隊(duì)的工程師。

當(dāng)時，他們在Cursor里使用一個MCP插件，而這個插件會把LiteLLM作為傳遞依賴?yán)M(jìn)來。

安裝到被投毒的LiteLLM1.82.8之后，機(jī)器突然開始異常：內(nèi)存被瘋狂吃滿，最后直接崩潰。

后來追進(jìn)去才發(fā)現(xiàn)，問題出在一個.pth文件上。

對很多Python開發(fā)者來說，.pth文件平時幾乎沒有存在感。

但正因這樣，它可以在Python解釋器啟動時自動執(zhí)行代碼。攻擊者就在這里塞進(jìn)了惡意啟動器。

按原本設(shè)計(jì)，它會悄悄拉起子進(jìn)程，執(zhí)行后續(xù)竊密和外傳邏輯。

結(jié)果它寫砸了。

因?yàn)樽舆M(jìn)程本身也會再次觸發(fā)同一個.pth文件，于是每個新進(jìn)程都會再生出新進(jìn)程，進(jìn)入指數(shù)級自我復(fù)制，最后演變成一個fork bomb，把機(jī)器資源迅速吃光。

也就是說，這次攻擊之所以暴露，只是因?yàn)樗约喊炎约和嬲恕?/p>

如果攻擊者不是靠vibe coding搞出了這個烏龍，這次如此隱蔽的后門，極可能會在全網(wǎng)潛伏數(shù)周甚至數(shù)月而不被察覺。

全行業(yè)的安全防線竟然靠的是黑客寫了個bug，整個生態(tài)的安全檢測機(jī)制，在這一刻形同虛設(shè)。

這也是整件事最讓人后怕的地方。

一場精心策劃的「 供應(yīng)鏈投毒」

從攻擊手法的精密程度來看，這是一場有組織的「供應(yīng)鏈投毒」。

首先，攻擊者不知通過何種手段攻破了維護(hù)者的PyPI賬戶，直接繞過了官方的CI/CD發(fā)布流程，把帶有后門的v1.82.7和v1.82.8版本強(qiáng)行上傳到了PyPI倉庫。

在LiteLLM的GitHub源碼倉庫中，你甚至找不到對應(yīng)的tag或release記錄。

其次，攻擊載荷分為極其專業(yè)的三段式：

第一階段，是精準(zhǔn)的大范圍「收集」；

第二階段，是用內(nèi)置的4096位RSA公鑰配合AES-256-CBC進(jìn)行高強(qiáng)度「加密」，并外傳到一個極具迷惑性的假域名（models.litellm.cloud）；

第三階段最致命，如果環(huán)境中存在Kubernetes的憑證，它會直接「橫向移動」，讀取集群中所有命名空間下的全部Secret，并在所有節(jié)點(diǎn)創(chuàng)建特權(quán)Pod，植入持久化后門。

LiteLLM 1.82.8的惡意litellm_init.pth文件，在Python解釋器啟動階段被自動觸發(fā)，進(jìn)而執(zhí)行三階段payload攻擊

最令人毛骨悚然的一個細(xì)節(jié)發(fā)生在事發(fā)后：

當(dāng)社區(qū)試圖在GitHub issue中討論此事時，該issue被所有者直接以「not planned」關(guān)閉，隨后被數(shù)百個機(jī)器人賬號瘋狂刷屏淹沒。

維護(hù)者的賬號和開發(fā)環(huán)境顯然已被全面接管，攻擊者正在系統(tǒng)性地掩蓋痕跡。

目前，LiteLLM官方已經(jīng)介入，懷疑此次事件與更大范圍的Trivy安全事件有關(guān)（疑似使用被盜憑證），并緊急聯(lián)系了Google Mandiant安全團(tuán)隊(duì)進(jìn)行取證。

所幸的是，官方Docker鏡像的用戶因固定了版本而免遭一劫。

但這套完整的APT（高級持續(xù)性威脅）手法，已經(jīng)宣告了「戰(zhàn)爭」的升級。

Karpathy的「反依賴宣言」

AI開發(fā)范式要變了

這場災(zāi)難，正在深刻改變硅谷頂層技術(shù)精英對軟件工程的底層認(rèn)知。

傳統(tǒng)的軟件工程觀念一直教導(dǎo)我們：不要重復(fù)造輪子。依賴是構(gòu)建宏大金字塔的堅(jiān)實(shí)磚塊。

但在這次事件后，Karpathy在推文中拋出了他的「反依賴宣言」：

這也是為什么我越來越抗拒依賴，更傾向于在功能足夠簡單、而且確實(shí)可行的時候，直接用LLM去「順」一段功能來用。

從「依賴是磚塊」到「依賴是定時炸彈」，這不僅僅是情緒的發(fā)泄，更是AI時代開發(fā)范式的重大轉(zhuǎn)折。

每次執(zhí)行pip install，你都在整棵依賴樹深不可測的某一環(huán)，引入了致命的未知風(fēng)險。

當(dāng)大模型已經(jīng)強(qiáng)大到能夠直接生成和替換第三方依賴的底層邏輯時，「少依賴」將不再是代碼潔癖，而會成為核心的安全策略。

這其中還隱藏著一個極具諷刺意味的閉環(huán)：

Callum之所以中招，是因?yàn)槭褂昧薃I編碼工具Cursor，通過MCP插件引入了AI中間件litellm。

AI工具鏈自身，竟然成了最大的攻擊面。

AI正在飛速創(chuàng)造解決問題的新范式，但同時也在創(chuàng)造前所未有的新漏洞。

9700萬次下載背后的「信任危機(jī)」

LiteLLM官方已經(jīng)在做止血動作：

下架受污染版本；輪換維護(hù)者憑證；建立新的授權(quán)維護(hù)者；聯(lián)系Mandiant做取證分析；提示用戶排查受影響版本、查找IoC、輪換所有憑證。

https://docs.litellm.ai/blog/security-update-march-2026

雖然，LiteLLM事件以不到1小時的「鬧劇」收場，受污染版本已被撤回，憑證也已輪換，但真正令人不安的是，這次事件之所以沒有演變成更大規(guī)模的靜默災(zāi)難，不是靠安全體系發(fā)現(xiàn)了它，而是因?yàn)楹诳妥约撼鲥e。

9700萬的月下載量，意味著全行業(yè)進(jìn)行了9700萬次「信任賭博」。

這次「投毒事件」暴露出AI基礎(chǔ)設(shè)施中開源供應(yīng)鏈的信任模型，也可能是極其脆弱的：

你以為你信任的是成千上萬行經(jīng)過審查的開源代碼，但實(shí)際上，你信任的僅僅是某個遠(yuǎn)在天邊的包維護(hù)者沒有把他的PyPI賬號密碼搞丟，或者他的電腦沒有中木馬。

這種系統(tǒng)性的安全風(fēng)險，對于過度依賴開源的AI生態(tài)無疑是一記重錘。

如果AI開發(fā)者和企業(yè)大量依賴PyPI等開源包，而基礎(chǔ)設(shè)施安全又僅僅寄托在「上游沒有被黑」這種虛幻的假設(shè)上，類似危險的重演，可能只是時間問題。

LiteLLM只是一個開始，誰也無法回答那個最讓人不安的問題：

下一個被投毒的包，會是哪個？

參考資料：

https://x.com/karpathy/status/2036487306585268612?s=20%20

https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/