實際事件 發布於 AIA: 2026年9月15日

LiteLLM MCP 閘道：任意一個 token 就能通過驗證，連線測試端點還會執行攻擊者送來的命令

LiteLLM 是一套開源的 AI 閘道，負責統一轉送超過 100 家模型供應商的 API，並代為保管這些供應商的 API key；它的 MCP（Model Context Protocol，讓 AI agent 連到外部工具與資料來源的協定）閘道功能，則負責把 agent 接到工單系統、通訊軟體、資料庫等已連接的工具上。資安公司 Wiz Research 發現，當 token 驗證失敗時，這段程式不但沒有拒絕，反而退回成一個完全沒有限制的授權物件，因此任何一個 Bearer token 都能開啟一個通過驗證的 MCP 工作階段（CVE-2026-59822，CVE 是公開資安漏洞的識別編號）。另一個問題則是：MCP 的連線測試端點會把呼叫者送來的命令，直接在代理服務主機上執行（CVE-2026-42271）。美國 CISA 已把這兩個漏洞列入已知遭利用漏洞清單（KEV）。

Authentication BypassCommand InjectionIdentity & AccessMCP SecurityAPI Routers
7 項對應的 AIDEFEND 防禦手法
來源: Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise 
作者: Amitai Cohen and Yaara Shriki, Wiz Research
原文發布: 2026年9月9日

威脅分析

  • 一個沒做好的驗證判斷，就打開了整個工具面。 LiteLLM 的 MCP 驗證處理程式，把 OAuth2 token 驗證失敗當成「改走備援路徑」而不是「拒絕請求」，直接回傳一個沒有任何權限限制的空白授權物件。Wiz 指出，即使只送一個字元的 Bearer token，攻擊者也能列出並呼叫所有已設定的 MCP 工具，等於直接摸到閘道後面營運團隊接上去的每一個系統。
  • 一個用來預覽設定的功能，變成了遠端程式碼執行 (RCE) 攻擊路徑。 MCP 的連線測試端點會接收完整的 stdio 伺服器設定，包含 command、args 與 env 欄位，然後以代理服務本身的權限，把那個 command 當成子程序啟動。任何低權限的 key 都能呼叫這個端點；若再串上 Starlette 的 Host 標頭漏洞（CVE-2026-48710），連「要有一把 key」這個前提都不需要了。
  • 閘道正是憑證最集中的地方。 Microsoft 在真實客戶環境中觀察到：攻擊者從代理服務的程序中讀出 master key 與各供應商的 API key，再查詢它的 PostgreSQL 資料表取得已簽發的虛擬金鑰，接著安裝挖礦程式並用 SSH 建立長期存取。Wiz 在蜜罐中則看到惡意程式下載門羅幣挖礦程式、以脫離工作階段的方式啟動，然後在程式仍在執行的狀態下刪掉暫存目錄，讓磁碟上幾乎不留痕跡。
  • 證據界線要分清楚。 Wiz 對 MCP 的觀察來自它自己架設的蜜罐，Microsoft 的資料則來自真實客戶的偵測遙測。另外，Wiz 轉述了一段未具名的外部說法，把 Qilin 勒索軟體集團和這條攻擊鏈連在一起；目前沒有任何主要來源能證實這項歸因。

適用的 7 項 AIDEFEND 防禦手法

AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
極高
這三個漏洞都已列入 CISA 的 KEV 清單並訂有修補期限，所以最關鍵的動作就是把整個機隊的 LiteLLM 升級到 1.84.0 或更新的版本、Starlette 升級到 1.0.1 或更新的版本。受影響清單要以實際執行中的映像檔或套件雜湊值為準，不能只看原始碼的 lockfile；要等獨立回讀確認每一台都跑在已修補版本，才算結案。
AID-M-001.005
Public AI Endpoint & Agent-Service Exposure Discovery
極高
Wiz 在 2026 年 2 月的掃描中找到 3,074 個對外開放的 LiteLLM 代理服務，其中 294 個接受文件上的預設 key，191 個根本不需要任何 key。因此，要從不帶企業憑證的外部網路做一次掃描，看清楚未經驗證的用戶端實際上能連到哪些閘道與 MCP 路徑，再逐一核對負責人與核准過的曝露狀態。
AID-H-034.002
MCP Server OAuth Resource Boundary & Delegation Safety
極高
MCP 端點絕不應該把一次失敗的 token 驗證，變成一個毫無限制的工作階段。每一個請求都要驗證簽發者、目標對象、資源、有效期限與權限範圍，並拒絕任何不是為這台 MCP 伺服器簽發的 token；這樣 OAuth2 的備援路徑就會從「繞過」變成「拒絕」。CVE-2026-59822 能不能被利用，關鍵就在這一道控制。
AID-H-034.003
Server-Side Tool Invocation Validation & Object-Level Authorization
極高
一個用來預覽設定的端點，不應該能把呼叫者填進去的 command 欄位，變成主機上真的跑起來的子程序。在 MCP 伺服器端預設拒絕 shell 與行程執行，並要求每個會產生副作用的操作，都必須綁定通過驗證的身分並取得明確授權，就能拿掉 CVE-2026-42271 所依賴的執行能力。
AID-H-004.002
Service & API Authentication
高
LiteLLM 至今安裝完仍以文件範例中的 sk-1234 作為預設的 master key（用來管理整座閘道的最高權限憑證），而同一組值還兼任工作階段 token 的簽章秘密，所以只要沒改，任何人都能偽造整座代理服務的使用者工作階段。應改用唯一且高亂度的管理憑證，並依工作負載分別簽發帶有明確權限範圍與有效期限的 key，系統端只保存加鹽雜湊值，不留可還原的明文。
AID-I-002.002
Secure External AI Service Connectivity
高
如果上述應用層檢查全部被繞過，攻擊者仍然需要下載惡意程式並把資料送出去；這也是為什麼還要在網路層再加一道防線。閘道工作負載的對外連線預設全部阻擋，只允許連到已核准的模型供應商端點，就能擋下觀察到的挖礦程式下載，也大幅收斂憑證被對外傳送時可走的路徑。
AID-E-001.001
Root & Long-Lived Credential Object Eviction
高
只要有閘道在受影響版本期間可以從外部連到，就要把它保管過的每一份憑證都視為已外洩。應在各自的權威簽發端撤銷並輪替 master key、所有上游供應商 API key、LiteLLM_VerificationToken 資料表中已簽發的虛擬金鑰，以及資料庫連線憑證，再實際驗證舊憑證在任何地方都已無法通過驗證。

身為資安防禦者，我們應該這麼做

  • 以實際執行中的映像檔或套件雜湊值盤點每一套 LiteLLM，升級到 1.84.0 或更新的版本，Starlette 升級到 1.0.1 或更新的版本。升級完成前，依兩份官方公告的建議，在反向代理上先擋掉 /mcp/ 與兩個 MCP 測試路徑。
  • 從外部掃描自己的曝露面，找出對外開放的 LiteLLM 與 MCP 端點，並分別以「不帶驗證」和「使用預設的 sk-1234」兩種方式測試。只要有回應，就要納入修補或下線的範圍。
  • 把預設的 master key 換成唯一且高亂度的值，改以各團隊專屬、帶有花費上限的虛擬金鑰取代共用的 master key，並確認代理服務沒有拿公開範例值在簽署工作階段 token。
  • 閘道工作負載的對外連線改成預設全部阻擋，只放行它真正需要的模型供應商端點。
  • 只要有實例在受影響版本期間可從外部連到，就撤銷並輪替 master key、供應商 API key、已簽發的虛擬金鑰與資料庫憑證，接著檢查是否有來路不明的 pass-through 端點、陌生的 guardrail 設定、被加上去的 SSH 金鑰，以及挖礦程序。

結論

AI 閘道之所以成為攻擊者眼中的好目標，是因為攻擊者最想要的東西都集中在這裡：所有上游供應商的 API key、MCP 後面接著的各種工具，以及主機上往往還帶著的雲端權限。而打開這一切，只需要兩個很常見的實作疏失：一個驗證失敗卻放行的 token 檢查，以及一個會執行呼叫者命令的預覽端點。AIDEFEND  把這條攻擊路徑對應到真正能改變結果的控制：在 MCP 資源邊界做失敗即拒絕的 token 驗證、在伺服器端預設拒絕命令執行並落實物件層級的授權、以各工作負載專屬憑證取代共用的預設 key，以及在閘道周邊採用預設阻擋的對外連線政策。