跳到正文
Wiz：Research（安全研究）·· 2026-09-10精選AI 評分80

Wiz 研究揭示 LiteLLM 認證繞過及雲端入侵風險

Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise

AI 導讀

Wiz 研究發現 LiteLLM 存在 MCP 認證繞過、自訂程式碼 guardrails 遠端程式碼執行漏洞，另指出 pass-through 端點可被管理員用於竊取雲端憑證。

推薦理由

研究將 LiteLLM 的 MCP 認證繞過、自訂程式碼 guardrails 遠端程式碼執行，以及 pass-through 雲端憑證風險分開分析，呈現 AI gateway 對雲端環境的延伸攻擊面。

正文 · 繁體中文

接近每 10 個公開可存取的 LiteLLM 實例中，就有 1 個接受預設主控金鑰，或完全毋須驗證。我們掃描約 3,000 個面向互聯網、部署了目前最受歡迎的開源 LLM 閘道的實例時，發現了這個情況。一般而言，這類暴露帶來的顧慮是 LLMjacking——有人利用憑證發出 API 呼叫，費用由你的帳戶支付——但我們想了解攻擊者能否造成更嚴重的後果：能否在主機上執行程式碼？此外，他們能否利用這點入侵更廣泛的環境？

我們決定使用 Claude Code 檢視 LiteLLM 的程式碼庫，尋找會接收用戶控制的輸入並將其傳入執行環境的功能。我們發現了多個問題，詳情如下。

主要發現：

  1. MCP 驗證繞過：透過 MCP 端點（CVE-2026-59822），任意 Bearer token 均可建立有效工作階段；已確認數百個面向互聯網的實例可受此漏洞攻擊。

  2. 驗證後以 root 權限遠端執行程式碼：透過 LiteLLM 的自訂程式碼防護機制（CVE-2026-59821）。

  3. 在本次研究進行時，3,074 個公開實例中有 9.6% 接受預設主控金鑰（sk-1234），或完全毋須驗證。在這些情況下，實際上無須驗證即可利用遠端程式碼執行漏洞。

  4. 預設未經驗證即可取得管理員權限 （未分配 CVE；與 CVE-2026-59821 一併修復）：未設定驗證時，所有用戶均獲授予 PROXY_ADMIN 存取權。

  5. 驗證後竊取雲端憑證的途徑：透過直通端點功能，因為該功能沒有驗證 URL。此問題不被視為漏洞，因此沒有修復，也沒有分配 CVE，意味著這種手法在驗證後的情況下仍可被利用。不過，與上述情況相似，若配合預設主控金鑰或缺少驗證，實際上無須驗證即可利用。

所有漏洞其後均已負責任地向 LiteLLM 披露，並已有修補程式可用。CVE-2026-59822 已列入 CISA 的「已知遭利用漏洞」目錄；我們亦透過蜜罐基礎設施觀察到該漏洞在野外遭到利用。這項研究此前曾於 DEF CON 34 上發表。

背景：LiteLLM 是甚麼？

LiteLLM 是一個開源 AI 閘道，為超過 100 個 LLM 供應商提供統一的 OpenAI 相容 API，包括 OpenAI、Anthropic、AWS Bedrock、Azure 和 Google Vertex AI。各機構會將 LLM 流量經由 LiteLLM 傳送，以便集中管理 API 金鑰、設定預算限制、套用防護機制、監察用量等。

根據 Wiz 的數據，LiteLLM 是最受歡迎的開源 AI 閘道之一，約三分之一的雲端環境都有使用。LiteLLM 可以儲存每個已設定 LLM 供應商的 API 金鑰、處理經它傳送的每個提示詞和回應，並透過 MCP 連接外部工具。LiteLLM 實例遭入侵，意味著 AI 基礎設施也遭入侵；正如我們將展示，往往連其所在的雲端環境也會受影響。

這類情況的傳統風險模型稱為 LLMjacking：攻擊者代表機構發出 API 呼叫，累積費用，並竊取已設定的供應商金鑰。雖然這確實是已在現實世界證實的風險，但 LiteLLM 不只是憑證儲存庫。它會在每次推理請求時執行伺服器端 Python，可將請求代理至任意內部 URL，並透過 MCP 連接內部工具和系統。因此，我們想了解攻擊者入侵實例後，除了濫用 API，實際上還能做甚麼。

搜尋攻擊路徑

我們使用 Claude Code，逐一檢視防護欄、直通端點、模型設定、Hook 系統和 MCP 層。當中有三項功能的攻擊面相當明顯：

  1. MCP 認證處理常式（user_api_key_auth_mcp.py）：為 Model Context Protocol 端點設置的獨立認證路徑

  2. 自訂程式碼防護欄（guardrail_endpoints.py）：管理員提交 Python 程式碼，由伺服器傳遞至 exec(compile(...))

  3. 直通端點（pass_through_endpoints.py）：將請求轉送至任意 URL、且不作驗證的代理路由

