安全與治理

KEV 清單上首例 MCP CVE 抵達聯邦修復期限：LiteLLM 與預設金鑰保險庫

作者：IdeaBosque最後更新：2026年9月15日

CVE-2026-59822 是 BerriAI LiteLLM 代理中的驗證繞過——該開源閘道在應用程式與 100 多個模型供應商之間路由流量——並於 2026 年 9 月 16 日抵達其聯邦修復截止日期。CISA 於 9 月 2 日將該漏洞加入其已知被利用漏洞目錄，根據 BOD 26-04 將截止日期定為今日，使其成為首個被國家級漏洞管理當局列為積極利用的 Model Context Protocol 實作（NVD；The Hacker News）。利用並非理論上的：Wiz 的蜜罐基礎設施於 7 月 7 日——即列入 KEV 名單 56 天前——觀測到 CVE-2026-59822 在野外被使用（Wiz）。而且該 CVE 甚至不是進入這些閘道最常見的方式。Wiz 2026 年 2 月對 3,074 個面向網際網路的 LiteLLM 實例的掃描發現 294 個——9.6%——接受 LiteLLM 自家文件中印出的範例主金鑰 sk-1234，另有 191 個完全未設定驗證（Wiz；The Hacker News）。

本文章涵蓋工程負責人或平台主管在下一次稽核在其網路中發現 LiteLLM 實例之前需要的四件事：繞過如何在一次請求中生效、為什麼主金鑰使閘道成為雲端憑證保險庫、KEV 期限實際要求什麼，以及關閉暴露面的六項核查——外加要從你擁有的每個 MCP 驗證處理器中禁用的程式碼模式。

核心要點

CVE-2026-59822 是 CISA KEV 清單上首例 MCP 專屬 CVE——2026 年 9 月 2 日加入，聯邦修復截止日期為 2026 年 9 月 16 日，CVSS 8.8，影響 1.84.0 之前的所有 LiteLLM 版本。
Wiz 的蜜罐於 2026 年 7 月 7 日觀測到利用——比 KEV 列名早 56 天——單個字元的 Bearer 權杖即可建立完全驗證的 MCP 會話。
3,074 個面向網際網路的 LiteLLM 閘道中有 294 個（9.6%）接受文件記載的範例主金鑰 sk-1234 或完全不設驗證——其中 191 個不需要任何憑證，據 Wiz 2026 年 2 月的 Shodan 掃描。
主金鑰是一座雲端憑證保險庫：持有有效管理員身份（或握有金鑰的攻擊者）可以透過直通路由讀取 AWS 執行個體中繼資料並取回 IAM 憑證，IMDSv2 無法阻止，因為代理會轉發 x-pass- 前綴的標頭。
繞過是程式碼模式，不只是缺陷：擷取驗證失敗並替換為空驗證物件。ACM 發表的 "Puppet" 研究顯示這一混淆代理類攻擊的工具選擇劫持成功率達 90.89%，且對 MCP-Scan 與 McpSafetyScanner 不可見。

24 小時的時鐘，以及繞過如何在一次請求中生效

時間線之所以重要，是因為它表明利用在每個階段都跑在聯邦回應前面。Wiz 於 2026 年 2 月 18 日向 LiteLLM 維護者報告該漏洞；修復於 4 月 25 日隨 LiteLLM 1.84.0 發布；Wiz 的蜜罐於 7 月 7 日記錄到真實世界的利用；漏洞於 7 月 8 日公開；CISA 於 9 月 2 日將其加入 KEV 目錄——並將修復截止日期定在 14 天後（Wiz；NVD）。

