文章 發布於 AIA: 2026年4月18日

LiteLLM 後續效應：被植入惡意程式的 AI 依賴套件，如何波及 Mercor

Mercor 已證實自己受到 LiteLLM 供應鏈事件波及；這起事件的關鍵，是被植入惡意程式的 PyPI 套件倉庫版本會偷走安裝主機上的憑證。另一方面，Lapsus$ 對外宣稱拿到大量 Mercor 資料，但截至報導發布時，完整資料集內容仍未被獨立驗證；不過，防禦重點已經很清楚了：AI 依賴套件必須做版本釘選、事前審查、低信任隔離安裝，並假設它在安裝或執行時看得到的每一份密鑰都可能被偷走。

AI Supply ChainCredential TheftOpen Source SecurityAI Infrastructure
7 項對應的 AIDEFEND 防禦手法
來源: Mercor confirms cyberattack as hackers claim 4TB of critical data in possession 
作者 Vilius Petkauskas · 原文發布: 2026年4月1日

威脅分析

  • 最一開始失守的，不是 Mercor 自己的程式，而是上游套件信任鏈。 LiteLLM 的 1.82.7 和 1.82.8 被攻擊者發到 PyPI，而且不是走官方 GitHub 發版流程，而是在維護者帳號遭挾持後直接上傳。
  • 這不是一般會當機的壞版本，而是專門偷憑證的惡意套件。 LiteLLM 官方 GitHub 事件說明寫得很清楚：惡意程式會收集 SSH 金鑰、環境變數裡的密鑰、雲端和 Kubernetes 憑證、資料庫密碼，以及 CI 設定。
  • 1.82.8 的危險之處還不只如此。 它多塞了一個 .pth 啟動檔（Python 啟動時會自動載入的檔案），所以就算你沒有明確 import LiteLLM，惡意程式也可能在 Python 啟動時被帶起來。
  • Mercor 已證實自己受影響，但 extortion 團體對外喊的資料量，仍然只能當成未完全證實的主張。 Cybernews 引述 Lapsus$ 稱其拿到原始碼、資料庫和 VPN 相關資料；不過在文章發布當下，完整資料集內容還沒有被獨立確認。
  • 這正是 AI 依賴套件風險特別麻煩的地方。 像 LiteLLM 這類函式庫，通常靠近模型金鑰、雲端憑證、CI runner，還有內部資料路徑；一個被下毒的套件，就可能把開發工具鏈直接接到企業級資安事件上。

適用的 7 項 AIDEFEND 防禦手法

AID-H-024
Publisher Integrity & Workflow Hardening
極高
這次惡意 LiteLLM 版本，是繞過官方 GitHub CI 流程直接上傳到 PyPI。企業內部鏡像站和安全審查流程，應優先信任那些能證明自己來自核准 CI workflow 的套件，而不是只因為名稱看起來是官方套件就直接接受。
AID-H-003.001
Software Dependency & Package Security
極高
LiteLLM 這種 AI 關鍵依賴套件，必須做精準版本釘選和雜湊值驗證，不能讓正式流程直接相信公開 PyPI 上當下看到的最新版本。若 Mercor 當時只允許經過核准、位元組內容固定不變的內部鏡像套件進線，這次被下毒的版本會比較容易被擋下來。
AID-H-023.002
Proactive Package Vetting
高
像 LiteLLM 這種 AI 閘道函式庫的升級，不能只看版本號就直接裝。套件信譽分析、發版路徑比對、異常版本偵測，以及對「突然出現的非正常發版」加上政策關卡，才能在開發者或 CI 吃進套件之前先把可疑更新攔下來。
AID-H-023.001
Sandboxed Dependency Installation
高
套件安裝和 image build 階段，應該在短生命週期、強隔離的環境裡進行，而且裡面不該放長效雲端金鑰、VPN 憑證，或正式環境的 .env。惡意依賴套件就算真的執行了，也應該只撞上一個幾乎沒有可偷資料的死胡同環境。
AID-H-004.002
Service & API Authentication
高
就算真的裝到了惡意套件，被偷走的憑證也不該自動變成原始碼、資料庫、VPN、雲端控制面的通行證。把服務帳號改成短效期、按工作負載綁定、權限切到最小，能大幅縮小開發主機或 CI 主機被打下來後的後續傷害。
AID-E-001.001
Foundational Credential Management
高
一旦遭污染的 LiteLLM 版本可能已經收走 secrets，收斂影響範圍就不能只移除套件。AI 服務供應商金鑰、雲端權杖、CI secrets、資料庫密碼、VPN 存取權和服務帳號資料，都應該依照影響範圍證據撤銷或輪替。
AID-M-001.002
AI System Dependency Mapping
中
團隊需要知道到底哪些應用、notebook、container、CI runner 用過 LiteLLM。只有把相依關係圖畫清楚，生態系層級的公告才會變成一份真的能拿來輪替密鑰、隔離主機、縮小 blast radius 的事件處理清單。

身為資安防禦者，我們應該這麼做

  • 先搜尋 lockfile、container image、build cache 和 site-packages，找出是否出現過 LiteLLM 1.82.7、1.82.8，以及惡意的 litellm_init.pth。只要有，就先隔離該主機。
  • 把 2026 年 3 月 24 日之後曾經出現在受影響主機上的所有憑證都輪替掉，包括 AI 服務供應商金鑰、雲端和 Kubernetes 憑證、CI token、SSH 金鑰、資料庫密碼，以及 VPN / TailScale 存取權。
  • 對 AI 關鍵依賴套件停止直接拉公開 PyPI。改成要求精準版本釘選、雜湊值驗證，並只透過內部鏡像站或核准的 artifact cache 發佈。
  • 把依賴套件安裝和 build 流程移進短生命週期、低信任的隔離環境，並加上對外連線限制。會跑 pip install 的地方，不該同時放著長效密鑰。
  • 整理每一個使用 LiteLLM 的應用、notebook、container 和 runner 清單，然後回頭檢查自 2026 年 3 月 24 日以來，是否有異常的 code repo、資料庫、VPN 或雲端存取紀錄。

結論

Mercor 這起事件，是目前最清楚的一個下游案例，說明 LiteLLM 事件不是單純的開源維護者事故，而是真能一路打進企業的 AI 供應鏈攻擊路徑。被信任的是套件名稱，真正失守的是安裝面看到的所有密鑰。AIDEFEND  在依賴套件安全、安裝隔離、相依關係盤點，以及憑證權限收斂這幾塊都對得上；營運上的核心教訓是：AI 函式庫要當成特權供應鏈輸入來管，不能只把它當成一般開發便利套件。