觀點 · 資訊分享
Python AI 服務常用的 Starlette、LiteLLM 漏洞遭利用：CISA 列管，快升 1.0.1 與 1.84.0
CISA 把 Starlette 的 Host 標頭漏洞與 LiteLLM 的 MCP 驗證繞過列入已遭利用清單。前者讓路徑檢查被騙過，後者用假金鑰就能叫用 MCP 工具，自架 Python API 與 AI 閘道的人要先查版本。
- 發布
- 2026-09-03
- 篇幅
- 約 5 分鐘 · 2,228 字
- 結構
- 7 節 + 3 題常見問題
- 標籤
一句話看懂：Python 網頁框架 Starlette 和 AI 閘道 LiteLLM 各有一個漏洞已被拿來攻擊，美國 CISA 在 9 月 2 日列管，自架 FastAPI 服務或 LiteLLM 的人要立刻查版本。
先用白話講：這兩個漏洞是什麼？
Starlette 的漏洞像是大樓警衛只看信封上的地址決定能不能進，但郵差其實照門牌送。有人在信封上亂寫地址，警衛以為要去「大廳」就放行，信卻被送進「機房」。
LiteLLM 的漏洞則像是門禁卡刷錯了，系統沒有拒絕，反而換了一張「空白訪客證」放你進去，讓你能使用裡面的工具。
- Starlette：輕量的 Python 網頁框架，FastAPI 就建在它上面
- LiteLLM：AI 閘道，用同一種格式代理呼叫各家大型語言模型，也能接 MCP 工具
發生什麼事
CISA（美國網路安全暨基礎設施安全局）在 9 月 2 日一次把 7 個漏洞加進「已知遭利用漏洞清單」（KEV），其中兩個跟開發者特別有關：
- CVE-2026-48710（Starlette）：1.0.1 以前沒檢查 HTTP 的 Host 標頭，就拿它拼回網址。攻擊者在 Host 裡塞
/、?這類符號，就能讓程式讀到的路徑跟實際被執行的路徑不同。CVSS 3.1 分數 6.5 - CVE-2026-59822（LiteLLM）：1.84.0 以前的 MCP 端點，驗證失敗時會走一條後備路線，結果換成一個空的身分物件放行。帶一個編造的 Authorization 標頭，就能列出並呼叫設定好的 MCP 工具。CVSS 4.0 分數 8.8
CISA 要求聯邦機關在 9 月 16 日前處理，也提到 Starlette 這個漏洞可以跟另一個漏洞 CVE-2026-42271 串連。
該怎麼因應
| 你在用 | 先做什麼 |
|---|---|
| FastAPI 或 Starlette | 升到 Starlette 1.0.1 以上，檢查權限判斷是不是靠 request.url.path |
| LiteLLM 代理伺服器 | 升到 1.84.0 以上；不能馬上升就關掉 MCP 路由或在反向代理擋 /mcp/ |
| 前面有 Nginx 等反向代理 | 確認它會拒絕格式錯誤的 Host，別信任 X-Forwarded-Host |
給開發者的技術細節
Starlette 的官方公告舉了一個例子，請求實際打的是 /foo：
GET /foo HTTP/1.1
Host: example.com/abc?bar=
路由照真正的路徑跑到 /foo，但程式重組出來的網址是 http://example.com/abc?bar=/foo，request.url.path 讀到的是 /abc。如果中介軟體寫「/admin 開頭才要登入」，這個檢查就被騙過了。修正版會依 RFC 規定檢查 Host 格式，不合格就改用 scope["server"]。
- 權限判斷建議改用路由本身或
scope裡的原始路徑，不要用重組後的網址 - 補充來源 OSTIF 特別點名：直接用 uvicorn 等伺服器對外、前面沒有符合 HTTP/1.1 規範的反向代理，就屬於受影響的情況
我的看法
這兩個漏洞都不是什麼冷門專案，而是 Python AI 服務最常見的地基。很多人用 FastAPI 包一個模型 API、再用 LiteLLM 統一管各家金鑰，可能根本沒意識到自己在用 Starlette。
我會建議做兩件事：第一，把相依套件版本鎖檔拿出來看，別只看 FastAPI 的版本；第二，LiteLLM 這種手上握有一堆模型金鑰和工具權限的閘道，本來就不該直接對外，至少放在需要驗證的反向代理後面。MCP 讓 AI 能動手做事，驗證一旦出包，影響就不只是「多花一點 token」而已。
名詞小辭典
- CISA KEV：美國 CISA 維護的「已知遭利用漏洞清單」，列進去代表已經有實際攻擊。
- Host 標頭：瀏覽器送請求時告訴伺服器「我要找哪個網站」的欄位。
- MCP（Model Context Protocol）：讓 AI 模型呼叫外部工具與資料的開放協定。
- CVSS：漏洞嚴重程度的評分，滿分 10 分，越高越嚴重。