創泓科技股份有限公司
    CLOSE
  • 關於創泓
  • 最新公告
  • 產品介紹
  • 解決方案
  • 活動資訊
  • 投資人專區
  • 軟體標
  • 課程報名
  • 資料下載
  • Copyright © 2017 MIRACLE

LiteLLM 遭投毒事件揭示:Sonatype Repository Firewall 於攻擊發生數秒內自動攔截惡意套件,客戶零影響

  • 首頁
  • 最新公告

Sonatype Repository Firewall 於攻擊發生數秒內自動攔截惡意套件,客戶零影響

Vibe Coding 時代的供應鏈危機:
LiteLLM 遭投毒事件揭示 AI 開發工具的安全盲區

【2026 年 3 月 25 日,台北訊】2026 年 3 月 24 日,廣受全球開發者使用的 Python AI 套件 LiteLLM(月下載量超過 9,500 萬次)在 PyPI 套件庫遭到供應鏈攻擊。攻擊者 TeamPCP 利用先前入侵 Aqua Security Trivy 安全掃描器時竊取的 CI/CD 憑證,繞過正式發布流程,直接上傳含有三階段憑證竊取惡意程式的 v1.82.7 與 v1.82.8 至 PyPI。此次事件的第一位發現者,正是一名 Cursor IDE 使用者——他從未主動安裝 LiteLLM,卻因 MCP plugin 的 transitive dependency(間接依賴)而在不知情的狀況下引入了惡意版本。

面對 Vibe Coding 風潮席捲開發社群,AI 輔助工具正以前所未有的速度替開發者自動化安裝套件與管理依賴。然而,這起事件凸顯了一個關鍵警訊:當開發者將依賴決策交給 AI,誰來把關這些 AI 幫你裝的套件是否安全?

事件概要

LiteLLM 是一個開源 Python 函式庫,提供統一 API 介面整合超過 100 家大型語言模型(LLM)供應商,包括 OpenAI、Anthropic、Google 等。根據 Wiz 研究,LiteLLM 存在於全球 36% 的雲端環境中,其在 AI 開發生態系的核心地位,使其成為極具價值的供應鏈攻擊目標。

此次攻擊是 TeamPCP 威脅組織系列行動的第 9 階段,展現了「連鎖憑證竊取」的攻擊模式——每一個被入侵的環境都會產生進入下一個目標的鑰匙:

Wiz 研究員將此描述為「開源供應鏈的連鎖崩潰」——Trivy 被入侵,導致 LiteLLM 被入侵,數萬個環境的憑證落入攻擊者手中,而這些憑證又將成為下一波攻擊的入口。


事件來源:

https://futuresearch.ai/blog/litellm-pypi-supply-chain-attack/

https://docs.litellm.ai/blog/security-update-march-2026

Vibe Coding 時代的新型攻擊面

此次事件最值得關注的面向,並非攻擊的技術複雜度,而是受害路徑。第一位發現此攻擊的使用者,是在 Cursor IDE 中透過 MCP plugin 間接引入了 LiteLLM。他從未執行 pip install litellm,卻已在不知情的狀況下遭到入侵。

這正是 Vibe Coding 浪潮下的典型場景:開發者信任 AI 工具替他們處理依賴管理,不會逐一檢查 dependency tree 中的每個間接套件。然而,這起事件證明了——

AI 讓開發速度飛快,但同時也讓開發者對供應鏈的掌控力降到了前所未有的低點。

更令人擔憂的是,v1.82.8 版本使用了 Python 的 .pth 檔案機制。這種檔案會在 Python 直譯器啟動時自動執行,意味著只要環境中安裝了該惡意版本,任何 Python 程式啟動都會觸發惡意程式碼——即使從未 import litellm。在共享開發環境中,這等同於每一個 Python 腳本都成為攻擊的觸發器。

惡意程式三階段攻擊流程

一旦觸發,惡意程式將依序執行三個階段:

第一階段:憑證收割。系統性收集主機上的 SSH 金鑰、雲端供應商憑證(AWS、GCP、Azure)、Kubernetes secrets、環境變數檔(.env)、資料庫密碼、Docker 設定檔,以及加密貨幣錢包。

第二階段:橫向移動。偵測 Kubernetes service account token 後,讀取所有 namespace 的 cluster secrets,並在每個節點的 kube-system 中建立特權 Pod,掛載主機檔案系統,將攻擊範圍擴展至整個叢集。

