整理 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

如果你是一名 Python 開發(fā)者，對 pip install 命令肯定很熟悉——這是最常用的套件安裝指令，可用來從 PyPI 或其它來源安裝、升級與管理套件。

但就在 3 月 24 日，這個看似無害的動作，差點變成一場席卷整個開源生態(tài)的安全災(zāi)難：出問題的是 AI 開發(fā)圈中使用非常廣泛的 Python 庫 LiteLLM，它在 PyPI 上發(fā)布的兩個版本（1.82.7 和 1.82.8）被發(fā)現(xiàn)包含惡意代碼。

簡單介紹一下，LiteLLM 的作用很簡單：統(tǒng)一調(diào)用不同大模型 API，讓開發(fā)者可以在 OpenAI、Anthropic、Google 等模型之間自由切換。因此，它被大量 AI 項目當作底層依賴使用，月下載量高達 9700 萬次。

換句話說：它一旦出問題，影響范圍也將呈指數(shù)級放大。

一次“繞過流程”的投毒發(fā)布

事情的起點，是當天 10:52（UTC）發(fā)布到 PyPI 上的一個新版本：litellm 1.82.8。隨后 FutureSearch 團隊很快確認，1.82.7 版本也同樣受到了污染。

表面上，這只是一次普通的版本更新。但很快有人發(fā)現(xiàn)不對勁：PyPI 上出現(xiàn)了新版本，GitHub 倉庫卻沒有任何對應(yīng)的 release 或 tag。顯然，該版本的發(fā)布應(yīng)該是繞過了正常流程。

更關(guān)鍵的是，更新之后的版本中夾帶了一個不起眼卻極其危險的文件——.pth 文件。

對于不熟悉 Python 機制的人來說，這里有個關(guān)鍵點：.pth 文件可以在 Python 解釋器每次啟動時自動執(zhí)行代碼。也就是說，只要安裝了這個版本：即使你沒有主動調(diào)用 LiteLLM，惡意代碼也會在后臺悄悄運行。

幸運“烏龍”：攻擊代碼出了“低級Bug”

這次的惡意攻擊之所以被快速發(fā)現(xiàn)，并不是因為防御做得有多好，而是——攻擊代碼自己出了 Bug。

最早發(fā)現(xiàn)異常的是 FutureSearch 工程師 Callum McMahon。當時，他正在測試一個 Cursor MCP 插件，卻遇到了一個詭異現(xiàn)象：Python 一啟動，機器直接卡死（內(nèi)存被耗盡）。

他排查后發(fā)現(xiàn)：

● 問題來源于新安裝的 LiteLLM 包

● 存在一個 34KB 的 .pth 文件

● 文件內(nèi)容經(jīng)過雙重 base64 編碼

正如上文所說，由于 .pth 文件在每次 Python 啟動時都會執(zhí)行，而惡意代碼會啟動一個 Python 子進程，子進程再次觸發(fā) .pth，無限遞歸之后，最終形成一個指數(shù)級的“fork 炸彈”。

由此導(dǎo)致的結(jié)果非常直接：內(nèi)存占用飆升、系統(tǒng)迅速卡死，最終機器直接崩潰。

本來，這只是攻擊代碼中的一個“低級 Bug”，但正是這個 Bug 引起了工程師的警覺，才讓這次攻擊浮出水面——正如 Andrej Karpathy 所說：

“如果攻擊者不是用 Vibe Code 寫代碼（而出了 Bug），這次攻擊很可能會隱藏幾天甚至幾周?！?/blockquote>

一旦中招，你的開發(fā)環(huán)境基本“全盤透明”

據(jù) FutureSearch 介紹，這次攻擊的惡意代碼設(shè)計得相當“專業(yè)”，主要分為三個階段：信息收集、數(shù)據(jù)外傳和橫向擴散。

首先，它會掃描開發(fā)者機器上的敏感信息，包括：SSH 私鑰和配置、.env 文件中的各種 API Key、AWS、GCP、Azure 等云平臺憑證、Kubernetes 配置、Git 憑證、數(shù)據(jù)庫密碼、Shell 歷史記錄，甚至加密貨幣錢包文件。同時，它還會主動讀取環(huán)境變量，并訪問云環(huán)境中的元數(shù)據(jù)接口，進一步挖掘可用權(quán)限。

接下來，這些收集到的數(shù)據(jù)不會明文發(fā)送，而是經(jīng)過精心處理：

使用 AES-256-CBC 加密數(shù)據(jù)，再用 4096 位 RSA 公鑰加密會話密鑰，打包成 tar 文件并發(fā)送到 https://models.litellm.cloud/——這個域名看似“官方”，實際上并不屬于 LiteLLM 的基礎(chǔ)設(shè)施。

其實到這一步為止，問題已經(jīng)足夠嚴重了，但真正危險的是它的第三步：從“偷數(shù)據(jù)”到“接管集群”。

一旦檢測到當前環(huán)境中存在 Kubernetes 配置，這段惡意代碼會嘗試進一步擴散：

