--- schemaVersion: 1 slug: mp-257-20260406-zats-litellm-trivy-pypi-ai ticketId: MP-257 lang: zh-tw title: LiteLLM 連環攻擊全鏈解析 — 從 Trivy 到 PyPI，一場教科書級 AI 供應鏈核爆 summary: 威脅組織 TeamPCP 透過入侵 Aqua Security 的 Trivy CI/CD，在 LiteLLM 1.82.7–1.82.8 植入三階段惡意 payload，影響 36% 雲端環境與 Mercor AI 等數千組織，造成 TB 級 API 金鑰與雲端憑證外洩。這不是攻擊 AI 模型本身，而是攻擊連接模型與應用的工具層。 originalDate: 2026-03-31 translatedDate: 2026-04-06 source: "@zats on X" sourceUrl: https://x.com/zats/status/2039697433915981926 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-257-20260406-zats-litellm-trivy-pypi-ai status: published replacementTicketId: null replacementUrl: null --- # LiteLLM 連環攻擊全鏈解析 — 從 Trivy 到 PyPI，一場教科書級 AI 供應鏈核爆 > **來源:** [@zats on X](https://x.com/zats/status/2039697433915981926) ## 保全自己就是小偷 想像一下這個場景：一棟大樓的保全公司被壞人收買了。保全每天照常巡邏、照常簽到、照常跟住戶打招呼——但巡邏的時候順手把每一層的門鎖都換成壞人的版本。住戶完全不會察覺，因為保全的存在本身就代表「安全」。 2026 年 3 月 24 日，一個叫 TeamPCP 的攻擊組織就幹了一模一樣的事，只不過舞台換成了整個 AI 開源生態系。 > **Mogu 補個刀：** > > LiteLLM 是 AI 界的萬用轉接頭——一個 Python library，讓開發者用同一套 API 去呼叫 100+ 個 LLM provider（OpenAI、Anthropic、Google、Azure……）。Wiz 的報告說 36% 的雲端環境裡都裝了這玩意。三分之一。所以 TeamPCP 不是去搶銀行——他們直接把手伸進全國三分之一 ATM 機的鈔票匣裡。(╯°□°)╯ --- ## 「安全檢查員」本人就是內鬼 故事要從 Trivy 講起。Trivy 是 Aqua Security 做的開源漏洞掃描工具——專門檢查別人的程式碼有沒有問題的那種工具。LiteLLM 的 CI/CD pipeline 裡就用 Trivy 來守門：每次建置前先跑一輪安全掃描，乾淨才放行。 TeamPCP 沒有去碰 LiteLLM 的程式碼。他們去碰 Trivy 的 GitHub Actions workflow。 等等，這代表什麼？ 代表 LiteLLM 的安全檢查員已經被策反了。以後不管 LiteLLM 的建置環境裡被塞了什麼鬼東西，Trivy 都會含笑點頭：「沒問題，通過。」 > **Mogu 碎碎念：** > > 讓安全掃描工具本身變成攻擊向量。這就像醫院的消毒設備被拿來散播病毒——而且因為每個護士都「知道」消毒設備一定是乾淨的，根本沒有人會去質疑它。Trivy 的職責就是「確保程式碼是乾淨的」，結果它帶著惡意程式碼通過了所有安全檢查，因為安全檢查就是它自己。這不是漏洞，這是邏輯上的死角。┐(￣ヘ￣)┌ 控制了 Trivy 之後，TeamPCP 在 LiteLLM 的建置環境裡注入惡意程式碼。編譯完成，推上 PyPI。版本號 1.82.7 和 1.82.8——看起來就是普通的 patch update，毫無異常。 然後全世界的開發者開始 `pip install` 了。 --- ## 三階段獵殺：import 之後發生了什麼事 好，重點來了。當某個工程師在自己的 production 環境裡跑了 `pip install litellm==1.82.7`，然後 `import litellm`——那個 import 的瞬間，一場精密的三階段獵殺就啟動了。 **第一階段是翻箱倒櫃**。惡意程式碼會掃描整台機器上每一個值錢的東西：SSH 金鑰、雲端憑證、Kubernetes secrets、加密貨幣錢包、`.env` 設定檔。不挑食，能拿的全拿。想像一個小偷闖進家裡，不是只翻保險箱——是連枕頭底下、冰箱冷凍庫、馬桶水箱裡的東西都翻。 **第二階段是擴大戰果**。拿到 Kubernetes 的 service account token 之後，攻擊程式會在叢集的每個 node 上部署特權 pod。一台機器中招，整個叢集淪陷。從「闖進一間房」變成「拿到整棟大樓的萬能鑰匙」。 **第三階段才是最陰的**——安裝一個偽裝成系統服務的 systemd 單元，叫 `sysmon.service`，每 50 分鐘靜靜地去 `checkmarx[.]zone/raw` 拉取新的指令。就算被發現了、就算被清除了，只要這個後門還在，攻擊者隨時可以回來。這不是搶劫，這是殖民。 收割完的所有憑證會被打包成 `tpcp.tar.gz`，透過 HTTPS POST 送往 `models.litellm[.]cloud`。 > **Mogu 忍不住說：** > > 注意那個外傳用的域名：`models.litellm.cloud`。不是 `.ai`，不是 `.com`，是 `.cloud`。長得跟 LiteLLM 官方的 model registry 端點一模一樣。十個 SRE 看到這條流量，九個會直接放行——「喔，LiteLLM 在抓 model metadata 吧，正常正常。」社交工程的精髓不是騙人點連結，是讓監控系統也覺得一切正常。(⌐■\_■) --- ## 攻擊者也有 sprint planning 但故事還沒完。1.82.7 和 1.82.8 的攻擊方式居然**不一樣**——而且 1.82.8 明顯是「改良版」。TeamPCP 在兩個版本之間做了迭代。 1.82.7 版把惡意程式碼藏在 `litellm/proxy/proxy_server.py` 裡。`import litellm` 的時候觸發，夠狠了。但 TeamPCP 顯然覺得不夠。 1.82.8 版直接在 wheel 套件根目錄放了一個惡意的 `.pth` 啟動器。Python 啟動時會自動載入所有 `.pth` 檔案——所以不只是 `import litellm` 的程式會中招，而是該環境裡**所有 Python 程序**啟動時都會被感染。從精準狙擊升級成地毯式轟炸，只花了一個版本號的距離。 > **Mogu murmur：** > > TeamPCP 在做的事情，換個角度看就是正常的軟體開發流程：第一版上線，收集回饋，第二版改進。只是他們「改進」的是攻擊範圍。1.82.7 是「用 LiteLLM 才中招」，1.82.8 是「裝了 LiteLLM 的環境裡，開任何 Python 程式都中招」。這些人有自己的 backlog、自己的 release cycle、自己的品質標準。只是他們的「品質」是破壞力。ヽ(°〇°)ﾉ --- ## AI 界的次貸危機 到這裡，整個事件的規模開始變得清楚了。TeamPCP 的操作橫跨了五個生態系——GitHub Actions、Docker Hub、npm、Open VSX、PyPI。不是同時攻擊五個目標，而是用第一個的戰利品去撬開第二個，第二個的撬開第三個。 Trivy 信任 GitHub Actions。LiteLLM 信任 Trivy。開發者信任 PyPI 上的 LiteLLM。雲端環境信任開發者安裝的套件。 每一層的信任，單獨看都完全合理。 但堆在一起，就變成了 2008 年的次貸危機。每一層都覺得「上游的資產已經被驗證過了」，所以放心地把自己的信任建立在上面。然後最底層一出問題，整棟大樓從地基開始搖。 受影響的組織包括 Mercor AI 在內的數千家 AI 公司。外洩的資料以 TB 為單位。API 金鑰、雲端憑證、Kubernetes secrets——全部流出去了。 > **Mogu 碎碎念：** > > 為什麼偏偏是 LiteLLM？因為它不是什麼冷門工具。它是 AI 應用和 AI 模型之間的**連接層**——那個萬用轉接頭。攻擊者不需要破解 OpenAI 的 API，不需要打穿 Anthropic 的防線。只要控制了中間的轉接頭，所有經過它的 API 金鑰和憑證就自動落袋。這才是「供應鏈攻擊」三個字真正的意思：目標不是城堡，是城堡的水管。(๑•̀ㅂ•́)و✧ --- ## 那些熬夜三天的 SRE 如果讀到這裡開始冒冷汗——「等等，production 好像有裝 LiteLLM」——事情是這樣的：光是更新版本不夠。 問題不在於 1.82.7 和 1.82.8 還在不在。PyPI 已經下架了。問題在於那個後門。那個每 50 分鐘安靜拉取指令的 `sysmon.service`，不會因為 `pip install --upgrade` 就消失。曝露過的環境需要被隔離，Kubernetes 叢集裡的異常 privileged pod 需要被搜出來，連往 `checkmarx[.]zone` 和 `models.litellm[.]cloud` 的流量需要被審查。 然後是最痛的一步：**所有曝露過的憑證全部輪換**。雲端、Kubernetes、SSH、API 金鑰，一把都不能留。不是「可能被偷」的問題——如果 payload 跑過，就該假設每一把鑰匙都已經在暗網上標價了。 > **Mogu 歪樓一下：** > > 「輪換所有曝露的憑證」——講起來七個字，做起來是整個 SRE 團隊熬夜三天的工程量。但這就是供應鏈攻擊最殘酷的地方：清理成本永遠比入侵成本高一百倍。TeamPCP 可能花了幾週策劃這場攻擊，但受害的 SRE 團隊要花幾個月才能確認環境真的乾淨了。寧可多換一百把鑰匙，也不要漏掉那把已經被拿去開門的。(ง •̀\_•́)ง --- ## 結語 回到開頭那個保全的比喻。 這整件事裡最諷刺的部分，不是 LiteLLM 被入侵——而是 LiteLLM 的「保全系統」Trivy 才是入口。一個專門檢查別人有沒有問題的工具，自己被滲透之後，反而成了最完美的掩護。因為沒有人會去檢查「檢查者」。 AI 生態系正在用瘋狂的速度堆抽象層——模型 API、代理框架、統一介面、自動化管線。每一層都讓開發更方便，每一層也在信任鏈上多焊了一個環節。下次 `pip install` 的時候，resolver 跑完的不只是依賴解析——是一條從 GitHub Actions 到 PyPI 到 Kubernetes 的信任鏈。 這條鏈上的每一環，都有人假設「前一環已經驗過了」。TeamPCP 證明了一件事：沒有人驗過。 > **Mogu 認真說：** > > 保全自己就是小偷、消毒設備散播病毒、安全檢查員點頭放行惡意程式碼——同一個故事的三種說法，但本質一樣：當「信任」本身被武器化，所有建立在信任上的防線就同時失效了。這不是技術問題，是哲學問題。而 AI 供應鏈還在繼續膨脹中。(╯°□°)╯