LiteLLM 代理被爆 Host 標頭繞過驗證：多數部署有前置防護不受影響，建議升到 1.84.0

一句話看懂：LiteLLM 代理有個靠特製 Host 標頭繞過驗證的漏洞，官方說多數有前置防護的部署不受影響，但仍建議升到 1.84.0。

先用白話講：這個漏洞是什麼？

想像大樓櫃台有兩個人：一位負責「查證件」，另一位負責「帶你去哪一層樓」。正常情況下，兩個人聽到的是同一個目的地。但如果訪客用一種特別的說法，讓查證件的人聽成「去一樓大廳」，帶路的人卻聽成「去頂樓辦公室」，就能繞過檢查。

LiteLLM 的情況很像：驗證層判斷的「你要存取哪個路由」，和實際被分派的路由，可能被一個特製的 Host 標頭搞得不一致。

發生什麼事

• 漏洞編號 CVE-2026-49468，GitHub 公告發布於 2026 年 6 月 16 日，標示為嚴重，CVSS 9.8
• 成因：驗證層在 get_request_route() 依 request.url.path 取得路由，而 Starlette 會依 Host 標頭重組這個值；特製的 Host 可能讓驗證閘道看到的路由，與 FastAPI 實際分派的路由不同
• 影響：特定條件下，可能在未驗證的情況下存取受保護的管理路由
• 修補：1.84.0，不需要更改設定

誰比較危險？

官方強調多數部署不受影響。只要代理前面有下列任何一種會驗證或標準化 Host 的元件，這個繞過就會被擋下：

• CDN 或 WAF（例如 Cloudflare）
• 設定了 server_name 白名單的反向代理
• 依主機名稱路由的負載平衡器

官方也說 LiteLLM 雲端客戶不受影響。風險比較高的是：自架、直接把 LiteLLM 開在網際網路上、前面什麼檢查都沒有的情況。

給開發者的技術細節

• 受影響版本：1.84.0 之前；修補版：1.84.0（官方 release 為 v1.84.0）
• 不能馬上升級時，官方的建議是把代理放在會驗證或標準化 Host 標頭的元件後面
• 排查建議（我的整理，不是官方清單）：確認自己的 LiteLLM 是否直接對外、前面的反向代理是否限制了允許的 Host 名稱
• 後續日期：NVD 在 2026 年 6 月 22 日才收錄這個 CVE，但 GitHub 公告早在 6 月 16 日就已發布

我的看法

自架 LiteLLM 或類似的 AI 閘道，很多人是「先跑起來再說」，反向代理設定也常常複製貼上。這次的漏洞提醒我：Host 標頭看起來很不起眼，卻可能是驗證邏輯的一環。

好消息是，只要前面有一層正常設定的反向代理，風險就低很多。我自己的習慣是：任何對外的服務，前面一定先放一層只允許自己網域的反向代理，再把內部管理路由限制在內網。這次剛好驗證了這個習慣是對的。當然，最直接的處理仍然是升到 1.84.0。

名詞小辭典

• Host 標頭：HTTP 請求裡標明「你要找哪個網站」的欄位。
• 反向代理：站在伺服器前面接客的服務，可以先檢查、轉發請求。
• 認證繞過：不用正確的登入資訊，就通過驗證存取受保護的功能。
• LLM 閘道：集中管理各家 AI 模型呼叫的中間服務，處理金鑰、用量與權限。

資料來源

• GitHub Advisory：LiteLLM Authentication Bypass via Host Header Injection
• LiteLLM Release v1.84.0