● 讀取整個集群中所有 namespace 的 secrets

● 在每個節(jié)點上創(chuàng)建特權(quán) Pod

● 掛載宿主機文件系統(tǒng)

隨后，它會在系統(tǒng)中寫入后門：/root/.config/sysmon/sysmon.py，并注冊 systemd 服務(wù)，實現(xiàn)持久化控制——這意味著：攻擊者不僅能讀取你的數(shù)據(jù)，還能長期“接管”你的整個集群，且悄無聲息。

如果這件事只影響 LiteLLM 用戶，問題還不算最糟。但現(xiàn)實是，影響范圍遠不止如此：如上文所說，LiteLLM 自身的月下載量已高達 9700 萬次，同時它又被大量 AI 項目作為底層依賴使用，因此下載這些項目同樣也會受到影響。

如 Karpathy 提到的 DSPy 等框架，都間接依賴 LiteLLM。所以，哪怕你只是執(zhí)行了一次 pip install dspy，也可能被“順帶感染”——這種通過供應(yīng)鏈傳播的攻擊，就像病毒一樣，會在整個軟件生態(tài)中擴散。

所幸，根據(jù)目前披露的信息，被投毒的版本在 PyPI 上存在的時間不到一小時，隨后被緊急下架。安全團隊也迅速介入，社區(qū)開始排查和修復(fù)影響范圍。到目前為止，沒有大規(guī)模用戶數(shù)據(jù)泄露的報告，可以說是不幸中的萬幸。

如果你中招了，該怎么辦？

如果你在 3 月 24 日之后安裝過 LiteLLM，請立即執(zhí)行以下操作：

1. 檢查版本：

pip show litellm

重點關(guān)注是否為 1.82.7 和 1.82.8 版本。

2. 清理環(huán)境：

rm -rf ~/.cache/uv

并刪除相關(guān)虛擬環(huán)境中的 LiteLLM。

3. 檢查后門

重點查看：

~/.config/sysmon/sysmon.py

~/.config/systemd/user/sysmon.service

Kubernetes 用戶需檢查異常 Pod（如 node-setup-*）。

4. 最關(guān)鍵的一點：立即更換所有憑證

記住一個默認原則：只要安裝過惡意 LiteLLM 版本的設(shè)備，所有憑證一律視為已泄露。其中包括：SSH Key、云服務(wù)密鑰、Kubernetes 配置、API Key 和數(shù)據(jù)庫密碼。

關(guān)注此事的 Karpathy，在 X 上提到了一句話：

“像這樣的供應(yīng)鏈攻擊，是現(xiàn)代軟件中最可怕的事情之一?！?/blockquote>

原因在于，今天的軟件開發(fā)，已經(jīng)建立在龐大的依賴體系之上：一個項目可能依賴幾十甚至上百個庫，每個庫又有自己的依賴，最終形成一個復(fù)雜的“依賴樹”。攻擊者只需要在這棵樹的某一個角落“投毒”，就可能影響到無數(shù)的下游項目。

而更可怕的是，一旦憑證被竊取，攻擊者就可以登錄云服務(wù)，接管代碼倉庫，并發(fā)布新的惡意版本，從而形成一個不斷擴散的攻擊鏈條。

一直以來，傳統(tǒng)的軟件工程都在提倡復(fù)用、模塊化、不要重復(fù)造輪子，盡量使用成熟的依賴庫?？山?jīng)過此事，這個理念正在被重新審視。Karpathy 也基于此提出了一個頗具爭議的觀點：

在一些簡單場景下，他更傾向于使用大模型直接生成代碼，而不是引入新的依賴。

本質(zhì)上來說，這是在用“可控的代碼生成”，來替代“不可控的外部依賴”——聽起來可能有些“反直覺”，但放在安全視角下，卻并非沒有道理。

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

https://x.com/karpathy/status/2036487306585268612

【活動分享】"48 小時，與 50+ 位大廠技術(shù)決策者，共探 AI 落地真路徑。"由 CSDN&奇點智能研究院聯(lián)合舉辦的「全球機器學(xué)習技術(shù)大會」正式升級為「奇點智能技術(shù)大會」。2026 奇點智能技術(shù)大會將于 4 月 17-18 日在上海環(huán)球港凱悅酒店正式召開，大會聚焦大模型技術(shù)演進、智能體系統(tǒng)工程、OpenClaw 生態(tài)實踐及 AI 行業(yè)落地等十二大專題板塊，特邀來自BAT、京東、微軟、小紅書、美團等頭部企業(yè)的 50+ 位技術(shù)決策者分享實戰(zhàn)案例。旨在幫助技術(shù)管理者與一線 AI 落地人員規(guī)避選型風險、降低試錯成本、獲取可復(fù)用的工程方法論，真正實現(xiàn) AI 技術(shù)的規(guī)模化落地與商業(yè)價值轉(zhuǎn)化。這不僅是一場技術(shù)的盛宴，更是決策者把握 2026 AI 拐點的戰(zhàn)略機會。