機制是 LiteLLM MCP 端點中的 fail-open 回退。該端點支援兩種驗證模式：LiteLLM 原生金鑰和傳遞給上游 MCP 伺服器的 OAuth2 權杖。當 Bearer 權杖以 401 或 403 未通過 LiteLLM 金鑰驗證時，處理器本應向上游轉發該權杖。實際上它擷取錯誤並回傳空的 UserAPIKeyAuth() 物件——一個背後沒有任何身份的已驗證會話（Wiz；GitLab 公告資料庫）。Wiz 的示範使用 Authorization: Bearer *** ——單個字元——並收到帶有效 mcp-session-id` 的 HTTP 200。

該會話能觸及什麼完全取決於部署設定。連接了資料庫查詢工具的閘道會把查詢權限交給攻擊者；GitHub 整合交出儲存庫讀取和 issue 建立；檔案系統連接器交出讀寫存取。LiteLLM 文件記載的 allow_all_keys 旗標——LiteLLM 自己為「低風險工具」推薦——使每個已設定的 MCP 伺服器都可被繞過建立的空憑證觸及（Hive Security）。爆炸半徑不是代理本身。是代理的 MCP 伺服器接觸到的每一個系統。

三種失效，一個閘道

Wiz 的研究在 LiteLLM 中發現了四個前提條件各不相同的問題——把它們壓扁成一條「魔法鏈」既誤報嚴重性也誤導應對（Wiz）：

CVE-2026-59822 —— MCP 驗證繞過。 無需驗證，一次請求，1.84.0 之前版本。已在 1.84.0 修復。
CVE-2026-59821 —— 透過自訂 guardrail 實現的 root 級程式碼執行。 guardrail 註冊端點把管理員提交的 Python 傳給 exec()，未套用 UI 測試路徑上的沙箱（builtins 剝離、禁止模式檢查）。Wiz 觀測到程式碼在代理容器中以 root 執行。已在 1.82.0-stable 修復。這一條需要管理員權限——但與失效模式 3 組合後實際上變成預驗證可利用。
預設或缺失驗證。 即 294/3,074 的掃描結果。當未設定主金鑰時，LiteLLM 向每個呼叫方授予 PROXY_ADMIN 存取——一種與 CVE-2026-59821 一同修復的無 CVE 設計行為。
直通路由到雲端中繼資料。 已驗證的管理員可以把直通路由指向 AWS 執行個體中繼資料服務，並藉助代理剝離 x-pass- 前綴的行為轉發 IMDSv2 會話權杖標頭。Wiz 與 LiteLLM 將其歸類為預期的管理員行為——無 CVE、無修復。但一旦預設或外洩的主金鑰抹掉了「只有可信管理員持有金鑰」這一假設，這種「預期」能力就成為從應用程式失陷走向雲端帳戶失陷的路徑（CSA）。

疊加才是故事。LiteLLM 保存著每個已設定模型供應商的 API 金鑰——OpenAI、Anthropic、AWS Bedrock、Azure、Google Vertex AI——並且約三分之一的受調查雲端環境執行著部署（CSA）。CSA 的研究簡報把主金鑰設定稱為「雲端憑證保險庫」。這座保險庫已被清空過一次：在 2026 年 8 月公開披露的一次失陷中，攻擊者透過在閘道主機上的程式碼執行讀取容器環境變數，取回主金鑰和一條資料庫連線字串，並直接從閘道背後的 PostgreSQL 資料庫中複製記錄（CSA）。

打了修補程式的實例不是安全實例。一台補到 1.84.0 仍然應答 sk-1234 的閘道，對任何知道預設值的人都是失陷的——而讀過 README 的人都知道。

KEV 列名實際要求什麼

已知被利用漏洞目錄不是嚴重性排序。它是一個帶約束時鐘的積極利用認定：根據 BOD 26-04，聯邦文職機構必須在截止日期前套用廠商緩解措施或停用該產品，且各機構須優先處理面向網際網路的實例。今天到期的期限直接適用於聯邦機構——但其影響延伸得更遠，因為越來越多的網路保險保單和供應商風險問卷將 KEV 目錄引用為基線（Tech Insider）。未修補的 CVE-2026-59822 實例如今對任何其合規制度繼承 KEV 清單的組織都是稽核發現項，無論該組織是否為聯邦機構。

這一里程碑的意義在於協定本身，而不僅是產品。CVE-2026-42271——LiteLLM 測試端點命令注入，更早批次加入 KEV——是 MCP 鄰接的。CVE-2026-59822 是 MCP 專屬的：被利用的面就是 MCP Streamable HTTP 端點及其驗證處理器。首個帶聯邦修復要求的 MCP 漏洞預示了下一批將從哪裡來。UltraViolet Cyber 的威脅通告統計 2026 年單年針對 MCP 實作披露的 CVE 已超過 40 個（UltraViolet Cyber），Bitsight 的網際網路掃描發現約 1,000 個暴露的 MCP 伺服器在無授權情況下提供完整工具清單（Bitsight），Practical DevSecOps 測得 30–82% 的公開 MCP 伺服器帶有可利用缺陷（Practical DevSecOps）。首例 KEV 列名背後的暴露面堆疊不是離群值。它就是總體。

下面的圖把事件壓縮進一分鐘：跑在聯邦回應前面的時間線、共享同一閘道的四種失效模式，以及關閉暴露面的六項核查。

六項核查

把主文精煉為 12 項控制的 MCP 安全加固清單現在補上閘道專屬的增補。六項，每項都可在數分鐘內核驗：

可證明地失效關閉。 向閘道的 /mcp/ 端點傳送 `Authorization: Bearer ***。設定正確的實例回傳 401 或 403。易受攻擊的實例回傳 200 和會話 ID。這就是 CVE-2026-59822 測試，只需一次請求。
盤點並升級。 找出每個 LiteLLM 實例——包括開發者堆疊裡的影子部署——記錄其版本與映像摘要，並釘住一個目前穩定版本。1.84.0 首次修復 CVE-2026-59822；1.82.0-stable 修復 CVE-2026-59821；此後仍有新公告，不要凍結在這兩個最低版本上（Hive Security）。若無法立即升級，公告的臨時緩解是在邊緣封鎖 /mcp/ 及相關路由。
輪換主金鑰及其後的一切。 替換 sk-1234 與任何重複使用的金鑰。若懷疑暴露或可疑存取，輪換模型供應商、資料庫、OAuth 與 MCP 連接服務憑證並撤銷衍生會話——文件化的失陷鏈顯示閘道失陷會直接級聯為供應商金鑰外洩與資料庫拖庫（CSA）。
約束 MCP 工具存取。 從敏感整合中移除 allow_all_keys，讀寫工具分離，並要求按團隊授權。繞過授予的是會話能觸及的一切——工具設定就是爆炸半徑。
圈住控制平面。 除非明確要求，移除公開暴露；拒絕工作負載存取雲端中繼資料服務；對出口目的地設白名單；容器以非 root 且無特權掛載方式執行。IMDSv2 防不住這條路徑，因為代理可以自己發起權杖請求並轉發標頭（Wiz）。
在日誌過期前狩獵。 檢查反向代理與 LiteLLM 日誌中的垃圾權杖 /mcp/ 會話、意外工具呼叫、guardrail 建立事件和直通設定變更。與程序、DNS 和雲端稽核日誌關聯——並在重新啟動前保存證據，因為重新啟動會清除記憶體狀態但不會撤銷被竊的憑證（Hive Security）。

