LiteLLM 兩項漏洞修補指南：CVE-2026-35029、CVE-2026-59823

LiteLLM 是一個開源 LLM 閘道，每月約有 100,000 名開發人員下載，讓應用程式透過它連接 OpenAI、Anthropic、Google 及其他所有模型供應商。Check Point 的 AI Agent 安全團隊在當中發現兩個漏洞，足以瓦解整套安全模型：缺少授權檢查，讓任何用戶都能成為管理員並執行程式碼（CVE-2026-35029）；伺服器端請求偽造漏洞則會暴露閘道儲存的所有供應商 API 金鑰（CVE-2026-59823）。兩個漏洞都已在 LiteLLM 1.83.9 修復。如果你有運行 LiteLLM，尤其是用它作為 n8n AI Agent 的前置服務，本文會提供檢查、修補、輪替和審核的四步程序。

兩個 CVE 實際造成的影響

LLM 閘道位於你的應用程式與模型供應商之間。與其讓每個工作流程直接呼叫 OpenAI 的 API，不如把所有請求交由閘道轉送至適當的後端。LiteLLM 正是這樣的代理伺服器，能集中管理憑證、日誌記錄和使用情況追蹤。集中管理正是採用閘道的目的，也正因如此，這些漏洞格外危險。

CVE-2026-35029 是缺少授權檢查。安全性中的授權機制，負責判斷「這個用戶是否獲準執行此操作？」LiteLLM 的執行階段設定端點缺少這項檢查，因此任何已登入的用戶，即使只有最低權限，也能修改閘道的執行階段設定。根據 Check Point 的調查結果，這可導致系統遭全面接管：攻擊者能存取檔案、竊取憑證，並透過從雲端儲存空間載入的惡意 Python 模組遠端執行程式碼。Check Point AI Agent 安全研究主管 Mateo Rojas-Carulla 直言，任何在有漏洞的部署中持有帳戶的人，都能接管閘道。

CVE-2026-59823 是伺服器端請求偽造（SSRF）漏洞。SSRF 是指攻擊者誘使你的伺服器，向他們指定的目標發出網絡請求。在這裏，攻擊者可重新導向閘道發出的請求，也就是承載你的 OpenAI、Anthropic 和 Google API 金鑰的請求，將它們導向攻擊者控制的目的地。本應是 AI 技術堆疊中最集中管理、最受保護的秘密的金鑰，就這樣落入攻擊者手中。

Check Point 透過協調式披露流程披露了這兩個漏洞，而 LiteLLM 已在 1.83.9 版本推出修補程式；任何早於 1.83.9 的版本都受影響。

為何 Agent 建置者需要留意

如果你自行架設 n8n，LiteLLM 很可能已在你的技術堆疊之中：它是讓所有 AI Agent 節點使用同一個 OpenAI 相容端點的自然選擇，並支援備援、負載平衡和統一帳單。這裏的危險在於影響範圍：遭入侵的 LLM 閘道洩漏的不是一個金鑰，而是所有金鑰，包括 OpenAI、Anthropic、Gemini，以及你設定的其他服務。與攻擊者暗中使用外洩金鑰不同，閘道遭接管會讓攻擊者取得持續性的立足點：他們可以在主機上執行程式碼、讀取檔案，並進一步橫向移動。

Black Duck 資深研發經理 Christopher Jess 指出，這種情況令人痛心地熟悉：缺少權限檢查，讓低權限用戶得以使用管理功能，最終導致程式碼執行。他警告，隨着 AI 普及速度加快，安全基本原則正被視為次要事項；而集中管理所有 AI 存取權限的閘道，尤其是有價值的攻擊目標。

一句話總結：存放所有模型 API 金鑰的盒子，竟讓任何用戶都能撬開鎖，取走整串金鑰。

先決條件

可存取 LiteLLM 執行環境的 Shell（Docker 主機、VPS，或裝有 pip install litellm 的電腦）
LiteLLM 版本號碼（步驟 1 會説明如何查找）
LiteLLM 介面及 AI 供應商控制台的管理員權限（用於輪換金鑰）
有權重新啟動閘道容器或程序

步驟 1 - 檢查 LiteLLM 版本

這些漏洞影響所有早於 1.83.9 的 LiteLLM 版本。先找出目前執行的版本。

如果你在 Docker 中執行 LiteLLM，請使用 exec 進入容器：

docker exec <your-litellm-container> pip show litellm 2>/dev/null | grep -E "Name|Version"

如果你透過 pip 安裝，也可以在主機上檢查：

pip show litellm | grep -E "Name|Version"

你應會看到類似 Version: 1.83.9 的 Version: 行。任何低於 1.83.9 的版本都易受攻擊 — 請立即繼續步驟 2。如果你使用的是 1.83.9 或更新版本，修正已包含在內；請跳至步驟 4，並仍然進行審核，因為如果你曾執行舊版，這些漏洞就曾存在於你的版本歷史中。

步驟 2 - 升級至 LiteLLM 1.83.9 或更新版本

拉取修正版本並重新啟動。透過 Docker Compose 安裝的話：

cd /path/to/your/litellm-compose
docker compose pull
docker compose up -d
docker exec <your-litellm-container> pip show litellm | grep Version

pip show 的輸出必須顯示 1.83.9 或更高版本。透過 pip 安裝的話，請直接升級現有安裝：

pip install --upgrade "litellm>=1.83.9"

之後重新啟動 LiteLLM 程序 — 修正位於應用程式碼中，因此仍在執行的舊程序在重新啟動前仍易受攻擊。