MCP 認證繞過（CVE-2026-59822）

LiteLLM 支援 MCP（Model Context Protocol），這是一種用於連接 AI 模型與外部工具及資料來源的標準。MCP 端點有自己的認證處理常式，與 LiteLLM 的主要認證機制分開。這項設計支援雙重認證模式：供直接用戶使用的 LiteLLM API 金鑰，以及供透過 GitHub 或 Atlassian 等上游供應商進行認證的用戶使用的 OAuth2 token 直通。原理很簡單——如果 Bearer token 不是有效的 LiteLLM 金鑰，就將它轉送至上游 MCP 伺服器，作為 OAuth2 token。

問題出在回退邏輯。當 token 未通過 LiteLLM 驗證時，處理常式不會區分「這是供上游供應商使用的合法 OAuth2 token」和「這完全是無效內容」。它會捕捉 401 錯誤，並在不作提示的情況下傳回空的認證物件——如同請求已完成認證般授予存取權：

這個分支會在任何帶有 Authorization 標頭的請求中觸發——所有一般 Bearer token 請求都帶有此標頭。任何無效 token 都會因驗證失敗而回傳 401，但處理常式仍會繼續執行，彷彿甚麼也沒有發生。如下所示，整個漏洞利用只需發出一個請求。請注意，Authorization: Bearer a（只包含一個字元）已足以建立一個完成認證的 MCP 工作階段：

攻擊者如何濫用 MCP 存取權？

攻擊者進入後，便可使用完整的 MCP 協定。不只是讀取操作，還能以任意參數執行工具。如果 MCP 伺服器提供資料庫查詢工具，攻擊者便可執行查詢。同樣地，如果伺服器連接 GitHub，攻擊者便可讀取程式碼庫及建立 issue。如果伺服器可以存取檔案系統，攻擊者便可讀取及寫入檔案。

攻擊者可連接哪些 MCP 伺服器，取決於機構如何設定這些伺服器。LiteLLM 支援 allow_all_keys 旗標，啟用後，所有用戶都能使用 MCP 伺服器，包括由認證繞過漏洞產生的空白憑證。LiteLLM 的文件建議，在「內部知識庫、日曆整合，或其他低風險工具中」使用此設定，讓每個團隊都能連線，而無須申請存取權。

此外，在內部部署 LiteLLM 的機構，更有可能將 MCP 伺服器連接至敏感系統：用於專案管理的 Jira、用於通訊的 Slack、存放業務資料的內部資料庫，以及用於部署自動化的 CI/CD 管道。這些環境依賴網絡層級的安全措施，並且通常會設定較廣泛的工具存取權限。這個驗證繞過漏洞讓攻擊者可直接存取這些已連接的敏感系統。

透過自訂程式碼護欄實現的驗證後根權限程式碼執行 (CVE-2026-59821)

LiteLLM 的護欄功能讓管理員可定義適用於每個 LLM 請求的政策，包括封鎖敏感提示詞、過濾輸出內容，以及執行合規規則。自訂程式碼護欄進一步擴展這項功能：管理員可編寫類似 Python 的程式碼，由伺服器在每次推理呼叫前或呼叫後執行。

原本的設計設有沙箱。網頁介面的「執行測試」按鈕會根據禁用模式清單驗證程式碼，並在執行前移除 __builtins__，以封鎖 import、os、subprocess 等內容。但註冊端點（POST /guardrails）沒有套用這兩項保護。

建立護欄時，伺服器會在 custom_code_guardrail.py 中呼叫 _compile_custom_code()：

這個流程缺少兩項檢查。第一，禁用模式檢查只會在測試端點執行；該檢查會封鎖 import、exec()、eval()、os、subprocess 及危險屬性。第二，測試端點會在執行前明確設定 exec_globals["__builtins__"] = {}，註冊端點則不會。若 __builtins__ 不存在，Python 會自動重新填入，因此提交的程式碼可使用完整的標準程式庫。

護欄註冊時，程式碼便會立即執行，因為 import os 和 os.popen('id') 會在初始化期間、任何 LLM 請求發出前執行。結果會儲存在 _cmd。攻擊者可傳送任何聊天完成請求來觸發護欄，並查看以封鎖原因形式返回的輸出：

PR #22095 修正了全部三個問題：

  1. 護欄端點現在要求 PROXY_ADMIN。CRUD 端點會明確檢查管理員角色，不再接受任何有效金鑰。

  2. 註冊時會正確執行沙箱限制。現在 exec() 流程會移除內建項目，並在編譯前執行禁用模式檢查，與測試端點的行為一致。

