LiteLLM 供應鏈攻擊延燒　2,500 家企業、43.4 萬條 CI/CD 憑證外洩

編按：本文綜合整理自 Ars Technica、CloudSEK 研究報告、LiteLLM 官方安全公告、Trend Micro 技術分析，並加入 Siami 編輯部觀點與分析。

一場規模空前的供應鏈攻擊在八月曝光：威脅行為者 TeamPCP 透過污染開源 AI 路由套件 LiteLLM，在短短 40 分鐘內讓 43.4 萬條企業 CI/CD 流水線的雲端金鑰、SSH 金鑰、Kubernetes 權杖與 AI API 金鑰被全數收割；受害企業名單橫跨輝達（NVIDIA）、亞馬遜 AWS、三星、Salesforce、Cisco、Roche、Airbus、約翰迪爾（John Deere）、湯森路透（Thomson Reuters）、聯邦快遞（FedEx）、福斯（Volkswagen）、X Corp（推特）等 2,500 家以上。

事件總覽：40 分鐘的污染窗口

Ars Technica 引述 CloudSEK 與 Hudson Rock 兩家資安公司的獨立調查指出，被洩漏的資料量高達數 TB，內容包括：

• 雲端服務金鑰（AWS、GCP、Azure）
• 程式碼倉庫權杖（GitHub、GitLab PAT）
• SSH 私鑰
• Kubernetes service account token
• 套件發布憑證（PyPI、npm、Docker Hub）
• 環境變數與第三方 API 金鑰
• 多家 LLM 服務商的 API key

攻擊發生在 2026 年 3 月 24 日上午 10:39 UTC，TeamPCP 利用先前從 Trivy 安全掃描工具外洩的 PyPI 發布權杖，將兩個後門版本（litellm==1.82.7 與 1.82.8）上傳到 Python 官方套件庫。PyPI 在 40 分鐘後將套件下架，但在這段窗口內，所有透過 pip install litellm 拉取新版的使用者，記憶體中的憑證就已被掃光並加密外傳到 models.litellm.cloud（非官方域名）。

LiteLLM 月下載量約 9,700 萬次，是 Python 生態系最受歡迎的 LLM 代理層，被微軟、亞馬遜、Cisco、三星、Salesforce 等公司內部大量部署為「AI 統一閘道」，集中管理所有 LLM API 金鑰與雲端憑證。

「上游單一破口、影響數千家企業同時遭殃。40 分鐘的污染窗口換來 43 萬次部署、數百萬個秘密被收割。」——Hudson Rock 共同創辦人兼技術長 Alon Gal

攻擊時間軸：從 Trivy 開始的連環污染

Trend Micro 與 Armo 的分析顯示，這並非單一事件，而是 TeamPCP 從三月 19 日開始、橫跨五個生態系的系統性攻擊：

1. 3 月 19 日：入侵 Aqua Security 的 Trivy 漏洞掃描工具，偽造合法維護者 commit 植入後門。
2. 3 月 21 日：透過 Trivy 收割到的憑證，污染 Checkmarx KICS SAST 工具的 GitHub Actions 工作流。
3. 3 月 24 日 10:39 UTC：利用 Trivy 偷到的 LiteLLM PyPI 發布權杖，上傳 litellm==1.82.7 與 1.82.8。
4. 3 月 24 日 11:19 UTC：PyPI 將兩個版本下架。
5. 後續：TeamPCP 進一步攻擊 Docker Hub、NPM 與 Open VSX，擴大污染範圍。

關鍵技術細節：後門版本在 proxy_server.py 中插入惡意 payload，並透過 Python .pth 檔案在套件載入時自動執行；它會枚舉環境變數、~/.ssh/、~/.aws/、~/.kube/、~/.config/gh/ 等敏感路徑，將所有秘密加密後 POST 到 models.litellm.cloud。

為什麼這件事重要

這場攻擊揭示了 AI 開源生態系的三個結構性脆弱：

第一，「AI 統一閘道」本身成了高價值標靶。 企業為簡化 LLM API 管理，把所有雲端金鑰、模型 API key、Kubernetes token 集中到 LiteLLM 這類代理層。一旦代理層被攻破，等於把整個企業的 DevOps 信任鏈打包外送。Hudson Rock 統計，這場攻擊影響的 2,500 家企業橫跨 14 個產業，包括金融（倫敦證券交易所、湯森路）、醫療（Roche、Regeneron）、航太（Airbus US Space & Defense）、零售（Kroger、Roku）與公共服務（Deutsche Bahn、Vodafone）。

