一個 Bearer Token 與一個空物件：LiteLLM 授權繞過漏洞登上 CISA 已知遭利用漏洞清單，AI 閘道正式成為攻擊目標

2026 年 9 月 2 日，美國網路安全暨基礎設施安全局（CISA）將七個漏洞列入「已知遭利用漏洞」（Known Exploited Vulnerabilities，KEV）清單——這是聯邦政府最具權威性、確認已在真實世界遭到利用的漏洞資料庫。其中六個是老面孔：SonicWall 設備、Sangoma 的 PBX 系統、JFrog Artifactory、一套開源工作流引擎。第七個則截然不同。它不在防火牆或路由器裡，而是活在數千個 AI 工程團隊幾乎不假思索就部署起來的軟體中：LiteLLM——那套在應用程式與 OpenAI、Anthropic、Google 等數十家模型供應商之間代理流量的開源 LLM 閘道。

這個編號 CVE-2026-59822（CVSS 8.8） 的漏洞，是 LiteLLM「模型上下文協定」（Model Context Protocol，MCP）Streamable HTTP 端點上的不當授權（improper authentication）缺陷。它允許未經身分驗證的攻擊者，僅憑一個任意的 Bearer Token，就建立起完整的已授權 MCP 連線。而根據 Google 旗下的 Wiz 回報，攻擊者已被觀測到正在探測 LiteLLM 部署環境——包括 Wiz 自家的蜜罐——尋找模型列舉端點。對聯邦機構而言，時間已經相當緊迫：依據第 26-04 號約束性運作指令（BOD 26-04），LiteLLM 與 Starlette 漏洞的修補期限是 2026 年 9 月 16 日，其餘漏洞則須在 9 月 5 日前完成。

漏洞原理：當驗證失敗卻回傳成功

這個漏洞的技術原理簡單到近乎諷刺。LiteLLM 的 MCP Streamable HTTP 端點會驗證傳入的 Bearer Token。在 1.84.0 之前的版本，當驗證失敗——當 Token 明顯是偽造或垃圾資料時——程式碼路徑會回退到 OAuth2 passthrough 模式，並回傳一個空的授權物件，而不是直接拒絕請求。

結果是：一個帶著偽造 Authorization 標頭的請求，可以觸發 OAuth2 passthrough 回退機制，而那個空授權物件就像呼叫者已通過驗證一樣流向下游。未授權的請求就這樣在沒有有效 LiteLLM 金鑰的情況下觸及 MCP 工具。攻擊者可以列出可用的 MCP 工具、呼叫它們，並進一步滲透到閘道所連接的任何下游服務。

修補程式已在 LiteLLM 1.84.0 中發布，讓金鑰驗證失敗時確實「失敗關閉」（fail closed）。但更深層的啟示在於這個閘道本質上是什麼。一個 LLM 代理伺服器不是單純的 HTTP 轉發器。它保管著供應商 API 金鑰、模型路由設定、發給內部團隊的虛擬金鑰，而且——隨著 MCP 支援日益普及——還有直通資料庫、內部 API 與代理工作流的即時工具存取權。在這一層出現一個授權繞過，暴露的不是單一服務，而是它背後整個 AI 技術棧。

這不是 LiteLLM 第一次進 KEV——攻擊鏈已有完整紀錄

這次列入 KEV 之所以值得注意，在於它並非孤立事件。2026 年 6 月，CISA 就已將 LiteLLM 的指令注入漏洞 CVE-2026-42271（CVSS 8.7）列入同一份清單，理由同樣是證實遭到主動利用。而且這兩個漏洞不只是資料庫裡的鄰居：根據 The Hacker News 的報導，Horizon3.ai 在 6 月的報告指出，同批列入 9 月 2 日 KEV 的 Starlette 請求走私漏洞 CVE-2026-48710，可以與 CVE-2026-42271 串接，繞過身分驗證並對有漏洞的 LiteLLM 部署環境達成遠端程式碼執行（RCE）。

微軟同週發布的遙測資料，則補全了攻擊者入侵後實際做了什麼。利用這些漏洞闖入 LiteLLM 閘道的威脅行為者被觀測到：

