月下載9700萬的Python庫被“投毒”！Karpathy緊急警告：一行pip install，敏感數據全泄

整理 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

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

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

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

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

一次“繞過流程”的投毒發布

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

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

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

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

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

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

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

他排查后發現：

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

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

● 文件內容經過雙重 base64 編碼

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

由此導致的結果非常直接：內存占用飆升、系統迅速卡死，最終機器直接崩潰。

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

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

一旦中招，你的開發環境基本“全盤透明”

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

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

接下來，這些收集到的數據不會明文發送，而是經過精心處理：

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

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

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

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

● 在每個節點上創建特權 Pod

● 掛載宿主機文件系統

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

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

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

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

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

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

1. 檢查版本：

pip show litellm

重點關注是否為 1.82.7 和 1.82.8 版本。

2. 清理環境：

rm -rf ~/.cache/uv

并刪除相關虛擬環境中的 LiteLLM。

3. 檢查后門

重點查看：

~/.config/sysmon/sysmon.py

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

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

4. 最關鍵的一點：立即更換所有憑證

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

關注此事的 Karpathy，在 X 上提到了一句話：

“像這樣的供應鏈攻擊，是現代軟件中最可怕的事情之一。”

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

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

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

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

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

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

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

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