LiteLLM 指令注入漏洞拍檔 Starlette 跳過驗證，AI 基建大門中門大開

兩個端點都會喺 JSON 請求主體度接收一個完整嘅 MCP 伺服器設定，包括 stdio 傳輸會用嘅 Cmd（指令）、args（參數）同 env（環境變數）欄位 。當一個已經登入嘅用戶呼叫呢兩個端點是但一個嗰陣，LiteLLM 就會拎住提供嘅 Cmd 值，喺主機上面產生一個子程序出嚟執行，而且行嗰陣係用緊同 LiteLLM 代理程序一樣嘅作業系統權限 。

最初 BerriAI 公佈呢個係一個要登入先用到嘅遠程執行指令漏洞——攻擊者需要一個有效嘅 API 密鑰先去到呢啲端點，而且佢哋冇做角色權限檢查去限制邊個可以呼叫呢啲端點。即係話，就算係一個低權限嘅內部用戶，只要有任何一個有效嘅代理 API 密鑰，就可以喺主機上面執行任意指令 。但個故事未完。

Starlette 嘅 BadHost 跳驗證漏洞，令到連登入都唔使

第二個漏洞係 CVE-2026-48710，研究員幫佢改咗個花名叫「BadHost」。呢個係 Starlette 框架嘅 Host 頭驗證漏洞。Starlette 係一個輕量級嘅 ASGI 框架，FastAPI、vLLM 同成千上萬嘅 Python 網頁應用程式都係用佢做底層——包括 LiteLLM 。所有由 0.8.3 到 1.0.0 版本嘅 Starlette 都受影響 。

根本原因係 Starlette 點樣將傳入嘅請求路由出去，同佢點樣為應用程式邏輯重組網址，兩者之間有個解析分歧 。ASGI 路由層會用請求嘅原始 HTTP 路徑去判斷邊個端點處理佢。但係 request.url——即係應用程式中介軟件同裝飾器（decorator）見到嗰個網址——係透過將原始嘅 Host 頭值同請求路徑直接拼埋一齊重建出嚟嘅，中間冇做過適當嘅驗證 。

透過喺 Host 頭度注入好似 ? 或者 # 呢啲 URI 權威部分同路徑部分之間嘅分隔字符，攻擊者可以令到 request.url.path 睇起嚟同實際上路由咗嘅路徑完全唔同 。中介軟件會見到一個好似 / 咁人畜無害嘅路徑，而路由器就喺背後將個請求轉送去真正嘅目標端點。任何信任 request.url.path 去做路徑驗證嘅中介軟件，都可以好簡單咁俾人繞過 。

將兩個漏洞夾埋：由 8.7 分變成 10.0 分

LiteLLM 嘅身份驗證裝飾器（decorator）係透過檢查 request.url.path 嚟判斷一個請求需唔需要有效嘅 API 密鑰。BadHost 跳驗證漏洞俾攻擊者可以操控嗰個網址，令到身份驗證中介軟件見到一個唔需要登入嘅路徑，但同時 ASGI 路由器就將個請求派送去其中一個有指令注入漏洞嘅 MCP 端點度 。

咁樣就移除咗企喺互聯網同任意指令執行之間嘅唯一一道存取控制關卡。一個冇憑證、事先冇任何網絡存取權限嘅攻擊者，只需要發送一個精心製作嘅 HTTP 請求，就可以完全繞過身份驗證，並且喺 LiteLLM 代理主機上面執行作業系統指令 。Horizon3.ai 證實呢個完整嘅漏洞鏈係行得通嘅，並且因為佢達到唔使登入就遠程執行指令嘅效果，所以將佢哋夾埋嘅 CVSS 評分定為最高嚴重性嘅 10.0 分 。

攻擊者攞到呢個權限可以做啲乜

一旦利用成功，攻擊者就可以用 LiteLLM 代理程序嘅權限去執行指令。由呢度開始，威脅面就會極速擴大：

