實際事件 發布於 AIA: 2026年4月18日

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

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

Malicious PackagesCredential TheftSupply Chain DefenseAI Supply ChainOpen Source Security
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-023
Publisher Integrity & Workflow Hardening
極高
這次惡意 LiteLLM 版本，是繞過官方 GitHub CI 流程直接上傳到 PyPI。企業內部鏡像站和安全審查流程，應優先信任那些能證明自己來自核准 CI workflow 的套件，而不是只因為名稱看起來是官方套件就直接接受。
AID-H-003.001
Software Dependency & Package Security
極高
LiteLLM 這種 AI 關鍵依賴套件，必須做精準版本釘選和雜湊值驗證，不能讓正式流程直接相信公開 PyPI 上當下看到的最新版本。若 Mercor 當時只允許經過核准、位元組內容固定不變的內部鏡像套件進線，這次遭投毒的版本會比較容易被擋下來。
AID-H-022.002
Pre-Merge Dependency Change Risk Review
高
LiteLLM 這類 AI 閘道函式庫只要要升級，合併前就要針對指定版本、來源與 lockfile 差異，檢查漏洞、授權條款、維護者與來源儲存庫信譽、版本來源、安裝腳本差異，以及套件名稱是否有錯字或相似字元。突然出現的非正常版本、維護者或儲存庫異動、新增生命週期腳本，或任何一項檢查無法完成，都要擋下合併。至於實際建置時解析到的套件檔案是否遭撤回、有已知漏洞或雜湊不符，仍要由另一道建置檢查把關。
AID-H-022.001
Sandboxed Dependency Installation
高
套件安裝和 image build 階段，應該在短生命週期、強隔離的環境裡進行，而且裡面不該放長效雲端金鑰、VPN 憑證，或正式環境的 .env。惡意依賴套件就算真的執行了，也應該只撞上一個幾乎沒有可偷資料的死胡同環境。
AID-H-004.002
Service & API Authentication
高
CI job、應用程式、服務與其他非人類呼叫端應使用不同的 workload identity、短效且綁定 audience 的憑證與 route binding，讓某台主機被偷走的 secret 不能不分服務地通過原始碼、資料庫、VPN 與雲端控制面的 authentication。人類開發者存取由 AID-H-004.001 負責；資源 authorization 與事件期間的 credential eviction 仍由其他控制負責。
AID-E-001.001
Root & Long-Lived Credential Object Eviction
高
一旦遭污染的 LiteLLM 版本可能已收走 secrets，不能只移除套件；還要依影響範圍證據撤銷或輪替確切的 root 與長效 credential object，包括 AI 供應商 API key、cloud access key、CI client secret、資料庫密碼、VPN credential、SSH key 與長效服務憑證。已簽發的 access token 或 session 由 AID-E-001.002 處理。
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 函式庫要當成特權供應鏈輸入來管，不能只把它當成一般開發便利套件。