連Karpathy都怕了！9千萬(wàn)級(jí)AI包被投毒，竟靠黑客寫出bug救命

新智元報(bào)道

編輯：元宇

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

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

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

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

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

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

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

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

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

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

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

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

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

「我越來(lái)越抗拒依賴了。」

pip install

然后你的一切都沒了

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

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

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

• SSH私鑰和配置

• AWS/GCP/Azure憑證

• Kubernetes配置和Token

• .env中的API Key

• git憑證

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

• shell歷史記錄

• SSL私鑰

• CI/CD機(jī)密

• 加密貨幣錢包文件

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

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

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

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

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

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

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

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

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

一次靠黑客「代碼寫太爛」才暴露的史詩(shī)級(jí)漏洞

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

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

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

當(dāng)時(shí)，他們?cè)贑ursor里使用一個(gè)MCP插件，而這個(gè)插件會(huì)把LiteLLM作為傳遞依賴?yán)M(jìn)來(lái)。

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

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

對(duì)很多Python開發(fā)者來(lái)說(shuō)，.pth文件平時(shí)幾乎沒有存在感。

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

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

結(jié)果它寫砸了。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Karpathy的「反依賴宣言」

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

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

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

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

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

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

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

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

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

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

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

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

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

LiteLLM官方已經(jīng)在做止血?jiǎng)幼鳎?/p>

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

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

雖然，LiteLLM事件以不到1小時(shí)的「鬧劇」收?qǐng)觯芪廴景姹疽驯怀坊兀瑧{證也已輪換，但真正令人不安的是，這次事件之所以沒有演變成更大規(guī)模的靜默災(zāi)難，不是靠安全體系發(fā)現(xiàn)了它，而是因?yàn)楹诳妥约撼鲥e(cuò)。

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

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

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

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

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

LiteLLM只是一個(gè)開始，誰(shuí)也無(wú)法回答那個(gè)最讓人不安的問題：

下一個(gè)被投毒的包，會(huì)是哪個(gè)？

參考資料：

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

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