突發｜立即檢查你的Python庫！LiteLLM被投毒，Karpathy警告

編輯｜冷貓

這是一件極其嚴肅的軟件安全事件。

今天，Karpathy 發長推文警告全部開發者注意，GitHub 超過 4 萬星，月下載量達 9700 萬次的 Python 庫LiteLLM 在 PyPI 上被投毒

首先提請各位開發者檢查自己的 LiteLLM 版本 ，含有惡意代碼的版本號為 1.82.7 和 1.82.8，如果中招請盡快重新安裝。

目前，被攻破的版本已被撤回，PyPI 隔離措施已解除。包維護人員正在處理后續影響。

這一事件影響非常廣泛，可以被稱之為教科書級別的供應鏈攻擊。

熟悉 Python 的朋友們一定知道 PyPI 上軟件包的重要性，沒有 pip install 命令我們將寸步難行。

但這次 LiteLLM 的問題正出在 PyPI 軟件包上。簡單的 pip install litellm 就足以竊取你的 SSH 密鑰、AWS/GCP/Azure 憑證、Kubernetes 配置、git 憑證、環境變量（包括你所有的 API 密鑰）、shell 歷史記錄、加密貨幣錢包、SSL 私鑰、CI/CD 機密以及數據庫密碼。

除去 LiteLLM 本身每月的 9700 萬次下載之外，更嚴重的是以 LiteLLM 為基礎依賴的其他項目和軟件包同樣也會遭受投毒的攻擊

Karpathy 在推文中寫道：「像這樣的供應鏈攻擊基本上是現代軟件中最令人恐懼的事情。每當你安裝任何一個依賴項時，你都可能從其龐大的依賴樹深處引入一個被投毒的包。對于那些擁有海量依賴庫的大型項目來說，這種風險尤其高。而每次攻擊中失竊的憑證，又會被用來接管更多的賬戶，進而污染更多的軟件包。」

該事件首次由 FutureSearch 報告給 PyPI，FutureSearch 就事件始末詳情發布了博客。

• 博客鏈接：https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

根據 FutureSearch 提供的信息，該攻擊負載分為三個階段運行：

• 信息搜刮 (Collection)
• 一個 Python 腳本會從主機中搜刮敏感文件，包括：SSH 私鑰和配置、.env 文件、AWS / GCP / Azure 憑證、Kubernetes 配置、數據庫密碼、.gitconfig、shell 歷史記錄、加密貨幣錢包文件，以及任何匹配常見機密模式的文件。它還會運行令來導出環境變量，并查詢云端元數據端點（如 IMDS、容器憑證）。
• 數據外傳 (Exfiltration)
• 收集到的數據會使用硬編碼的4096 位 RSA 公鑰，通過AES-256-CBC模式進行加密（生成隨機會話密鑰，再用 RSA 密鑰加密該密鑰）。數據被打包成 tar 歸檔文件，并通過 POST 請求發送到 https://models.litellm.cloud/ ——請注意，該域名并非 LiteLLM 官方基礎設施的一部分。
• 橫向移動與持久化
• Kubernetes 滲透：如果存在 K8s 服務賬戶令牌，惡意軟件會讀取所有命名空間下的所有集群機密信息，并嘗試在每個節點的 kube-system 中創建一個具有特權的 alpine:latest Pod。
• 后門植入：每個惡意 Pod 都會掛載宿主機文件系統，并在 /root/.config/sysmon/sysmon.py 處安裝持久化后門，并配合一個 systemd 用戶服務運行。
• 本地持久化：在本地機器上，它會通過 ~/.config/sysmon/sysmon.py 嘗試相同的持久化手段。

這件事引發了馬斯克的關注，「Caveat emptor」意味著提醒大家注意承擔風險。

這個帶有惡意代碼的軟件版本被發現的過程非常具有戲劇性，其根源來自于攻擊代碼中的 bug。

開發者 Callum McMahon 在 Cursor 內部運行的 MCP 插件將此包作為傳遞依賴項拉取時發現了這個問題。

