【關鍵漏洞警報】AI 閘道 LiteLLM 與框架 Starlette 雙漏洞串連，造就滿分遠端代碼執行危機

原本設計的用意很貼心：讓你在儲存設定前，先測試一下 MCP 伺服器能不能通。但問題在於，這兩個端點會接收包含 Cmd、args 與 env 欄位的完整伺服器設定，為了進行測試，伺服器會直接在 主機上 將你提供的 Cmd 當作子程序（Subprocess）執行起來，而且權限等同於 LiteLLM 代理伺服器本身 。

這代表，駭客只要有一組有效的 LiteLLM 金鑰（即使是低權限的內部測試帳號），就能夠在主機上執行任何指令，權限等同於該代理程式的執行程式。原本這個被列為高風險，CVSS 評分 8.7，前提是「需要驗證」 。

第二個缺口：偷天換日的身分繞過術

駭客若想省去找金鑰的麻煩，就得靠另一個名為「BadHost」的漏洞 CVE-2026-48710。這個漏洞藏在 Starlette 框架裡——這是一個輕量級的 Python ASGI 框架，不僅是 LiteLLM 的底層，更是 FastAPI、vLLM 等無數 AI 基礎服務的核心支柱，受影響的衍生專案超過 40 萬個 。

它的原理說穿了是一種「路徑混淆」攻擊。當伺服器收到 HTTP 請求時，核心路由是依據「原始請求路徑」來決定該交給誰處理。然而，Starlette 在重建程式看得懂的 request.url 時，會直接拿「Host 標頭」的內容去拼接，中間缺乏嚴格的驗證 。

駭客只要在 Host 標頭內塞入像 ? 或 # 這類特殊字元，就能讓負責檢查身分的驗證中介層看到一條「無害的路徑」（例如 /），同時底層的 ASGI 路由器卻把請求導向了真正危險的端點

POST /mcp-rest/test/connection

致命的串連：從 8.7 變成 10.0 的滿分危機

當這兩個漏洞結合在一起時，產生了最嚴重的後果：

1. 攻擊者利用 BadHost 漏洞（CVE-2026-48710），發送一個帶有惡意 Host 標頭的請求。這個請求騙過了 LiteLLM 的身分驗證中介層，讓系統誤以為這是個不需要身分認證的請求 。
2. 請求實際上送達了 LiteLLM 的測試端點（CVE-2026-42271）。因為沒有了驗證保護，攻擊者在沒有帳號、沒有密碼、沒有任何金鑰的情況下，直接對端點注入惡意的主機命令 。
3. 伺服器執行命令。駭客取得 LiteLLM 代理伺服器當下的執行權限，完全控制了主機。

Horizon3.ai 的研究團隊實證，這條攻擊鏈一打就通，合併風險評級直接給了 CVSS 10.0 的滿分，也就是最高等級的嚴重性 。

災難性的後果：不只是被入侵，而是被洗劫

成功發動此攻擊的駭客，能做的事情遠比單純植入後門可怕得多：

1. 任意指令執行，主機變肉雞

駭客可以立刻在機器上安裝惡意軟體、加密貨幣挖礦程式，或者用其作為跳板進行內部網路探測 。

2. 大型語言模型金鑰庫存大失血

這是最致命的商業損失。LiteLLM 作為 AI 閘道，串接了 OpenAI、Anthropic、Azure、AWS Bedrock 等數十間服務商的 API 金鑰。駭客一旦進入，就能一次撈走資料庫或環境變數裡儲存的所有金鑰 ，隨即可能發動驚人的帳單攻擊，或者盜用你的 AI 額度。

3. 橫向移動攻佔 AI 供應鏈

拿到雲端權限與內部金鑰後，駭客可以輕易地從閘道主機橫向移動（Lateral Movement）到企業內部的 MCP 伺服器、向量資料庫、甚至是下游的 AI 代理人框架，將整個 AI 基礎設施變成自己的遊樂場 。

緊急應變：三件你現在必須做的事

CISA 已強制要求美國聯邦機構限期內修補，並強烈建議所有民間企業將此視為最高緊急修補事件 。以下是你的行動清單：

1. 立即更新 LiteLLM：將版本升級至 1.83.7 或更新版本。此版本直接移除了端點動態執行指令的能力，修復了命令注入的核心問題 。
2. 立即更新 Starlette：將版本升級至 1.0.1 或更新版本。這個修補會驗證 Host 標頭的合法性，阻斷路徑混淆攻擊 。
3. 輪換所有金鑰（這一步最關鍵！）：不要抱持僥倖心態。假設你的 OpenAI、Anthropic、Azure 或任何其他 LLM 提供商的 API 金鑰「全都已經外洩」。請立刻到各家供應商的後台，將舊金鑰作廢並換發新的 。

除此之外，建議在修補程式的空窗期，先於反向代理（Reverse Proxy）或網站應用程式防火牆（WAF）直接阻擋以下兩個路徑的 POST 請求：

• /mcp-rest/test/connection
• /mcp-rest/test/tools/list

這一切並非虛構的理論威脅，這是一場正在進行式的真實攻擊。在這個漏洞面前，沒有帳號密碼的保護，你的 AI 大門形同敞開。