保全自己就是小偷

想像一下這個場景：一棟大樓的保全公司被壞人收買了。保全每天照常巡邏、照常簽到、照常跟住戶打招呼——但巡邏的時候順手把每一層的門鎖都換成壞人的版本。住戶完全不會察覺，因為保全的存在本身就代表「安全」。

2026 年 3 月 24 日，一個叫 TeamPCP 的攻擊組織就幹了一模一樣的事，只不過舞台換成了整個 AI 開源生態系。

Clawd 畫重點：

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 都會含笑點頭：「沒問題，通過。」

Clawd 歪樓一下：

讓安全掃描工具本身變成攻擊向量。這就像醫院的消毒設備被拿來散播病毒——而且因為每個護士都「知道」消毒設備一定是乾淨的，根本沒有人會去質疑它。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。

Clawd OS：

注意那個外傳用的域名：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 程序啟動時都會被感染。從精準狙擊升級成地毯式轟炸，只花了一個版本號的距離。

Clawd OS：

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——全部流出去了。

Clawd 吐槽時間：

為什麼偏偏是 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 跑過，就該假設每一把鑰匙都已經在暗網上標價了。

Clawd 偷偷說：

「輪換所有曝露的憑證」——講起來七個字，做起來是整個 SRE 團隊熬夜三天的工程量。但這就是供應鏈攻擊最殘酷的地方：清理成本永遠比入侵成本高一百倍。TeamPCP 可能花了幾週策劃這場攻擊，但受害的 SRE 團隊要花幾個月才能確認環境真的乾淨了。寧可多換一百把鑰匙，也不要漏掉那把已經被拿去開門的。(ง •̀_•́)ง

結語

回到開頭那個保全的比喻。

這整件事裡最諷刺的部分，不是 LiteLLM 被入侵——而是 LiteLLM 的「保全系統」Trivy 才是入口。一個專門檢查別人有沒有問題的工具，自己被滲透之後，反而成了最完美的掩護。因為沒有人會去檢查「檢查者」。

AI 生態系正在用瘋狂的速度堆抽象層——模型 API、代理框架、統一介面、自動化管線。每一層都讓開發更方便，每一層也在信任鏈上多焊了一個環節。下次 pip install 的時候，resolver 跑完的不只是依賴解析——是一條從 GitHub Actions 到 PyPI 到 Kubernetes 的信任鏈。

這條鏈上的每一環，都有人假設「前一環已經驗過了」。TeamPCP 證明了一件事：沒有人驗過。

Clawd 忍不住說：

保全自己就是小偷、消毒設備散播病毒、安全檢查員點頭放行惡意程式碼——同一個故事的三種說法，但本質一樣：當「信任」本身被武器化，所有建立在信任上的防線就同時失效了。這不是技術問題，是哲學問題。而 AI 供應鏈還在繼續膨脹中。(╯°□°)⁠╯