換言之，自訂程式碼護欄一律會在沙箱中執行，而且此功能現在全面受管理員權限限制，無論是否已設定驗證。這項修正封鎖了透過一般 API 金鑰或完全不使用金鑰來執行程式碼的途徑。這表示在較新版本中，攻擊者若要濫用此功能，必須取得管理員級別的存取權，而且只能在沙箱內執行程式碼。

—

請注意，上述 MCP 驗證繞過漏洞只會讓攻擊者存取 MCP 伺服器，不能用來利用這個驗證後 RCE 漏洞。

因此，考慮到這個漏洞本身只可由已驗證的管理員用戶利用，關鍵問題便是攻擊者在甚麼情況下能繞過驗證取得管理員權限，從而利用此漏洞；這就引出了接下來的兩個主題。

預設無需驗證即可存取管理員功能

LiteLLM 支援多種身份驗證機制：主密鑰（主要方法）、JWT/OAuth2，以及虛擬 API 金鑰。主密鑰是最常見的方法：它既是管理員憑證，也是身份驗證本身的開關。設定主密鑰後，所有 API 請求都必須附上有效密鑰。若未設定主密鑰（亦未設定 JWT/OAuth2），代理伺服器便完全不會啟用身份驗證，並接受所有請求。

修補前，這造成了兩個相互疊加的問題：

首先，未設定主密鑰時，LiteLLM 的身份驗證處理常式會全域將 PROXY_ADMIN 角色指派給每個傳入請求。這不只是「未經身份驗證的存取」，而是對整個代理伺服器的未經身份驗證*管理員*存取。

其次，即使已啟用身份驗證，防護機制的 CRUD 端點和設定更新端點（用於設定直通路由）都不要求 PROXY_ADMIN 角色。這兩者使用通用的身份驗證依賴項，只接受任何有效 API 金鑰，因此任何已通過身份驗證的用戶都能存取。

PR #22095 修正了預設角色（由 PROXY_ADMIN 改為 INTERNAL_USER），並在防護機制端點加入 PROXY_ADMIN 檢查。設定更新端點則在 v1.83.0 中另行修正（CVE-2026-35029）。

未更改的預設主密鑰

無論身份驗證是否正確設定，LiteLLM 的 主密鑰 都是代理伺服器的管理員憑證。不過，LiteLLM 不只用它進行 API 身份驗證，也會將它用作簽署工作階段 JWT 的 HS256 密鑰。這表示，除非用戶將其從預設值（sk-1234）更改，否則任何人都能偽造整個代理伺服器的任意用戶工作階段。LiteLLM 的文件在快速入門指南、Docker Compose 範例及設定教學中，都以 sk-1234 作為主密鑰範例；許多部署環境也從未更改這個預設值。

2026 年 2 月，我們掃描了約 3,000 個公開暴露的 LiteLLM 代理伺服器，並測試其身份驗證：

找到的實例總數： 3,074

接受預設密鑰：294  (9.6%)

↳ 其中完全沒有身份驗證：191  (6.2%)

近十分之一的實例接受預設主密鑰，或完全不要求身份驗證；而這只計算了 Shodan 上可見的實例。2026 年 8 月的後續掃描發現超過 85,000 個實例，但大多數似乎是蜜罐或測試部署。截至今日，透過 Docker compose 或 pip install 安裝 LiteLLM 時，預設主密鑰仍設定為 sk-1234。

根據 Wiz 的數據，三分之一的雲端環境都部署了 LiteLLM。還有更多實例位於企業網絡和 VPN 後方，內部攻擊者、已遭入侵的工作負載，或任何擁有叢集網絡存取權限的人都能存取這些實例。

在任何未更改預設主密鑰、同時運行易受 CVE-2026-59821 影響版本（v1.82.0 之前）的實例中，上述 RCE 漏洞都可直接利用：只需使用預設密鑰發出一次請求，即可取得容器的 root 權限，以及存取環境中容器可觸及的一切。在較新版本中，使用預設主密鑰進行身份驗證的攻擊者，只能濫用自訂程式碼防護機制，在沙盒中執行程式碼，如上所述。

然而，即使沒有利用任何漏洞，預設的主密鑰或未設定主密鑰，仍會讓攻擊者直接存取代理伺服器上設定的所有 LLM 供應商 API 金鑰。這會令攻擊者得以進行 LLMjacking——劫持組織的 LLM API 存取權，以該組織的預算執行工作負載。過往在實際環境中觀察到的 LLMjacking 攻擊，曾令受影響組織及雲端服務供應商蒙受數十萬美元損失。

—

