// 威脅簡報

CVE-2026-59822已遭實際利用

LiteLLM Proxy MCP 閘道認證繞過:隨便一組 token 都能呼叫 MCP 工具

CVSS: 8.2 HIGH
CISA KEV: 2026-09-02
弱點類型: CWE-287 · CWE-306
主題: AI 安全

PlainCVE 團隊 · 發布 2026-09-23 · 更新 2026-09-24 · AI 輔助 · 媒體簡報 ↓

人工審稿 2026-09-23指令測試:未提供漏洞重現:未進行驗證紀錄 ↓

LiteLLM Proxy 的 MCP 端點在驗證失敗時沒有拒絕請求,反而以匿名身分放行;不需帳號就能列出並呼叫背後串接的 MCP 工具。已遭實際利用。

誰會中	使用 LiteLLM Proxy 1.84.0 以前、設定了 MCP 伺服器,且 MCP 路由可從不受信任的網路連到的組織。
後果	攻擊者可以透過閘道操作你串接的 MCP 工具與服務,例如讀寫工單、程式庫或資料庫,能做到什麼取決於你接了哪些工具。
現在該做什麼	升級 litellm 到 1.84.0 以上。無法立即升級時,在反向代理或 API 閘道擋掉 /mcp/ 相關路徑。查看依據(4) 廠商 / 維護者BerriAI 安全公告:升級到 1.84.0 以上We recommend upgrading to 1.84.0 or later.github.com 廠商 / 維護者BerriAI 安全公告:無法立即升級時,在反向代理或 API 閘道停用或封鎖 /mcp/ 相關端點If upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at your reverse proxy or API gateway.github.com 研究團隊Skycloak 建議輪替閘道持有的所有上游模型供應商金鑰;這是研究者的建議,官方沒有提供輪替指引skycloak.io 本站判斷檢查紀錄時先排除轉送到 OAuth2 伺服器的正常請求、有可疑存取才輪替受影響 MCP 伺服器的憑證,是本站參考 Skycloak 整理的回應建議,官方沒有提供偵測指引
受影響版本	1.84.0 以前的所有版本查看依據(3) 廠商 / 維護者BerriAI 安全公告:MCP 端點可用任意 Bearer token 建立已認證的 MCP 工作階段,影響 1.84.0 以前LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token.github.com CVE 紀錄CVE 紀錄:1.84.0 以前受影響Prior to 1.84.0, LiteLLM's MCP Streamable HTTP endpoint allowed an unauthenticated attacker to use a fabricated Authorization headercve.org 廠商 / 維護者BerriAI 安全公告:攻擊者能列出並呼叫已設定的 MCP 工具,所以要有設定 MCP 伺服器才有工具可被操作An attacker could use this to list and call configured MCP tools and access connected services exposed through MCP.github.com
修好的版本	1.84.0 以上查看依據(3) 廠商 / 維護者BerriAI 安全公告:1.84.0 已修補The issue is fixed in 1.84.0.github.com 廠商 / 維護者litellm v1.84.0 發布說明收錄修補 PR #26463fix(mcp): tighten public-route detection and OAuth2 fallback gatinggithub.com CVE 紀錄CVE 紀錄:1.84.0 已修補This issue is fixed in version 1.84.0.cve.org
CVSS 向量	顯示完整向量 `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N`
時間點	漏洞出現 2026-02-07 · 1.81.9 發布，首個含 PR #20602 的版本來源首次公開 2026-06-30
CISA KEV	已列入(2026-09-02),代表已有實際攻擊案例查看依據(3) CERT / 政府CISA 在 2026-09-02 依實際遭利用的證據把它列入 KEVbased on evidence of active exploitationcisa.gov 研究團隊Wiz 的誘捕系統觀察到針對這個漏洞的實際利用We observed exploitation of this vulnerability in our honeypotswiz.io 本站判斷有新聞稱這是第一個被列入 KEV 的 MCP 相關漏洞;CISA 本身沒有這樣表述,本站不採用這個說法

藍隊應對手冊

確認、修補 / 緩解、應變、強化。版本符合受影響條件不等於已被入侵;檢查沒有結果也不等於安全,每一項都有能證明與不能證明的範圍。標記的步驟對應下方攻擊流程裡可以擋下攻擊的那一步。

DETECT確認我受影響嗎?有沒有入侵跡象?

