AI 基礎設施安全
LiteLLM 實測 9.6% 公開閘道接受預設金鑰，MCP 漏洞可把任意 token 變成有效工作階段
Wiz 掃描 3,074 個公開 LiteLLM 實例，發現 294 個接受 `sk-1234` 或完全沒有驗證，其中 191 個未設定認證。新揭露的實地量測顯示，舊版 MCP 驗證繞過、可執行 Python 的 guardrail 與雲端中繼資料存取可被串成跨層攻擊路徑。
Wiz 於 9 月 9 日公布對 LiteLLM 的[攻擊面研究](https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise)。研究人員在 2026 年 2 月透過 Shodan 找到 3,074 個公開閘道，其中 294 個、即 9.6%，接受文件範例使用的管理金鑰 `sk-1234` 或未要求認證；191 個屬於後者。這次值得跟進的材料不是新 CVE，而是公開部署量測及蜜罐觀察：Wiz 稱 MCP 驗證繞過已出現實際利用。
核心漏洞 CVE‑2026‑59822 位於 MCP Streamable HTTP 的獨立驗證路徑。系統原本允許把無法辨識的 Bearer token 當作上游 OAuth2 token 傳遞，但失敗分支會建立空白的 `UserAPIKeyAuth` 物件，讓攻擊者用任意 token 建立已驗證工作階段，列舉並呼叫閘道連接的 MCP 工具。[GitHub 安全公告](https://github.com/advisories/GHSA-7488-6r32-c95q)將其評為 CVSS 8.8，影響 1.84.0 以前版本；修補版會阻止這條 fallback 路徑。
第二條鏈涉及 Custom Code Guardrails。舊版的正式建立及更新端點沒有套用測試端點使用的沙箱與驗證，具有權限的呼叫者可提交由伺服器執行的 Python；未設定 master key 時，舊版又會把匿名請求視為 `PROXY_ADMIN`。這項 CVE‑2026‑59821 已在 1.82.0 修正。若服務同時保留預設金鑰並運行舊版，原本屬於驗證後的程式執行便可能退化為近似未驗證攻擊。
Wiz 另指出 pass-through endpoint 可指向任意 URL，甚至 AWS instance metadata；管理者權限可藉轉送標頭完成 IMDSv2 token 流程。該能力未被列為漏洞，因此升級本身不足以消除全部風險。維運者應至少升至 1.84.0 以上、輪替 master key 與模型供應商金鑰、從公網移除管理及 MCP 路由，並以網路政策封鎖 link-local metadata。掃描數字只代表研究當時可見的實例，且「取得容器 root」仍取決於版本、執行帳號及部署權限，不能推廣為所有 LiteLLM 安裝皆可直接接管。