除了 RCE 和 LLMjacking，我們接着想知道：如果攻擊者成功以管理員身分通過驗證，他們在更大的環境中能取得多大權限？

透過直通端點在驗證後攻陷雲端金鑰

事實證明，即使無需利用防護機制漏洞，主密鑰可提供的存取權限仍超出大多數人的預期。LiteLLM 設有直通端點功能，讓管理員建立代理路由，將請求轉發至任意網址。目標網址不會經過驗證；系統不會檢查網址是否指向私人 IP 範圍、本機主機或雲端中繼資料端點。管理員可以將直通端點指向 AWS 中繼資料服務，藉此外洩 IAM 憑證：

這種方法對 IMDSv1 和 IMDSv2 均有效。即使執行個體只支援 IMDSv2，LiteLLM 的標頭轉發機制仍能繞過它。任何以 x-pass- 開頭的標頭都會在移除前綴後轉發至目標，因此 x-pass-X-aws-ec2-metadata-token-ttl-seconds: 21600 到達 IMDS 端點時會變成 X-aws-ec2-metadata-token-ttl-seconds: 21600。這會令 IMDSv2 的防護措施失效。

LiteLLM 合理地採用管理員本質上可信的威脅模型，因此這項直通功能可説是按預期運作，並不被視為需要修補的漏洞。然而，若與預設憑證或驗證繞過漏洞一併出現，就會構成安全問題；而正如上文所述，預設憑證在實際環境中相當普遍，因此這種威脅模型往往已遭破壞。

另外值得一提的是，在 v1.83.0 之前，用來控制直通路由的設定更新端點完全不需要 PROXY_ADMIN。任何已通過驗證的用戶（不只是管理員）都可以設定任意直通端點。這項問題已獨立於防護欄 RCE 修復，並獲編配 CVE-2026-35029（與我們的研究無關）。

AI 閘道作為雲端攻擊面

在一般雲端部署中，LiteLLM 的服務帳戶具有權限，可在 Bedrock 或 Vertex AI 上呼叫模型、存取參數儲存服務中的密鑰，以及與其他雲端服務互動。因此，它對攻擊者而言是極具價值的目標，因為這能為攻擊者打開橫向移動的途徑，進而存取更大環境中的敏感資源。

我們認為，LiteLLM 的這些漏洞反映了一項更廣泛的挑戰：近年來，AI 閘道已成為關鍵基礎設施，卻沒有相應的安全控制措施。它們持有各個 AI 供應商的憑證、執行任意程式碼、透過 MCP 連接內部工具，並以廣泛的雲端權限運作，但其安全模型往往只依賴一個共用密鑰。

這個問題並非 LiteLLM 獨有。隨着組織採用 AI 閘道、模型服務平台和 Agent 框架，它們正在建立一類新的高權限基礎設施，處於應用程式程式碼與雲端服務之間。這裏的教訓是，這些系統應被視為 Tier-1 安全資產，而非開發者工具。

修復措施

如果你正在使用 LiteLLM，我們建議採取以下措施：

  • 使用強度高且獨有的主密鑰，不要使用 sk-1234 或其他預設值

  • 檢查意外項目的防護措施，並重新啟動程序以清除記憶體

  • 稽核直通端點並限制容器的對外網絡流量

  • 套用最低權限 IAM 角色（IRSA 或同等方案）

Wiz 如何提供協助

Wiz 客戶已受到保護。Wiz 會自動偵測雲端環境中的 LiteLLM 部署，並標示有漏洞的版本、設定錯誤的驗證機制，以及暴露於外的管理端點。

  • Wiz Vulnerability Scanner 會偵測容器映像檔和執行中工作負載內有漏洞的 LiteLLM 版本。

  • Wiz Runtime Sensor 會偵測 LiteLLM 容器內的異常程式碼執行，例如 Python 執行環境意外啟動程序。

  • Wiz ASM 會找出可能在標準佈建流程以外設置的影子 LiteLLM 部署。

Wiz 客戶可使用Wiz Threat Intel Center內預先建立的查詢和公告，搜尋環境中的相關實例。

負責任披露時間表

2026-02-18  發現 RCE 漏洞並向 LiteLLM 維護者通報

2026-02-25  發布 RCE 及沙盒逃逸修正版本（v1.82.0）

2026-04-25  發布 MCP 驗證繞過修正版本（v1.84.0）

2026-07-07 在 Wiz 蜜罐中觀察到 CVE-2026-59822 遭利用

2026-07-08  公佈 CVE-2026-59821（RCE）和 CVE-2026-59822（MCP 驗證繞過）

2026-09-02 將 CVE-2026-59822 加入 CISA KEV

來源：Wiz：Research（安全研究） · wiz.io

#論文/研究#MCP/工具調用