AI infrastructure security
CISA 將 LiteLLM MCP 驗證繞過列入已遭利用漏洞，失敗金鑰曾降級成有效工作階段
CVE-2026-59822 讓偽造 Bearer token 在特定 OAuth2 passthrough 路徑繞過 LiteLLM 驗證，進而列出及呼叫已設定的 MCP 工具。漏洞早已在 1.84.0 修補，但 CISA 新增 KEV 紀錄，使盤點公開端點與輪替上游憑證成為即時工作。
美國 CISA 於 9 月 2 日把 LiteLLM 的 CVE-2026-59822 加入 Known Exploited Vulnerabilities（KEV）目錄，為原先 6 月公開的漏洞帶來實質更新。問題位於 MCP Streamable HTTP 端點的驗證處理：系統為上游 MCP 伺服器支援 OAuth2 passthrough，但 LiteLLM 金鑰驗證失敗後，特定備援路徑沒有直接拒絕要求，反而以空的 `UserAPIKeyAuth()` 物件繼續處理。攻擊者只需送出任意 Bearer token，便可能被當成已驗證工作階段。
影響不只是取得聊天或模型回應。維護者的安全公告指出，成功利用者能列出並呼叫 LiteLLM 已設定的 MCP 工具，因而觸及工具背後的資料庫、雲端服務或其他企業系統。漏洞可由網路遠端觸發，不需要既有權限或使用者互動；GitHub 公告給出的 CVSS 4.0 分數為 8.8，主要風險是高機密性衝擊與較低程度的完整性衝擊。
受影響範圍是 1.84.0 以前的 LiteLLM，修正版為 1.84.0 或更新版本。無法立即升級時，維護者建議停用 MCP 路由，或在反向代理及 API gateway 封鎖 `/mcp/` 與相關端點。CISA 對美國聯邦民政機關設定的處理期限是 9 月 16 日；KEV 收錄代表已有遭利用證據，但不等於每個部署都已被入侵。The Hacker News 引述 Wiz 的蜜罐觀察，稱已看到針對此漏洞的模型列舉探測。
部署者不應只核對套件版本。應先盤點哪些 LiteLLM 實例可從網際網路或不受信任網段抵達、哪些 MCP 工具具寫入能力，再檢查異常 Bearer token、工具列舉與呼叫紀錄。若端點曾暴露，還需輪替 MCP 工具可取得的上游 API key，並驗證閘道在所有驗證例外與 passthrough 分支都採 fail-closed；單靠外層登入頁或「內部服務」標籤不足以界定實際攻擊面。