• 任意指令執行： 攻擊者可以安裝後門程式、惡意軟件、加密貨幣挖礦程式，或者任何主機程序權限容許嘅軟件 。
• 大規模憑證盜竊： LiteLLM 代理伺服器坐喺應用程式同幾十個 LLM 供應商之間。佢會喺數據庫或者環境變數度儲存住 OpenAI、Anthropic、Azure、AWS Bedrock、Google 同其他連接咗嘅服務嘅 API 密鑰 。利用呢個漏洞，攻擊者可以一次過就偷走晒所有儲存咗嘅憑證。
• 透過 AI 基建橫向移動： 有咗盜返嚟嘅雲端 API 密鑰同代理主機嘅 Shell 存取權，攻擊者可以轉向攻擊其他連接咗嘅服務，例如內部 MCP 伺服器、向量數據庫同下游嘅 AI 代理框架 。
• 更廣泛嘅生態系統影響： Starlette 嘅 BadHost 漏洞影響超過 40 萬個依賴佢嘅項目，包括 FastAPI 應用程式、vLLM 伺服器、MCP 伺服器部署同 AI 代理框架。任何呢啲喺 1.0.1 版本之前嘅 Starlette 上面用咗基於路徑嘅身份驗證中介軟件嘅項目，都同樣曝露喺身份驗證繞過嘅風險之下 。

點解 CISA 嘅舉動令到件事更加緊急

CISA 喺 2026 年 6 月 8 號將 CVE-2026-42271 加入「已知被利用漏洞」（KEV）目錄，證實咗呢個漏洞唔係理論上嘅風險——攻擊者已經喺度積極利用緊佢 。根據《約束性操作指令 22-01》，所有美國聯邦民事行政部門機構必須喺指定嘅修復時間框架內修補 KEV 目錄上面列出嘅漏洞。CISA 亦強烈建議所有公私營機構，都將 KEV 目錄嘅新增項目視為緊急修補嘅優先事項 。

即刻要做嘅補救步驟

要修復呢個連鎖漏洞，需要喺兩方面做更新，再加埋幾項縱深防禦措施去應對憑證洩露嘅問題：

1. 將 LiteLLM 升級到 1.83.7 版本或之後。 呢個版本移除咗 MCP 測試端點直接執行用戶提供指令嘅功能，徹底堵塞咗指令注入呢個攻擊途徑 。
2. 將 Starlette 升級到 1.0.1 版本或之後。 呢個修補程式會根據網址規範驗證傳入嘅 Host 頭，並且忽略包含無效字符嘅頭，防止嗰種造成身份驗證繞過嘅路徑混淆技倆 。
3. 立即更換所有儲存過嘅憑證。 你要假設 LiteLLM 代理伺服器儲存過嘅任何 API 密鑰、存取權杖或數據庫憑證都已經外洩。更換所有 OpenAI、Anthropic、Azure、AWS 同其他供應商嘅密鑰，並且檢查賬單儀表板有冇未經授權嘅使用記錄 。
4. 喺反向代理或 WAF 度封鎖呢啲端點。 作為推出修補程式期間嘅縱深防禦措施，設定你嘅反向代理或網頁應用程式防火牆，喺請求到達應用程式之前，丟棄任何去

   POST /mcp-rest/test/connection

   同

   POST /mcp-rest/test/tools/list

   嘅請求 。
5. 追溯審計有冇未經授權嘅存取。 檢查 LiteLLM 代理日誌，睇下有冇喺 MCP 測試端點上面嘅異常活動，特別係嚟自唔尋常 IP 位址嘅請求，或者嗰啲 Host 頭俾人做過手腳嘅請求 。

綜合 CVSS 10.0 嘅最高嚴重性、現實世界中嘅積極利用，同埋 CISA 嘅 KEV 認證，所有運行緊 LiteLLM 或者 Starlette 驅動服務嘅機構，都應該將呢次事件視為一次緊急嘅「修補同更換憑證」行動。由積極利用到憑證外洩之間嘅窗口，已經打開咗。