01確認版本與曝險條件
LiteLLM Proxy 1.84.0 以前、設定了 MCP 伺服器、MCP 路由可從不受信任的網路連到,三者同時成立才受影響。
唯讀查詢
```
pip show litellm | grep -i '^version'
```
02找出曾被利用的跡象
先排除轉送到設定為 OAuth2 的 MCP 伺服器的正常請求(這類 token 本來就不是 LiteLLM 金鑰,修補後仍合法放行)。再調查沒有設定 OAuth2 的目標是否接受了不認得的 token、是否有異常的工具呼叫,以及上游服務的授權結果。單憑「token 對不到 LiteLLM 金鑰卻成功」一個條件不足以判定遭入侵。
步驟 2 步驟 3

MITIGATE修補 / 緩解先修補;還不能修補時先擋住

01升級到 1.84.0 以上
修補後只有所有目標伺服器都設定為 oauth2 時才允許轉送,其餘一律拒絕。
會變更環境
```
pip install -U "litellm>=1.84.0"
```
步驟 3
02還不能升級:在反向代理封鎖 /mcp/
官方建議:在反向代理或 API 閘道停用或封鎖 /mcp/ 相關端點。
步驟 1

RESPOND應變發現入侵跡象時

01輪替串接服務的憑證
確認有可疑存取時,輪替受影響 MCP 伺服器的憑證;Skycloak 另建議輪替閘道持有的上游模型供應商金鑰。這是 PlainCVE 整理的預防性建議,不代表已確認金鑰外洩;官方未提供輪替指引。
步驟 4

HARDEN強化長期避免同類問題

01不要讓 AI 閘道直接暴露在網際網路
步驟 1
02每個 MCP 工具用最小權限的憑證
就算閘道被繞過,攻擊者能做的事也有限。
步驟 4

完整修復步驟與說明

升級。 pip install -U "litellm>=1.84.0",或更新 Proxy 的 Docker 映像檔到對應版本。
無法立即升級時。 官方建議:在反向代理或 API 閘道停用或封鎖 /mcp/ 相關端點。
確認是否曾被利用。 官方沒有提供偵測或輪替指引,以下是 PlainCVE 的回應建議(參考 Skycloak 的分析)。檢查 MCP 端點的紀錄時,先排除轉送到設定為 OAuth2 的 MCP 伺服器的請求:這類 token 本來就不是 LiteLLM 金鑰,修補後也仍然合法放行。接著調查:沒有設定 OAuth2 的目標是否接受了不認得的 token、是否有異常的工具呼叫,以及上游服務那一側的授權結果。不要單憑「token 對不到 LiteLLM 金鑰卻回傳成功」這一個條件就啟動全面的憑證輪替。確認有可疑存取時,輪替受影響 MCP 伺服器的憑證;Skycloak 另建議輪替閘道持有的所有上游模型供應商金鑰。這是預防性做法,不代表已確認金鑰外洩。
通用原則。 AI 閘道不要直接暴露在網際網路;每個 MCP 工具用最小權限的憑證。

攻擊流程

從左到右是攻擊發生的順序。藍色盾牌代表這一步可以被擋下,越早擋下越好。點圖示可看細節。

圖片可自由用於報導與教學,採 CC BY 4.0,圖上已附出處。

攻擊者
帶著一組隨便編的 token 呼叫 MCP 端點
不需要任何 LiteLLM 帳號或金鑰。
防禦: 反向代理或 API 閘道限制 /mcp/ 只允許內部網路存取。
你的系統
LiteLLM 驗證這組 token,失敗
正常情況下應該在這裡回傳 401。
你的系統
驗證失敗被當成「OAuth2 轉送」放行
舊版假設失敗的 token 是要轉給上游 MCP 伺服器的 OAuth2 token,於是用空白的匿名身分繼續處理,而且對所有 MCP 伺服器都這樣做。
防禦: 升級到 1.84.0+,只有設定為 oauth2 的伺服器才允許這種轉送,其餘一律拒絕。
外部
攻擊者列出並呼叫串接的 MCP 工具
設定為 allow_all_keys 的伺服器更會直接開放給匿名身分。
防禦: 只串接必要的 MCP 工具,並給每個工具最小權限的憑證。

影響範圍

