對於許多開發者來說，LiteLLM 是一個非常方便的 AI 閘道器（AI Gateway），它可以讓我們用統一的格式去呼叫不同廠商的 LLM API。但近期發現的 CVE-2026-42271 漏洞提醒我們，當系統允許使用者定義執行環境時，如果缺乏嚴格的權限控管，將會帶來極其危險的後果。
指令注入漏洞的成因
這次問題的核心在於 LiteLLM 提供的 MCP（Model Context Protocol）伺服器測試功能。MCP 是一種讓 AI 模型能與外部工具或資料庫互動的標準協定。為了讓開發者在正式儲存設定前能先測試連線，LiteLLM 提供了兩個 API 端點：POST /mcp-rest/test/connection 以及 POST /mcp-rest/test/tools/list。
這兩個端點允許使用者在請求主體中傳入伺服器配置，其中包含 command（指令）、args（參數）以及 env（環境變數）。當 LiteLLM 使用 stdio 傳輸模式嘗試建立連線時，它會直接將這些傳入的指令作為子程序（subprocess）在主機上執行。
簡單來說，這就像是程式碼裡直接呼叫了類似 shell_execute 的函數，而輸入內容卻來自於使用者的 API 請求。如果攻擊者傳入惡意的 shell 指令，系統就會以執行 LiteLLM 程序的權限直接執行該指令，這就是典型的 Command Injection（指令注入）。
從驗證漏洞到完全失控的連鎖反應
原本這個漏洞被定義為需要驗證（Authenticated），也就是攻擊者必須持有有效的 API Key 才能觸發。雖然這降低了風險，但對於內部使用者或持有低權限金鑰的人來說，依然能藉此取得主機控制權。
然而，真正的危機在於這個漏洞可以與另一個名為 CVE-2026-48710 的漏洞進行鏈接（Chaining）。後者是一個影響 Starlette（一個輕量級的 ASGI 異步伺服器框架，LiteLLM 依賴它來處理 HTTP 請求）的 Host Header 驗證繞過漏洞。
攻擊者可以透過操縱 HTTP 請求中的 Host 標頭，欺騙系統繞過身分驗證機制。當這兩個漏洞結合在一起時，原本需要 API Key 才能觸發的指令注入，變成了不需要任何憑證就能執行的 Unauthenticated RCE（未經認證的遠端程式碼執行）。這將漏洞的嚴重程度直接推升至 CVSS 10.0 的最高等級。
實際影響與工程風險
一旦攻擊者成功執行 RCE，他們不僅能控制運行 LiteLLM 的伺服器，還能獲取儲存在該閘道器中的所有模型供應商憑證與 API Key。由於 AI 閘道器通常處於內部網路的核心位置，攻擊者可以將其作為跳板，進一步橫向移動到其他連通的 AI 基礎設施或下游系統中。
對於維運工程師來說，這類漏洞凸顯了兩個關鍵的安全性原則：第一，絕對不要將使用者輸入直接傳遞給系統 shell 或子程序執行；第二，身分驗證不應僅依賴單一層級，對於高風險操作（如執行測試指令）應要求最高權限（例如 PROXY_ADMIN 角色）。
修復建議與緩解措施
目前最根本的解決辦法是立即更新版本。LiteLLM 應更新至 1.83.7 或更高版本，Starlette 則應更新至 1.0.1 或更高版本。
若因環境限制無法立即更新，建議採取以下臨時緩解措施：
首先，在反向代理（Reverse Proxy）或 API 閘道層級直接封鎖 /mcp-rest/test/connection 與 /mcp-rest/test/tools/list 這兩個端點的 POST 請求。
其次，限制網路存取權限，僅允許受信任的網路分段存取該服務。
最後，檢查系統日誌中是否有異常的 Host 標頭請求或不尋常的子程序執行紀錄，並在確認安全後輪替（Rotate）所有儲存在代理伺服器中的 API 金鑰與憑證。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。