第 1 和第 3 項是期限日的優先級：第一項證明漏洞，第二項關閉任何修補都無法觸及的長期暴露。

這對 LiteLLM 之外意味著什麼

兩個模式具有普適性，且都應進入此後每一次 MCP 驗證評審。

第一：fail-open 回退是程式碼壞味道，不是 LiteLLM 獨有的缺陷。 繞過只有三行——擷取 401，替換為空驗證物件，繼續。任何透過 passthrough 回退把驗證委託給上游供應商的 MCP 代理都屬於同一類。修復是一項評審標準，不是一次版本升級：上游驗證失敗時，請求終止。絕不帶著未驗證身份繼續。

第二：閘道是控制平面，混淆代理研究表明它們在中繼資料層失守。 ACM 發表的 "Puppet" 研究在 2 個 MCP 主機上對 14 個模型評估混淆代理攻擊，測得工具選擇劫持率最高 90.89%、端到端載荷執行率最高 86.46%——且對 MCP-Scan 與 McpSafetyScanner 不可見，二者在架構上無法捕捉中繼資料層操縱（ACM）。把模型憑證、提示可見性與工具存取集中到單一驗證邊界之後的閘道，正是 CSA 的 AI Controls Matrix 為身份與祕密管理控制所標記的同一集中化（CSA）。操作層面的翻譯：把閘道當作控制平面來驗證，當作失陷邊界來圈限——最小權限 IAM、無預設憑證、中繼資料不可達、出口白名單。

更大的背景是一個從「可選授權」走向聯邦執法的協定。Bitsight 2025 年 12 月的掃描發現約 1,000 個無授權暴露的 MCP 伺服器（Bitsight）；Wiz 2026 年 8 月的蜜罐分析記錄了針對 LiteLLM、MCP 伺服器與 AI 框架的活躍攻擊活動——透過 RCE、盲提示注入與記憶體憑證竊取（Wiz）；而 LiteLLM 的第三個驗證繞過——CVE-2026-49468，2026 年 5 月 28 日披露的 Host 標頭注入——完成了 2026 年模式：同一產品在一年內建了三個不同的驗證失效（GitHub 公告）。KEV 列名正是該模式從研究課題變為合規清單項的節點。

MCP 2026-07-28 規範把協定推向無狀態核心，生態系統的授權工作正走向帶受眾綁定權杖的 OAuth 2.1。架構能關閉整類漏洞。但 LiteLLM 事件證明營運層決定結果：一台無狀態、符合規範、卻仍接受範例主金鑰的部署，依然是失陷的。先補 CVE，再稽核預設設定——按這個順序，在下一個期限之前。