在企業部署生成式 AI 的過程中，為了統一管理多個模型供應商（如 OpenAI, Anthropic 等）的 API 金鑰並管控使用量，通常會部署 AI 閘道器（AI Gateway）。LiteLLM 作為一款流行的開源 AI 閘道器，扮演著應用程式與後端模型供應商之間的中繼站。然而，根據 Wiz Research 的最新調查發現，許多對外公開的 LiteLLM 伺服器存在嚴重的配置錯誤，最顯著的問題在於大量系統仍在使用官方設定指南中的範例管理員金鑰 sk-1234。
背景與預設金鑰風險
LiteLLM 的管理員金鑰（Master Key）在系統中扮演雙重角色：它既是管理員的身分驗證憑證，也是啟動身分驗證功能的開關。在較舊的版本（1.82.0-stable 之前）中，如果啟動時未設定管理員金鑰，系統會將所有傳入請求視為具有完整管理權限。
Wiz Research 在 2 月份的掃描中發現，在 3,074 個對外公開的 LiteLLM 閘道器中，有 294 個接受 sk-1234 這個範例金鑰。其中 191 個伺服器甚至完全沒有設定金鑰，導致任何請求都能通過驗證。這意味著攻擊者只要嘗試範例金鑰，就能輕易獲取該伺服器的最高管理權限。
管理權限的擴散影響
一旦攻擊者取得管理權限，其影響範圍將遠超 AI 模型的呼叫。首先，管理員可以讀取伺服器上儲存的所有模型供應商 API 金鑰，這會導致 LLMjacking 攻擊，即攻擊者利用受害者的金鑰來運行自己的模型工作負載，由受害者買單。其次，管理員能監控所有經過閘道器的提示詞（Prompt）與回應，導致企業機密洩漏。
更嚴重的風險在於雲端基礎設施的權限外洩。LiteLLM 提供一種透傳端點（Pass-through Endpoint）功能，允許管理員將請求轉發到任何指定的 URL。由於該功能未對私有地址或雲端元數據服務（Instance Metadata Service, IMDS）進行限制，攻擊者可以將路徑指向雲端平台的元數據服務，藉此讀取該伺服器所擁有的 IAM 角色憑證（Identity and Access Management credentials）。即使伺服器啟用了 IMDSv2，攻擊者仍可利用 LiteLLM 的標頭處理機制繞過限制，最終獲取雲端帳戶的存取權限。
程式碼執行漏洞與爭議
除了配置錯誤，LiteLLM 過去還存在多個嚴重的程式碼執行漏洞。例如 CVE-2026-59821 涉及自定義守衛軌道（Guardrail）的檢查繞過，允許攻擊者在容器內執行 Python 程式碼。雖然 LiteLLM 官方將其評級為低風險（CVSS 2.1），認為這需要高權限帳號才能觸發，但 Wiz 研究員指出，在沒有設定管理員金鑰或使用預設金鑰的情況下，任何外部攻擊者都能輕易獲得該權限，從而實現 root 等級的程式碼執行。
此外，另一個漏洞 CVE-2026-40217 允許攻擊者逃逸沙箱（Sandbox Escape），在預設的 Docker 映像檔中以 root 權限執行指令。而在 7 月份被 CISA 列入已知被利用漏洞清單的 CVE-2026-59822，則允許未經身分驗證的攻擊者透過任何隨意的 Bearer Token 建立 MCP（Model Context Protocol，模型上下文協定）會話，進而存取組織連接的內部工具伺服器。
實務影響與防禦建議
微軟在 8 月份的案例分析中證實，攻擊者已利用 CVE-2026-42271 與 CVE-2026-48710 的漏洞鏈，在 LiteLLM 閘道器中執行指令，讀取環境變數中的管理員金鑰與資料庫連線字串，進而竊取 PostgreSQL 資料庫中的模型與虛擬金鑰紀錄。這證明了 AI 閘道器在現代架構中應被視為 Tier-0 的最高機密儲存庫。
針對上述風險，建議採取以下措施：
第一，立即將管理員金鑰從 sk-1234 更改為長且隨機的字串。這是最簡單且最有效的防禦手段，無需升級版本即可完成。
第二，將 LiteLLM 升級至 1.84.0 或更高版本，以修復上述所有已知的 CVE 漏洞。若暫時無法升級，應在反向代理或 API 閘道器層級封鎖 /mcp/ 路徑及相關的測試端點。
第三，實施最小權限原則。限制容器的對外網路存取，並為其分配權限最窄的雲端 IAM 角色，以防止即便管理權限被奪取，攻擊者也無法透過元數據服務獲取雲端帳戶權限。
最後，若懷疑系統已被入侵，僅僅升級版本是不夠的。必須檢查是否有未經授權的守衛軌道設定，清除記憶體中的執行碼，並全面輪換（Rotate）所有模型供應商金鑰、管理員金鑰以及資料庫憑證。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。