.pth 啟動器通過 subprocess.Popen 啟動一個子 Python 進程，但由于 .pth 文件在每次解釋器啟動時都會觸發，子進程會重新觸發相同的 .pth —— 這會創建一個指數級分叉炸彈，導致機器因內存爆炸而崩潰。這個分叉炸彈實際上是惡意軟件中的一個漏洞。

Karpathy 也稱，如果攻擊者編程能力更強，可能幾周都不會有人注意到

據說，惡意代碼的開發者采用了 AI 編碼導致出現 Bug，有開發者表示「vibe coding」這次救了我們。

英偉達機器人部門總監及杰出科學家 Jim Fan 也表達了關切。

他說，過去的身份盜竊與代理能做的事相比簡直不值一提。發送憑證太明顯了，新手也能做。

人們其實很少需要 LiteLLM 支持的所有 API，倒不如根據需求隨手構建一個自定義的功能軟件。這與 Karpathy 的想法不謀而合。

Karpathy 表示其更傾向于在功能足夠簡單且可行的情況下，利用 LLM 把功能「薅」過來自己實現一遍。

在「不經思考就瘋狂點允許」和「危險地跳過權限」之間，幾乎沒有中間地帶。利爪（Claws）必須被關進殼（Shells）里。而且可能是多層嵌套的殼。

但大家都在質疑，這樣一份帶有惡意代碼的軟件包是如何順利通過代碼審查，從而實現廣泛的推送發布的呢？

我們查閱了來自 snyk 的事故詳細報告，發現攻擊者并沒有通過正常的 GitHub 工作流提交惡意版本。

相反，攻擊者使用了一個被竊取的 PyPI 發布令牌，直接把被投毒的包上傳到了 PyPI，完全繞過了代碼審查。與此同時，官方 GitHub 倉庫本身仍然是干凈的，沒有對應的 tag 或 commit。

• 相關報告鏈接：https://snyk.io/articles/poisoned-security-scanner-backdooring-litellm/

太陽底下無新事，Sebastian Raschka 發現此次攻擊和數年前的 ctx 包事件非常相似。

雖然這種方案并非無懈可擊，但他認為規避此類風險的最佳路徑如下：

1. 獲取源代碼快照：直接從 GitHub 等可信源下載該軟件包特定版本的源代碼快照。
2. 安全審計：對其進行深度審計。傳統方式依賴人工核查，但現在可以借助LLM Agent輔助完成。
3. 源代碼內置：將審計過的源代碼直接整合進你自己的庫中。由于大多數開源協議本身就是相互兼容的，通常只需保留原協議文件并注明出處即可。

最后，請大家根據 FutureSearch 的提示，檢查自己的設備，并做以下操作來避免危險。

1. 檢查是否受影響 如果你在 2026 年 3 月 24 日或之后安裝或升級了 LiteLLM，請檢查版本是否為 1.82.8：
運行 pip show litellm。檢查 uv 緩存（搜索～/.cache/uv -name "litellm_init.pth"）。檢查 CI/CD 中的虛擬環境。
2. 移除包并清理緩存 從所有受影響的環境中刪除 LiteLLM 1.82.8。必須清理包管理器緩存（執行 rm -rf ~/.cache/uv 或 pip cache purge），以防止從本地緩存的 wheel 文件重新安裝毒包。
3. 檢查持久化痕跡 排查是否存在以下文件：~/.config/sysmon/sysmon.py ~/.config/systemd/user/sysmon.service 如果運行在 Kubernetes 中，審計 kube-system 命名空間，檢查是否存在匹配 node-setup-* 模式的 Pod，并審查集群機密（secrets）是否存在未經授權的訪問記錄。
4. 重置憑證（最關鍵）必須假設受影響機器上的所有憑證都已泄露，請立即輪換：
SSH 密鑰。云服務商憑證（GCP ADC、AWS 訪問密鑰、Azure 令牌）。Kubernetes 配置。.env 文件中的所有 API 密鑰。數據庫密碼。