1. 首頁 > 生活百科 > >

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

oppo find x9

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

文章圖片

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

文章圖片

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

文章圖片

突發｜立即檢查你的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 包事件非常相似 。
雖然這種方案并非無懈可擊 ， 但他認為規避此類風險的最佳路徑如下：
獲取源代碼快照：直接從 GitHub 等可信源下載該軟件包特定版本的源代碼快照 。安全審計：對其進行深度審計 。 傳統方式依賴人工核查 ， 但現在可以借助 LLM Agent 輔助完成 。源代碼內置：將審計過的源代碼直接整合進你自己的庫中 。 由于大多數開源協議本身就是相互兼容的 ， 通常只需保留原協議文件并注明出處即可 。最后 ， 請大家根據 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. 重置憑證（最關鍵）必須假設受影響機器上的所有憑證都已泄露 ， 請立即輪換：
【突發｜立即檢查你的Python庫！LiteLLM被投毒，Karpathy警告】SSH 密鑰 。 云服務商憑證（GCP ADC、AWS 訪問密鑰、Azure 令牌） 。 Kubernetes 配置 。 .env 文件中的所有 API 密鑰 。 數據庫密碼 。

    推薦閱讀