連Karpathy都怕了！9千萬級AI包被投毒，竟靠黑客寫出bug救命

新智元報道

編輯：元宇

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

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

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

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

只要你執行一句pip install litellm，你機器上的SSH密鑰、云服務憑證、數據庫密碼、加密貨幣錢包……會在幾秒內被加密打包，發往一個偽裝成官方的服務器。

然后，如果你的機器連著Kubernetes集群，惡意代碼會自動橫向擴散，在每個節點上植入后門。

LiteLLM，是當下AI應用開發中最核心的基礎設施之一。它的開源包全球月下載量9700萬。

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

攻擊者自己的代碼里有個bug，導致目標機器直接崩潰。如果沒有這個bug，沒人知道這次「投毒」還要擴散多久。

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

Karpathy帖子中所列的「竊取清單」堪比「災難現場」：

AWS/GCP/Azure 憑據、Kubernetes配置、CI/CD 機密、數據庫密碼、SSH 密鑰……

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

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

pip install

然后你的一切都沒了

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

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

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

• SSH私鑰和配置

• AWS/GCP/Azure憑證

• Kubernetes配置和Token

• .env中的API Key

• git憑證

• 數據庫密碼

• shell歷史記錄

• SSL私鑰

• CI/CD機密

• 加密貨幣錢包文件

• 環境變量中的敏感信息

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

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

很多項目用它統一連接OpenAI、Anthropic、Google、Azure等多家模型提供商。

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

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

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

一次投毒，順著錯綜復雜的依賴樹，瞬間就會輻射到無數AI項目中。

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

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

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

但事實的真相有點荒誕和諷刺。

最早發現異常的，是Callum McMahon團隊的工程師。

當時，他們在Cursor里使用一個MCP插件，而這個插件會把LiteLLM作為傳遞依賴拉進來。

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

后來追進去才發現，問題出在一個.pth文件上。

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

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

按原本設計，它會悄悄拉起子進程，執行后續竊密和外傳邏輯。

結果它寫砸了。

因為子進程本身也會再次觸發同一個.pth文件，于是每個新進程都會再生出新進程，進入指數級自我復制，最后演變成一個fork bomb，把機器資源迅速吃光。

也就是說，這次攻擊之所以暴露，只是因為它自己把自己玩炸了。

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

全行業的安全防線竟然靠的是黑客寫了個bug，整個生態的安全檢測機制，在這一刻形同虛設。

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

一場精心策劃的「 供應鏈投毒」

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

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

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

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

第一階段，是精準的大范圍「收集」；

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

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

LiteLLM 1.82.8的惡意litellm_init.pth文件，在Python解釋器啟動階段被自動觸發，進而執行三階段payload攻擊

最令人毛骨悚然的一個細節發生在事發后：

當社區試圖在GitHub issue中討論此事時，該issue被所有者直接以「not planned」關閉，隨后被數百個機器人賬號瘋狂刷屏淹沒。

維護者的賬號和開發環境顯然已被全面接管，攻擊者正在系統性地掩蓋痕跡。

目前，LiteLLM官方已經介入，懷疑此次事件與更大范圍的Trivy安全事件有關（疑似使用被盜憑證），并緊急聯系了Google Mandiant安全團隊進行取證。

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

但這套完整的APT（高級持續性威脅）手法，已經宣告了「戰爭」的升級。

Karpathy的「反依賴宣言」

AI開發范式要變了

這場災難，正在深刻改變硅谷頂層技術精英對軟件工程的底層認知。

傳統的軟件工程觀念一直教導我們：不要重復造輪子。依賴是構建宏大金字塔的堅實磚塊。

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

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

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

每次執行pip install，你都在整棵依賴樹深不可測的某一環，引入了致命的未知風險。

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

這其中還隱藏著一個極具諷刺意味的閉環：

Callum之所以中招，是因為使用了AI編碼工具Cursor，通過MCP插件引入了AI中間件litellm。

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

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

9700萬次下載背后的「信任危機」

LiteLLM官方已經在做止血動作：

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

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

雖然，LiteLLM事件以不到1小時的「鬧劇」收場，受污染版本已被撤回，憑證也已輪換，但真正令人不安的是，這次事件之所以沒有演變成更大規模的靜默災難，不是靠安全體系發現了它，而是因為黑客自己出錯。

9700萬的月下載量，意味著全行業進行了9700萬次「信任賭博」。

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

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

這種系統性的安全風險，對于過度依賴開源的AI生態無疑是一記重錘。

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

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

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

參考資料：

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

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