• 透過 ELF 執行檔投放 XMRig 加密貨幣挖礦程式，事前還會先指紋識別主機並終止其他競爭中的挖礦程序
• 利用先前竊得的資料庫資訊，存取 LiteLLM 背後的 PostgreSQL 資料層
• 鎖定 LiteLLM 自身的資料表——LiteLLM_ProxyModelTable 與 LiteLLM_VerificationToken——竊取模型設定、上游供應商金鑰素材、供應商端點，以及代理發行的虛擬金鑰
• 修改 ~/.ssh/authorized_keys 以建立持久化存取

Wiz 另行將 Qilin（又稱 Agenda）勒索軟體組織與這條 LiteLLM 攻擊鏈的主動利用連結在一起。這是一個成熟攻擊面的完整生命週期：初始入侵、憑證竊取、挖礦、持久化、勒索——全部紀錄在同一套開源閘道上。

AI 基礎設施如今是靶子，而不只是工具

最關鍵的定性來自微軟與 Wiz 的共同結論：LiteLLM、Flowise、LangChain、Langflow、ChromaDB、Ollama、Marimo 以及各種 MCP 伺服器，已經成為竊取 API 金鑰、存取後端系統、維持持久化、執行提示注入與挖礦的「高價值目標」。

AI Weekly 對 9 月 2 日這批 KEV 的分析提出了一個值得複誦的結構性觀察：這是第一批 AI 基礎設施佔了將近一半的 KEV 梯次。而曝險問題比「沒修補的伺服器」更隱微。以 Starlette 為例，它幾乎從不直接出現在任何人的資產清冊上——它是作為 FastAPI 底下的傳遞依賴（transitive dependency）進場的，這意味著以採購為基礎的資產盤點根本看不見它。與此同時，這一批三個 AI 相關 CVE 的修補程式，在列入清單之前 56 到 99 天就已問世，卻沒有任何廠商遙測或研究歸因隨之而來。團隊不是忽視修補；而是修補對他們來說是隱形的，因為軟體本身就是隱形的。

還有一個讓人不自在的時間點對比。這個 LiteLLM 漏洞在野外存在的整個夏天，產業安全論述正被前沿模型事件佔據——失控代理群、沙箱逃脫、Hugging Face 資安事件。那些故事確實重要。但 9 月 2 日的 KEV 批次提醒我們：2026 年在營運層面真正遭到利用的 AI 漏洞，不是什麼新奇的代理失準案例，而是最無聊、有十年歷史的漏洞類型——不當授權、指令注入、請求走私——落在所有人匆忙之間裝起來的新基礎設施上。

現在該做什麼

對任何在跑 LiteLLM 的團隊來說，檢查清單很短，但沒有討價還價的空間：

1. 立即升級到 LiteLLM 1.84.0 或更新版本。 這會關閉 CVE-2026-59822。如果無法升級，先停用 MCP Streamable HTTP 端點，直到能升級為止。
2. 輪換閘道看得到的每一組憑證。 已被文件化的攻擊路徑會從資料庫層竊取上游供應商金鑰與虛擬金鑰。把任何修補前的曝險視為潛在金鑰外洩——輪換供應商 API 金鑰、虛擬金鑰與資料庫憑證。
3. 稽查持久化痕跡。 檢查 authorized_keys、cron 排程與執行中的程序，找出非預期的挖礦程式或 shell——已被記錄的後續動作很具體，也偵測得到。
4. 盤點你的傳遞依賴。 只要你的 AI 技術棧任何角落跑著 FastAPI，你就大概率跑著 Starlette。確認 CVE-2026-48710 是否與你有關——即使你從未直接選擇安裝 Starlette。
5. 把 AI 閘道視為生產級關鍵基礎設施。 它保管著組織所用每一個模型的金鑰。它值得與資料庫層相同的修補 SLA、網路分段與監控。

聯邦文職機構沒有選擇餘地——BOD 26-04 的期限具有約束力。其他所有人都應該把 9 月 16 日當成自己的期限。蜜罐證據已經擺在眼前：攻擊者此刻正在列舉 LiteLLM 端點，尋找那些從沒收到消息的閘道。