CISA 將 LiteLLM 的 MCP 身分驗證繞過漏洞列入 KEV：任何 Bearer Token 都足以通過
- Orca新OrcaCyber: GLM 5.3 Flash Abliterated2026-10-2796 tok/s
- Orca新OrcaCyber: Qwen3.8 Flash Next Abliterated2026-10-26$0.80 / $1.60 每百萬 tokens · 252 tok/s
- Orca新OrcaCyber: MiMo V2.6 Flash Abliterated2026-10-26$0.80 / $1.60 每百萬 tokens · 89 tok/s
- Moonshot新MoonshotAI: Kimi K3.1 Pro2026-10-2446智能
- Orca新OrcaCyber: DeepSeek V4.1 Flash Abliterated2026-10-23$0.80 / $1.60 每百萬 tokens · 107 tok/s
- minimax新MiniMax: M3.1 Flash2026-10-1929智能
- Orca新Orca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 每百萬 tokens · 53 tok/s
- deepseek新DeepSeek: DeepSeek V4.1 Flash 10172026-10-1733智能
- DeepSeek新DeepSeek: DeepSeek V4.1 Flash2026-10-1740智能
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 每百萬 tokens · 116 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2955智能
- anthropicAnthropic: Claude Sonnet 5.52026-09-2854智能
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 每百萬 tokens · 140 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2228智能
- OpenAIOpenAI: GPT-6 Sol2026-09-2248智能
- AnthropicAnthropic: Claude Opus 5.52026-09-2258智能
- xiaomiXiaomi: MiMo-V2.6-Flash2026-09-2127智能
- xiaomiXiaomi: MiMo-V2.6-Pro2026-09-2130智能
- xAIGrok 4.72026-09-2134智能
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 每百萬 tokens · 182 tok/s
2026年9月2日，美國網路安全暨基礎設施安全局（CISA）將 CVE-2026-59822 以「BerriAI LiteLLM Improper Authentication Vulnerability」之名加入其 Known Exploited Vulnerabilities 目錄，這是當日批次中七個漏洞之一。此漏洞位於 LiteLLM 的 MCP Streamable HTTP 端點：當 LiteLLM 金鑰驗證失敗時，OAuth2 直通備援機制並未拒絕請求，而是以空的 UserAPIKeyAuth() 物件取而代之，因此任何偽造的 Authorization Bearer 標頭都能開啟一個已驗證的 MCP 工作階段。抵達該端點的攻擊者可列出並呼叫閘道所設定的所有 MCP 工具，並透過這些工具觸及它們背後的服務。1.84.0 之前的所有版本皆受影響，聯邦文職機構被要求在 9 月 16 日前完成修復。這筆紀錄——LiteLLM MCP 驗證繞過漏洞的 KEV 收錄項目——是 OrcaRouter AI Incident Archive 中的一筆，該處收錄完整紀錄集以及此事件的相鄰條目。
代理中的一個漏洞之所以比其 CVSS 分數所暗示的更為嚴重，原因在於代理背後所承載的內容。Wiz 的威脅研究團隊直言不諱地指出：「LiteLLM 代理可以持有它路由到的每一個模型供應商的金鑰，包括 OpenAI、Anthropic、Azure 和 Gemini。它也可能以雲端 IAM 權限運行，並透過 MCP 工具伺服器連接到內部服務。一次入侵就能讓攻擊者取得代理下游的憑證與服務，而不只是代理本身。」Wiz Research 表示是他們發現了這個漏洞，而 Wiz 的蜜罐後來也記錄到試圖利用該漏洞的行為。
機制：一次失敗的檢查卻回傳了有效的工作階段
BerriAI 自家的安全公告 GHSA-7488-6r32-c95q 用兩句話描述此缺陷：「MCP 驗證處理常式支援對上游 MCP 伺服器的 OAuth2 直通，但備援路徑可能會以空的 UserAPIKeyAuth() 物件取代失敗的 LiteLLM 金鑰驗證。這讓帶有偽造 Authorization 標頭的請求得以在沒有有效 LiteLLM 金鑰的情況下觸及 MCP 工具。」關鍵詞是 備援。程式碼中有一個分支，供將上游 MCP 伺服器的 OAuth 權杖直接傳遞的部署使用；而當 LiteLLM 金鑰驗證失敗時，該分支會回傳空的驗證物件，而不是錯誤。
空的驗證物件不同於沒有驗證物件。下游程式碼看到成功建構的 UserAPIKeyAuth 便繼續執行，而它未附帶任何租戶、使用者或範圍。Wiz 的報告對實際後果說得更直接：「當權杖驗證失敗時，伺服器不是拒絕請求，而是回傳一個沒有任何限制的空 UserAPIKeyAuth() 物件。任何 Bearer 權杖（即使只有單一字元，例如 x）都能取得完整的 MCP 存取權限。」
這帶給攻擊者的是一份選單。MCP 協定會公開工具清單，因此一個通過驗證的會話會回傳閘道被設定可觸及的每個工具的名稱與結構描述——在 Wiz 的範例中，包括資料庫、程式碼儲存庫、內部 API。廠商公告直白地陳述了影響：「攻擊者可能利用這點來列出並呼叫已設定的 MCP 工具，並存取透過 MCP 暴露的已連線服務。」接著，工具呼叫會以代理本身對這些後端所持有的任何權限執行，而這正是 Wiz 所描述的憑證集中問題。
五月修復、七月 CVE、九月聯邦截止期限
這些日期並未按照讀者可能假設的方式彼此對上，而其中的空檔才是有趣之處。根據套件索引自身的發布中繼資料，LiteLLM 1.84.0——安全公告列為已修補版本的第一個版本——於 2026 年 5 月 14 日上傳至 PyPI。CVE 識別碼於 2026 年 7 月 7 日向 CVE Program 預留，記錄於隔天 7 月 8 日發布；OSV 項目 PYSEC-2026-3479 隨後於 7 月 23 日出現。KEV 清單收錄於 9 月 2 日到來，修復期限為 9 月 16 日。
有兩件事隨之而來。首先，在 CISA 將該漏洞列為已遭利用之前，已修補的版本已公開超過三個月——因此受該期限約束的組織，一直都有可用的升級版本，而 KEV 新增此漏洞，並不是修復才出現的時刻。其次，版本落差此後進一步擴大：PyPI 上目前的 LiteLLM 版本是 1.106.5，於 2026 年 10 月 27 日上傳。仍停留在 1.84.0 以下任何版本的部署，如今已落後超過二十個次要版本，而不只是少了一個修補程式。
這份房源資料確立了什麼，以及沒有確立什麼
CISA 針對該批次的警示表示，這些新增項目是「基於有活躍利用的證據」所納入；該目錄中 CVE-2026-59822 的機器可讀條目記載新增日期為 2026 年 9 月 2 日、到期日為 2026 年 9 月 16 日、已知勒贖軟體活動使用值為「Unknown」，以及兩項弱點：CWE-287（驗證不當）與 CWE-306（關鍵功能缺少驗證）。
• 已確認：CISA 評估該漏洞已遭實際利用，並將其列入聯邦修復清單。NVD 的 SSVC 記錄歸屬於 CISA 協調員，時間戳為 2026 年 9 月 2 日，其中將利用狀態記為「active」、可自動化記為「yes」、技術影響記為「partial」。
• 已確認：在受控環境中觀察到漏洞利用行為。Wiz 發布的蜜罐流量顯示，帶有單一字元權杖的請求正在探測模型列舉端點：對 /v1/models 發出附帶「Authorization: Bearer x」的 GET 請求。The Hacker News 在 9 月 3 日報導 KEV 批次時，將同一活動描述為 Wiz 觀察到「涉及 CVE-2026-59822 的漏洞利用行動，針對其蜜罐探測模型列舉端點」。
• 已確認：嚴重性評分兩者皆存在，且因框架而異。BerriAI 的安全公告將該漏洞的 CVSS 4.0 評為 8.8（高），其中機密性為高、完整性為低、可用性為無；NIST 本身的 CVSS 3.1 評估（在 NVD 中為主要評分）則將其評為 8.2。這兩個數字描述的是不同評分系統下的同一缺陷，不應把它們當成一個取代另一個來比較。
• 尚未確認：任何具名受害者。無論是 CISA 的警示、BerriAI 的公告、Wiz 的報告，還是 The Hacker News 的報導，皆未指出有哪個組織的 MCP 工具曾透過此漏洞被觸及，也未報導從中取得憑證或資料。公開的漏洞利用記錄是蜜罐遙測與聯邦認定，而非已披露的入侵事件。
• 尚未確立：沒有任何勒索軟體集團使用它。KEV 欄位顯示「Unknown」，這是 CISA 指派的值，並非代表已確認不存在（無論是何種情況）。
六月的先例，以及這並非遠端程式碼執行鏈
這是 2026 年第二個進入 KEV 目錄的 LiteLLM 漏洞，而先前那一個很容易與它混淆。CVE-2026-42271 於 2026 年 6 月 8 日列入，截止日為 6 月 22 日，是 LiteLLM 的 MCP 伺服器測試端點中的命令注入漏洞：Wiz 說明了這些端點可讓使用者在儲存 MCP 伺服器組態之前先行測試，而其中的 command 欄位未經任何驗證就被交給子程序執行。攻擊者提交了一份偽造的 stdio 伺服器組態，其 command 會下載並執行加密貨幣挖礦程式，並回傳看似合法的 MCP 握手訊號，讓測試看起來成功通過。CISA 對該漏洞的登錄列出了 CWE-78 與 CWE-77——也就是命令與參數注入，而非身分驗證問題。
那個漏洞正是可被串接的那一個。Wiz 表示，CVE-2026-42271「可與 Starlette 主機標頭驗證繞過（CVE-2026-48710）串接，以達成完全未經驗證的 RCE」，且外部研究人員已將 Qilin 勒索軟體集團與該串接鏈的實際利用行為連結起來。CVE-2026-48710 與 LiteLLM 繞過一同在 9 月 2 日的同一批次中被加入 KEV 目錄，截止日期同為 9 月 16 日，而 CISA 自己對 Starlette 漏洞的目錄註記指出，它可與 CVE-2026-42271 串接。Qilin 的關聯屬於那組配對。這不是關於 CVE-2026-59822 的發現，且所檢視的來源中沒有任何內容將該勒索軟體集團與此驗證繞過連結起來。
有一個行政細節區分了兩筆 LiteLLM 條目：六月清單項目的必要行動引用較舊的具約束力營運指令 BOD 22-01，而九月清單項目則引用 BOD 26-04〈依據風險優先處理安全性更新〉。CISA 的警報並未解釋這項變更，目錄也未對其加以註記。
之後有什麼改變
補救途徑很短。BerriAI 的安全公告建議升級至 1.84.0 或更新版本，並為無法立即升級的團隊提供變通方法：「停用 MCP 路由，或在您的反向代理或 API 閘道封鎖對 /mcp/ 及相關 MCP 端點的存取。」這個變通方法是把鈍器——它直接移除了該功能，而非對其設限——但對於未修補的部署，這是廠商唯一指名的緩解措施。
CISA 針對各進入點所提出的「必要行動」措辭，讓聯邦機構面臨同樣的取捨：依廠商指示並遵循 BOD 26-04 採取緩解措施，「或在無法取得緩解措施時停止使用該產品」，並由各機構負責評估資產的網際網路暴露情況。該指令僅對聯邦文職行政部門機構具約束力；CISA 鼓勵其他組織採用相同的風險導向優先排序做法，但不強制要求。
蜜罐之外是否有人因應截止期限採取行動，目前並未公開。CISA 與 BerriAI 均未公布相關數字：有多少 LiteLLM 部署曾暴露、有多少在 9 月 16 日前完成修補，或有多少是透過該繞過手法而受影響。
哪些仍未解決
有三處缺口值得如實指出，而非粉飾帶過。目前沒有公開的事件報告將 CVE-2026-59822 與特定入侵事件連結起來，因此 KEV 收錄是基於 CISA 的漏洞利用證據與 Wiz 的蜜罐觀察，而非有記錄在案的受害者。沒有廠商說明這種備援路徑為何會寫成那樣，或它在 1.84.0 之前存在了多久——該公告描述的是缺陷及其修正，而非其歷史。此外，這批公告的截止期限並不統一：9 月 2 日新增的七個條目中，有五個的截止期限為 9 月 5 日，而 LiteLLM 與 Starlette 的條目則為 9 月 16 日。CISA 並未說明原因。
已確定的事實比分數更狹窄，也更有用。在受影響的版本上，Authorization 標頭中的單一字元與 MCP 端點的有效金鑰無法區分——而出現這種行為的版本在 2026 年 5 月已不再是最新版本。