警告：升級無法抹去已經發生的事。如果你不能完全信任的帳戶曾可連線至閘道，就必須執行步驟 3 的金鑰輪換，不能視之為可選項目。

步驟 3 - 輪換閘道中儲存的所有供應商 API 金鑰

CVE-2026-59823 會暴露 LiteLLM 儲存的 API 金鑰。輪換金鑰是指在供應商處建立全新金鑰，並在閘道讀取金鑰的所有位置以新金鑰取代舊金鑰，令任何被竊取的副本失效。

在每個供應商控制台（OpenAI、Anthropic、Google AI，以及任何其他已設定的供應商）建立新的 API 金鑰。
更新 LiteLLM 讀取的環境變數或設定檔 — 通常是在你的 .env 或 Docker Compose 檔案中的 OPENAI_API_KEY、ANTHROPIC_API_KEY、GEMINI_API_KEY 等變數。
在供應商處撤銷舊金鑰，避免它們在已外洩的情況下被使用。
重新啟動閘道，讓它載入新的設定值。

檢查供應商控制台，確認舊金鑰已失效：已撤銷的金鑰應顯示為非作用中或已刪除；設定新金鑰後，LiteLLM 健康狀態端點仍應正常回應。

步驟 4 - 審核帳戶，並確認權限確實有執行限制

Check Point 明確提出的建議同樣適用於此處：由於任何帳戶都可能利用這些漏洞，請檢視哪些用戶可存取閘道，並移除不再需要存取權限的帳戶。在 LiteLLM 介面中列出用戶及其角色，並清理任何過時項目 — 例如已離隊的隊友、測試帳戶及共用憑證。

接着進行能及早發現這個漏洞的權限檢查：以低權限用戶身分登入，並嘗試存取僅限管理員使用的端點（應測試執行階段設定修改路徑）。如果低權限帳戶可以變更任何管理員範圍內的項目，代表你的角色權限控管仍有漏洞 — 修正已解決這兩個 CVE，但只有實際驗證權限，才能防止下一個遺漏的檢查造成損害。

最後，將閘道納入日常資安工作：把 LiteLLM 納入定期漏洞掃描和滲透測試，與網絡應用程式及雲端基礎設施一併檢查。閘道是高價值目標，正是因為它們集中管理機密資料。

棘手情況與限制

本指南只涵蓋已報告且已修補的 CVE，不會審核你的 LiteLLM 部署是否存在其他設定錯誤，例如管理介面向互聯網開放、使用預設登入憑證，或 API 金鑰權限範圍過寬。如果你的閘道曾面向互聯網，請假設曝露範圍更廣，並檢查披露前後一段時間的存取記錄，留意有否異常的設定變更（Check Point 的詳細文章於 October 13, 2026 發佈）。目前沒有已公開、可免除升級的替代方案；修補是唯一解決方法。

我也未有核實 LiteLLM 中受影響呼叫所使用的確切端點路徑——至於你所用環境中的具體 API 路徑，請以官方公告和你所用版本的實際行為為準，而非本文。

常見問題

如果我只使用 LiteLLM 的 Python SDK，不使用代理伺服器，會受影響嗎？

披露的漏洞針對 LiteLLM 代理／閘道伺服器；該伺服器會為多名用戶提供服務，並儲存供應商金鑰。只在本機使用 SDK，而且不會向其他用戶開放伺服器，並不屬於本文所述的攻擊情境——但只要你有運行代理伺服器，就應檢查所用版本。

這些漏洞會直接影響 n8n 內置的 AI 節點嗎？

不會。漏洞影響的是 LiteLLM 本身。不過，如果你的 n8n 工作流程連接至自行託管的 LiteLLM 端點，你的 Agent 發出的每次模型呼叫都會經過這個有漏洞的元件——因此這也是 n8n 建置者需要關注的問題。

修補程式推出前，漏洞有被積極利用嗎？

Check Point 的報告和我看過的報道都沒有確認漏洞曾在實際環境中遭利用。話雖如此，漏洞詳情已於 October 13, 2026 公開，而且任何帳戶持有人都能輕易利用漏洞——為安全起見，應假設目前已有攻擊者正在探測曝露的實例。

重點摘要

LiteLLM 1.83.9 之前的版本存在兩個嚴重漏洞：CVE-2026-35029（缺少授權驗證 → 任何用戶都可取得管理員權限並遠端執行程式碼）和 CVE-2026-59823（伺服器端請求偽造 → 所有供應商 API 金鑰都會曝露）。
立即升級至 1.83.9 或更新版本，然後重新啟動閘道——在重新啟動之前，正在運行的程序仍然有漏洞。
輪替閘道儲存的所有供應商 API 金鑰；在供應商處撤銷舊金鑰，才能真正令已被盜用的金鑰失效。
清理閘道帳戶，並以低權限用戶測試權限——設定的權限與實際執行的權限之間的落差，正是這類漏洞的根源。
在安全措施中，將 AI 閘道視為高價值目標：它們持有 Agent 執行所有操作所需的金鑰。

接下來：如果你的 LiteLLM 面向互聯網，請檢查存取記錄，留意 10 月中旬前後有否由非預期帳戶作出的設定變更。另外，趁你查看閘道設定時，也要確認管理介面完全無法從公共互聯網連線——這是另一項曝露風險，利用這些 CVE 並不需要這項條件，但卻是攻擊者接下來會嘗試的目標。

來源：Infosecurity Magazine（報道 Check Point 的披露，Oct 15, 2026）。

圖片：Pexels（免費授權）。

原文刊載於 CortexFlow。免費 n8n 範本：https://cortexflow.tech/templates/