條件	是否受影響
LiteLLM Proxy 1.84.0 以前 + 設定了 MCP 伺服器 + MCP 路由對外可達	受影響
LiteLLM Proxy 1.84.0 以上	已修補
只把 litellm 當 Python SDK 呼叫模型、沒有跑 Proxy	官方公告描述的是 Proxy 的 MCP 端點
跑 Proxy 但沒有設定任何 MCP 伺服器	沒有可被呼叫的 MCP 工具,但仍建議升級

原理

LiteLLM Proxy 可以放在多個 MCP 伺服器前面當閘道。有些上游 MCP 伺服器使用自己的 OAuth2 登入,所以 LiteLLM 需要把使用者的 OAuth token「轉送」過去,而不是當成 LiteLLM 自己的金鑰來驗證。

2026 年 2 月加入的一段相容邏輯處理得太寬:只要請求帶了 Authorization 標頭、但 LiteLLM 自己的金鑰驗證失敗,程式就假設這是一個要轉送的 OAuth2 token,用一個空白的匿名身分繼續處理。這個假設套用在所有 MCP 伺服器上,不只是真的設定成 OAuth2 的那些。

結果就是:隨便編一組 token,驗證失敗,卻被放行。 這種錯誤稱為「失敗即開放」(fail-open),對應 CWE-287(認證不當)與 CWE-306(關鍵功能缺少認證)。

有問題的思路(概念示意,不是原始程式碼):

展開程式碼範例(python)

try:
    identity = verify_litellm_key(token)
except AuthError:
    # 驗證失敗 → 當成要轉送的 OAuth2 token,用匿名身分繼續
    identity = AnonymousIdentity()

修好的思路:

展開程式碼範例(python)

try:
    identity = verify_litellm_key(token)
except AuthError:
    # 只有「所有目標伺服器都明確設定為 oauth2」才允許轉送,其餘一律拒絕
    if targets and all(s.auth_type == "oauth2" for s in targets):
        identity = AnonymousIdentity()
    else:
        raise

同一個修補也修了另一個問題:判斷「公開路徑」(.well-known)時比對了整個網址含查詢字串,而不是只看路徑。

時間軸

