LiteLLM 是一款廣泛使用的開源 AI 閘道（AI Gateway），它的核心作用是作為一個中繼站，讓開發者可以用統一的 OpenAI 相容介面，去調用超過一百種不同的模型供應商（如 Anthropic, Gemini, Azure 等）。簡單來說，它幫企業統一管理 API 金鑰、配額與路由。
然而，近期 Obsidian Security 研究人員發現了一個嚴重的漏洞鏈，攻擊者僅需一個低權限極低的帳號，就能透過三個漏洞的組合，最終奪取整個伺服器的控制權（RCE）。
漏洞鏈的運作邏輯：從低權限到最高控制權
這次的攻擊並非單一漏洞造成，而是三個漏洞像接力賽一樣串接在一起。對於工程師來說，這是一個典型的權限管理失效案例。
第一步：繞過授權（CVE-2026-47101） 在 LiteLLM 中，一般使用者可以生成虛擬 API 金鑰。系統提供了一個名為 allowed_routes 的欄位，用來限制該金鑰能訪問哪些路徑。然而，系統在儲存這個欄位時沒有進行權限校驗，導致低權限使用者可以直接在請求中填入萬用字元（例如 ["/*"]）。這樣一來，原本應該被限制在一般路徑的金鑰，竟然獲得了訪問管理員專屬路徑的權限。
第二步：權限提升（CVE-2026-47102） 一旦繞過了路徑限制，攻擊者就可以訪問到 /user/update 這個端點。這個端點原本設計是用來讓使用者修改個人資料的，但它缺乏對寫入欄位的限制。攻擊者只要在請求中將自己的 user_role 修改為 proxy_admin，系統就會直接接受並儲存。至此，一個普通使用者成功「晉升」為系統管理員。
第三步：沙箱逃逸與遠端程式碼執行（CVE-2026-40217） LiteLLM 提供了一個自定義守衛欄（Custom Code Guardrail）功能，允許管理員編寫 Python 程式碼來過濾 AI 的輸入或輸出。雖然這在功能上很強大，但實作上直接使用了 Python 的 exec() 函數且缺乏有效的過濾。攻擊者可以利用 Python 內部機制繞過限制，直接呼叫 os.system 等指令，從而建立反向 Shell（Reverse Shell），完全接管伺服器。
被接管後的實際影響：不只是洩漏金鑰
如果 LiteLLM 伺服器被攻破，其影響範圍遠超想像，因為它處於 AI 流量的咽喉位置。
首先是機密洩露。攻擊者可以獲取所有配置的模型供應商 API 金鑰（如 OpenAI, Anthropic 等）、用於解密憑據的鹽值（Salt Key）以及資料庫連接字串。這意味著所有經過此閘道的對話紀錄、包含個資或原始碼的 Prompt，全部對攻擊者透明。
其次是中間人攻擊（MITM）與回應篡改。這是最危險的部分。攻擊者不需要對 AI 模型進行 Prompt Injection（提示詞注入），而是直接利用 LiteLLM 的回呼機制（Callback）在傳輸過程中修改 AI 的回覆。例如，當開發者詢問 AI 時，攻擊者可以將 AI 的正常回答替換成一個偽造的工具調用指令（Tool Call），誘導開發者的本地端執行惡意指令。
維運建議與防禦對策
針對此漏洞，建議所有使用 LiteLLM 的團隊立即採取以下行動：
更新版本。請務必升級至 v1.83.14-stable 或更新版本，此版本已修復上述漏洞鏈。
權限審計。重新檢查所有擁有 proxy_admin 權限的帳號。在 AI 閘道架構中，管理員權限等同於伺服器主機的 Root 權限，必須極其謹慎。
檢查隱藏配置。檢查 config.yaml 中的 litellm_settings.callbacks 區塊。由於回呼函數不會顯示在管理介面中，它是攻擊者在取得 RCE 後最喜歡隱藏後門的地方。
憑據輪替。如果懷疑伺服器曾被入侵，請立即更換所有供應商 API 金鑰、資料庫密碼以及 MCP（Model Context Protocol）相關的 Token。
總結
這次事件提醒我們，當系統設計將 權限校驗（Authorization）與 執行環境（Execution Environment）過度信任時，會產生巨大的安全漏洞。LiteLLM 的案例顯示，即使單一漏洞看似可控，但一旦形成漏洞鏈，低權限使用者也能迅速變成系統掌控者。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。