編輯｜冷貓

這是一件極其嚴(yán)肅的軟件安全事件。

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

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

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

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

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

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

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

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

該事件首次由 FutureSearch 報告給 PyPI，F(xiàn)utureSearch 就事件始末詳情發(fā)布了博客。

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

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

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

這件事引發(fā)了馬斯克的關(guān)注，「Caveat emptor」意味著提醒大家注意承擔(dān)風(fēng)險。

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

開發(fā)者 Callum McMahon 在 Cursor 內(nèi)部運行的 MCP 插件將此包作為傳遞依賴項拉取時發(fā)現(xiàn)了這個問題。

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

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

據(jù)說，惡意代碼的開發(fā)者采用了 AI 編碼導(dǎo)致出現(xiàn) Bug，有開發(fā)者表示「vibe coding」這次救了我們。

英偉達(dá)機器人部門總監(jiān)及杰出科學(xué)家 Jim Fan 也表達(dá)了關(guān)切。

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

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

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

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

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

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

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

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

太陽底下無新事，Sebastian Raschka 發(fā)現(xiàn)此次攻擊和數(shù)年前的 ctx 包事件非常相似。

雖然這種方案并非無懈可擊，但他認(rèn)為規(guī)避此類風(fēng)險的最佳路徑如下：

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

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

1. 檢查是否受影響 如果你在 2026 年 3 月 24 日或之后安裝或升級了 LiteLLM，請檢查版本是否為 1.82.8：
運行 pip show litellm。檢查 uv 緩存（搜索～/.cache/uv -name "litellm_init.pth"）。檢查 CI/CD 中的虛擬環(huán)境。
2. 移除包并清理緩存 從所有受影響的環(huán)境中刪除 LiteLLM 1.82.8。必須清理包管理器緩存（執(zhí)行 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）是否存在未經(jīng)授權(quán)的訪問記錄。
4. 重置憑證（最關(guān)鍵）必須假設(shè)受影響機器上的所有憑證都已泄露，請立即輪換：
SSH 密鑰。云服務(wù)商憑證（GCP ADC、AWS 訪問密鑰、Azure 令牌）。Kubernetes 配置。.env 文件中的所有 API 密鑰。數(shù)據(jù)庫密碼。