第二，安全掃描工具淪為攻擊跳板。 諷刺的是，LiteLLM 的 CI/CD 流程本身就跑了 Trivy 做漏洞掃描；攻擊者正是從這個「信任的掃描器」偷到 PyPI 發布權杖，再用它反過來污染 LiteLLM。「安全產品變成攻擊向量」並非新現象（XcodeGhost、CCleaner 事件都是前例），但這是第一次規模大到 43 萬條流水線同時遭殃。

第三，憑證輪替幾乎沒人做對。 Ars Technica 引用資安研究員 Beaumont 的田野調查：他致電受害企業，對方聲稱「早就 rotate 過了、沒事」；他依對方公布的負責任揭露政策實測——幾乎每一組憑證都還有效。這是一家美國前幾大的科技公司。

數據解讀與質疑

從 CloudSEK 與 Hudson Rock 公布的清單來看幾個值得追問的點：

• 43.4 萬條 CI/CD 流水線這個數字，包含哪些雲端資源？ CloudSEK 的原始報告承認「很多被洩漏的 pipeline 設定是通用的，看不出屬於哪家公司」，因此實際受害企業數可能遠超 2,500 家。
• 為什麼受害企業清單包含 NVIDIA、AWS、Samsung 卻沒有對應公告？ Ars Technica 引述 Hudson Rock 的說法是「這些企業的內部環境受 LiteLLM proxy 影響，但官方 LiteLLM Docker 映像（pin 依賴版本）不受波及」。換言之，多數受害企業的內部 AI 開發環境存在未受官方保護的部署路徑。
• 40 分鐘的污染窗口如何判定？ LiteLLM 官方公告寫「10:39 UTC 開始、約 40 分鐘後被 PyPI 隔離」；但攻擊者早在 Trivy 階段就已偷到發布權杖。從被入侵到主動上傳後門，中間至少有數天空檔。TeamPCP 不是「剛好拿到權杖」，而是「布局多日、刻意選在最小警覺時段投放」。
• SiriusXM 為何出現在受害清單？ Ars Technica 報導指出，名單中 @siriusxm.com 的 email 實際屬於衛星廣播商子公司 AdsWizz，非母公司本體。這顯示 CloudSEK 公開受害清單的歸屬判定仍有雜訊，企業若只對「網域名稱」做內部比對，可能會誤判或漏判。

修復建議與後續發展

Hudson Rock 與 CloudSEK 共同建議，任何在 3 月 24 日執行過 LiteLLM 的組織應：

• 立即輪替所有 LiteLLM 環境可存取的秘密：雲端金鑰、Kubernetes service account token、GitHub/GitLab PAT。
• 稽核 LiteLLM 1.82.7 與 1.82.8 的部署紀錄：PyPI 下載日誌、CI/CD log、容器映像清單。
• 輪替時同時撤銷 CI/CD 自動化權杖：CloudSEK 指出 Trivy 開發團隊曾「rotate 但未完全撤銷一個 automation token」，給了攻擊者近 20 天的 force-push 窗口。
• 啟用 egress 過濾：阻擋 models.litellm.cloud 與類似異常外連。

LiteLLM 官方已暫停新版本釋出、輪替所有維護者帳號，並在 3 月 27 日召開 town hall 向社群說明。BerriAI 團隊新增兩位維護者帳號（@krrish-berri-2 與 @ishaan-berri），但 TeamPCP 透過合法 commit 偽造取得信任的手法，意味著未來類似的供應鏈攻擊將更難靠「驗證帳號」防禦。

🚨 給 Siami 讀者的行動清單

如果你或你的公司在 3 月 24 日前後曾經跑過 LiteLLM（不限於後門版本），請立即執行：

1. 檢查 PyPI 下載紀錄：搜尋 litellm==1.82.7 與 litellm==1.82.8 的安裝事件。
2. 檢查 outbound 連線：對所有開發環境的 DNS 與 proxy log 比對 models.litellm.cloud。
3. 輪替所有「曾經放在 LiteLLM 環境變數中」的金鑰：包含雲端、LLM、容器 registry、版本控制平台。
4. 建立 CI/CD 憑證生命週期管理：自動化輪替、最小權限、定期審查。

「這場攻擊的關鍵教訓是：供應鏈已經進化到單一上游破口就能同時影響數千家企業。這規模迫使整個資安產業重新思考回應模式。」——Alon Gal, Hudson Rock CTO

攻擊沒結束，TeamPCP 還在活動。在 AI 開發工具全面整合進企業流程的今天，「信任一個開源套件」這件事的成本，正在快速上升。