第三階段:持久化。安裝 systemd backdoor 與持久化腳本,持續輪詢攻擊者 C2 伺服器以取得進一步指令,確保即使惡意套件被移除,後門仍然存在。

所有竊取的資料使用 RSA-4096 公鑰搭配 AES-256-CBC 加密,打包後 POST 至攻擊者控制的假冒域名。

Sonatype Repository Firewall 於數秒內自動攔截

面對此次攻擊,Sonatype 的自動化惡意套件偵測系統在惡意版本發布後數秒內即完成識別與封鎖(追蹤編號:sonatype-2026-001357)。所有使用 Sonatype Repository Firewall 的企業客戶在此事件中完全未受影響。

Sonatype Repository Firewall 是業界唯一專為開源軟體供應鏈設計的自動化惡意套件防護閘道,透過三層防護架構保護企業開發環境:

關鍵在於,Repository Firewall 的防護機制不依賴已知弱點資料庫(CVE),而是透過 AI 行為分析引擎主動識別惡意行為模式。這使其能夠偵測並封鎖傳統 SCA 工具無法捕捉的蓄意惡意套件——正如此次 LiteLLM 事件所展示的。

傳統防護手段為何失效

版本固定(Version Pinning):僅在已知安全版本存在時有效。此次攻擊發生在新版本發布的瞬間,固定版本無法防範尚未被識別的惡意新版本。

程式碼審查:攻擊者完全繞過 GitHub 程式碼審查流程,利用竊取的 PyPI token 直接上傳至套件庫。GitHub repository 上沒有對應的 tag 或 release。

CVE 追蹤與傳統弱點掃描:惡意套件通常不會被分配 CVE 編號,傳統弱點掃描器無法偵測蓄意植入的惡意程式碼。

手動稽核:以 LiteLLM 每日 340 萬次的下載量,惡意版本存活的 2-3 小時內可能已有大量環境受到影響。


 建議行動 

已受影響的組織

  • 確認環境中是否安裝了 LiteLLM v1.82.7 或 v1.82.8(執行 pip show litellm 檢查版本)。
  • 檢查系統中的入侵指標(IoC):litellm_init.pth 檔案、~/.config/sysmon/ 目錄、kube-system 中異常的 node-setup-* Pod。
  • 假設受影響系統上的所有憑證已被洩露,立即進行全面的 credential rotation,包括 SSH 金鑰、雲端存取權杖、資料庫密碼與 API 金鑰。
  • 考慮從已知乾淨狀態重建受影響的系統與環境。


長期防護建議

  • 部署 Sonatype Repository Firewall,在開源套件進入開發環境前自動攔截已知與未知的惡意元件。
  • 搭配 Sonatype Lifecycle 實施持續性的軟體組成分析(SCA),建立涵蓋直接與間接依賴的完整 SBOM。
  • 於 CI/CD 管線中強制所有依賴固定版本,並與上游原始碼進行比對驗證。
  • 特別針對 AI 輔助開發工具(Cursor、Windsurf、Copilot 等)建立額外的依賴審查機制,確保 AI 自動安裝的間接依賴同樣受到管控。
  • 採用 PyPI Trusted Publishers 等安全發布機制,降低對靜態 API token 的依賴。
 

關於 Sonatype

Sonatype 是全球領先的軟體供應鏈安全公司,旗下產品包括 Nexus Repository(全球最廣泛使用的開源套件管理平台)、Repository Firewall(業界唯一的開源惡意套件自動防護閘道)、Lifecycle / IQ Server(企業級軟體組成分析平台)、以及 SBOM Manager。Sonatype 至今已識別並封鎖超過 101,000 個惡意開源套件,保護全球數千家企業的軟體供應鏈安全。

關於創泓科技 UNIFORCE Technology

創泓科技 UNIFORCE Technology 為 Sonatype 在台灣的授權合作夥伴,專注於應用程式安全(Application Security)領域,提供涵蓋 SAST、SCA、SBOM 管理、開源合規、以及軟體供應鏈安全的完整解決方案。代理產品包括 Sonatype、Checkmarx與JScrambler 。

回上層
創泓科技股份有限公司
TEL
:(02)2658-3077
FAX:(02)2658-3097
ADD:台北市內湖區洲子街77號10樓
產品部門 代表號:206
業務部門 代表號:213
工程部門 代表號:810
  • 關於創泓
  • 型錄下載
  • 聯合聲明
歡迎訂閱電子報
Designed by 米洛網頁設計
採用全球最先進SSL 256bit 傳輸加密機制
建議使用Chrome、Firefox、Safari最新版本瀏覽
聯絡我們