整理 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

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

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

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

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

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

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

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

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

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

幸運(yùn)“烏龍”：攻擊代碼出了“低級(jí)Bug”

這次的惡意攻擊之所以被快速發(fā)現(xiàn)，并不是因?yàn)榉烙龅糜卸嗪?，而是——攻擊代碼自己出了 Bug。

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

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

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

● 存在一個(gè) 34KB 的 .pth 文件

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

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

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

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

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

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

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

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

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

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

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

一旦檢測(cè)到當(dāng)前環(huán)境中存在 Kubernetes 配置，這段惡意代碼會(huì)嘗試進(jìn)一步擴(kuò)散：

● 讀取整個(gè)集群中所有 namespace 的 secrets

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

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

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

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

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

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

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

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

1. 檢查版本：

pip show litellm

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

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

rm -rf ~/.cache/uv

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

3. 檢查后門

重點(diǎn)查看：

~/.config/sysmon/sysmon.py

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

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

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

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

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

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

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

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

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

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

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

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

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

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