日期	事件
2026-02-06	加入 OAuth2 轉送相容邏輯(PR #20602),問題由此產生
2026-04-30	修補 PR #26463 合併
2026-05-14	釋出 v1.84.0
2026-06-30	GitHub 安全公告公開
2026-07-08	CVE 公開
2026-08-27	Wiz 發表 AI 基礎設施誘捕系統研究,觀察到實際攻擊流量
2026-09-02	CISA 列入已知遭利用漏洞清單

驗證紀錄已人工審稿、核對來源;尚未在我們的環境重現

人工審稿	2026-09-23

驗證紀錄只寫環境與結果,不公開重現步驟或可攻擊他人系統的程式。詳見政策.

來源

其他1.81.9 released, first version with PR #20602 · pypi.org · 查閱 2026-09-24
安全公告GHSA-7488-6r32-c95q — MCP Authentication Bypass via OAuth2 Passthrough Fallback · BerriAI(GitHub), 2026-06-30 · 查閱 2026-09-23
CVE / NVD / OSVCVE-2026-59822 Record · CVE Program, 2026-07-08 · 查閱 2026-09-23
CVE / NVD / OSVNVD - CVE-2026-59822 · NIST · 查閱 2026-09-23
NVD 的 CVSS 3.1 為 8.2;CNA(GitHub)的 CVSS 4.0 為 8.8。
安全公告CISA Adds Seven Known Exploited Vulnerabilities to Catalog · CISA, 2026-09-02 · 查閱 2026-09-23
修補 commit / 版本fix(mcp): tighten public-route detection and OAuth2 fallback gating(PR #26463) · BerriAI(GitHub), 2026-04-30 · 查閱 2026-09-23
修補 commit / 版本litellm v1.84.0 release · BerriAI(GitHub), 2026-05-14 · 查閱 2026-09-23
修補 commit / 版本fix(mcp): resolve OAuth2 'Capabilities: none' bug for upstream MCP servers(PR #20602) · BerriAI(GitHub), 2026-02-06 · 查閱 2026-09-24
研究文章CVE-2026-59822: LiteLLM's MCP Auth Bypass, and the Second Bug in the Same Fix · Skycloak, 2026-09-21 · 查閱 2026-09-24
研究文章Inside 90 days of attacks on AI infrastructure · Wiz Research, 2026-08-27 · 查閱 2026-09-23

媒體簡報

一句話

LiteLLM 是許多公司用來統一管理 AI 模型呼叫的開源閘道。它負責串接外部工具的 MCP 功能有一個認證缺陷:驗證失敗的請求會被當成合法請求放行。美國 CISA 已在 2026 年 9 月 2 日將它列入已知遭利用漏洞清單。修補版 1.84.0 已於 5 月釋出。

關鍵數字

嚴重度: CVSS 3.1 8.2(NVD) nvd.nist.gov
列入 CISA KEV: 2026-09-02 cisa.gov
修補版本: 1.84.0(2026-05-14 釋出) github.com
安全公告公開: 2026-06-30 github.com

已確認

驗證失敗的請求會以匿名身分放行,影響 LiteLLM Proxy 1.84.0 以前的 MCP 端點。
CISA 已將它列入已知遭利用漏洞清單。
Wiz 的誘捕系統研究觀察到針對 AI 基礎設施的實際攻擊流量。

尚未確認 / 說法不一

有新聞稱這是第一個被列入 KEV 的 MCP 相關漏洞,CISA 本身沒有這樣說。
官方公告沒有說上游模型供應商的 API 金鑰會被讀取,本頁不做此推論。

可引用的一句話

這個漏洞的問題不在密碼太弱,而在於門鎖壞掉時,門是打開的,而不是鎖住的。

圖片

下載分享圖(PNG) · 攻擊流程圖(可下載)

引用時請標示「PlainCVE」並附上本頁連結。完整引用格式見下方「如何引用本頁」。有事實錯誤請回報.

LiteLLM Proxy MCP 閘道認證繞過:隨便一組 token 都能呼叫 MCP 工具

LiteLLM 是許多公司用來統一管理 AI 模型呼叫的開源閘道。它負責串接外部工具的 MCP 功能有一個認證缺陷:驗證失敗的請求會被當成合法請求放行。美國 CISA 已在 2026 年 9 月 2 日將它列入已知遭利用漏洞清單。修補版 1.84.0 已於 5 月釋出。

關鍵數字:
- 嚴重度:CVSS 3.1 8.2(NVD)(https://nvd.nist.gov/vuln/detail/CVE-2026-59822)
- 列入 CISA KEV:2026-09-02(https://www.cisa.gov/news-events/alerts/2026/09/02/cisa-adds-seven-known-exploited-vulnerabilities-catalog)
- 修補版本:1.84.0(2026-05-14 釋出)(https://github.com/BerriAI/litellm/releases/tag/v1.84.0)
- 安全公告公開:2026-06-30(https://github.com/BerriAI/litellm/security/advisories/GHSA-7488-6r32-c95q)

已確認:
- 驗證失敗的請求會以匿名身分放行,影響 LiteLLM Proxy 1.84.0 以前的 MCP 端點。
- CISA 已將它列入已知遭利用漏洞清單。
- Wiz 的誘捕系統研究觀察到針對 AI 基礎設施的實際攻擊流量。

尚未確認 / 說法不一:
- 有新聞稱這是第一個被列入 KEV 的 MCP 相關漏洞,CISA 本身沒有這樣說。
- 官方公告沒有說上游模型供應商的 API 金鑰會被讀取,本頁不做此推論。

「這個漏洞的問題不在密碼太弱,而在於門鎖壞掉時,門是打開的,而不是鎖住的。」— PlainCVE
https://plaincve.date/vulns/cve-2026-59822-litellm-mcp-auth-bypass

如何引用本頁

本文採 CC BY 4.0,轉載請保留署名與連結。

PlainCVE 團隊(2026)。《LiteLLM Proxy MCP 閘道認證繞過:隨便一組 token 都能呼叫 MCP 工具》。PlainCVE。https://plaincve.date/vulns/cve-2026-59822-litellm-mcp-auth-bypass(查閱日期:YYYY-MM-DD)

BibTeX

@misc{cve202659822litellmmcpauthbypass2026,
  title  = {LiteLLM Proxy MCP 閘道認證繞過:隨便一組 token 都能呼叫 MCP 工具},
  author = {PlainCVE 團隊},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/vulns/cve-2026-59822-litellm-mcp-auth-bypass},
  note   = {更新於 2026-09-24}
}