Starlette BadHost 漏洞打中 AI agent：香港自架 MCP／FastAPI 要即查

圖：Ars Technica．原文連結

一個放喺 Python web stack 底層嘅 Starlette 漏洞，今次之所以引起保安圈同 AI infra 圈緊張，唔係因為佢有幾新奇，而係因為佢撞正而家最熱門嘅自架 AI agent、MCP server、OpenAI-compatible proxy 同 LLM gateway。Ars Technica 報道指，Starlette 開發者稱套件每星期有 3.25 億次下載，而 FastAPI、vLLM、LiteLLM 等大量服務都直接或間接踩住呢層。對香港公司嚟講，呢件事唔係「外國開源套件又有 CVE」咁簡單，而係內部 AI 工具、試驗用 VM、VPN 後面嘅 MCP endpoint，可能一早變咗有價值入口。

漏洞名叫 BadHost，編號係 CVE-2026-48710。最重要嘅一句係：受影響 Starlette 版本喺處理 request.url 時，冇先驗證 HTTP Host header，令 request.url.path 有機會同 ASGI server 真正收到、真正 routing 嘅 path 唔一致。如果一個 FastAPI／Starlette app 用自製 middleware 根據 request.url.path 去決定邊啲 path 要登入、邊啲 path 可公開，就有機會畀人繞過。呢個漏洞唔等於每個 FastAPI app 都即刻穿，但一中就通常係 auth bypass，而 AI infra 後面往往就係 API key、工具權限同外部 SaaS token。

Host header 由門牌變錯路牌

正常 HTTP request 入面，Host header 係用嚟講明目標 host，而 path 係 request line 入面另一個部分。X41 D-Sec 嘅 advisory 指出，舊版 Starlette 會將 scheme、Host header 同 path 拼返成一條 URL，再由 URL parser 拆返 request.url.path。問題係，如果 Host 入面出現本來唔應該存在嘅 path／query／fragment 分隔字元，Starlette routing 仍然會按真正 request path 去執行 endpoint，但 middleware 睇到嘅 request.url.path 可能已經變咗另一個 path。換句話講，門口保安睇錯路牌，入面個辦公室照樣開門。

官方 GitHub advisory 將問題列為 GHSA-86qp-5c8j-p5mr，影響 starlette <= 1.0.0，修補版本係 1.0.1，CVSS v3 分數 6.5、級別係 Moderate。X41 另一邊就列明已確認受影響範圍為 starlette >= 0.8.3, < 1.0.1，用 CVSS v4 計到 7 分、評為 High；BadHost 掃描頁同部分第三方文章更形容為 critical。呢度要分清：官方基礎套件評級係 Moderate，但當下游 endpoint 係 key management、model control、tool execution、SSRF 入口，實際風險可以遠高過一個普通 web route。

AI agent 點解特別食正

Starlette 本身係輕量 ASGI framework，FastAPI 就建基於 Starlette；vLLM 提供 OpenAI-compatible HTTP server，LiteLLM proxy 又常用嚟將多個模型供應商包成統一 API。呢類服務嘅共通點係：一個 endpoint 往往控制模型存取、用量、budget、tenant routing、provider key，甚至連接內部資料庫、文件系統、電郵、calendar 或 ticketing 系統。以前一個 admin API 穿咗，可能只係改設定；而家 AI agent 後面有 tools，權限可以由「睇資料」一路去到「代人做動作」。

MCP 令件事再敏感。Model Context Protocol 嘅 HTTP authorization spec 要求支援 OAuth Protected Resource Metadata，用 WWW-Authenticate 等 discovery 流程畀 client 找到授權伺服器。呢個設計本身係為咗互通同安全，但亦代表 MCP server 常常會有一啲可預測、未登入都會回應嘅 discovery endpoint。當 custom middleware 用 path allowlist／denylist 做保安判斷時，BadHost 呢類 path confusion 就可能將「應該只係公開 discovery」同「真正受保護工具」扯埋一齊。對 agent backend 嚟講，呢個唔係 prompt injection，而係更底層嘅 HTTP 邊界錯判。

唔係所有 FastAPI 都同一個風險

呢點要講清楚：用 FastAPI 唔代表必然中招。風險集中喺自製 middleware、raw ASGI middleware、decorator 或其他權限邏輯，以 request.url 或 request.url.path 作保安決定。BadHost 掃描頁亦特別指出，FastAPI 標準 Depends()／Security() 路線通常係綁住實際 route 執行，而唔係靠 middleware 讀一條重建 URL path 去判斷，所以同一類風險較低。不過，香港好多內部工具都會貪快寫一層 middleware：「/health 放行，其他要 token」、「/admin 擋住」、「/metrics 只畀內部網段」；正正係呢種快捷寫法最需要查。

補鑊重點：版本、middleware、入口

第一步係將 Starlette 升到 1.0.1 或以上。Starlette 1.0.1 release note 寫明修補係「構建 request.url 時忽略 malformed Host header」；PyPI 目前已見更新版本 1.1.0，但保安基準至少係 1.0.1。只喺開發機 pip install -U 唔夠，因為好多 AI 工具係 Docker image、poetry／uv lockfile、vendor bundle、GPU VM snapshot 或 managed notebook 入面固定咗依賴。要重新 build、重新 deploy，再喺實際 runtime 驗證 import 出嚟嘅 Starlette 版本。

• 搜尋 codebase 入面所有 request.url、request.url.path、URL(scope=...)，特別係 middleware、auth、rate limit、audit、tenant routing。
• 如必須喺 middleware 睇 path，改用 ASGI scope 入面嘅原始 path，例如 request.scope["path"]，避免依賴由 Host 重建出嚟嘅 URL。
• 將權限檢查盡量放返 endpoint／route level，例如 FastAPI dependency 或 Starlette endpoint auth，而唔係靠 path 字串扮閘口。
• 避免將 Uvicorn、Hypercorn、Daphne、Granian 呢類 ASGI server 直接暴露出街；用 Nginx、Apache、Caddy、Traefik、HAProxy、Cloudflare 等反向代理喺前面先擋 malformed Host。
• 有 HTTP/3／QUIC、Cloudflare tunnel、內部 ingress、service mesh 嘅部署，要逐條入口驗證；唔好假設「有 proxy」就一定有同一套 Host 驗證。

香港公司最易忽略嘅位

公開資料暫時未見有香港受害個案，所以唔應該將呢件事寫成本地災情。但香港 startup、agency、金融科技 team、教育機構實驗室同公司 IT team，常見做法係將內部 AI dashboard、MCP connector、LiteLLM gateway 放喺 VPN、辦公室 NAS、lab subnet、雲端 VM 或 Cloudflare/Nginx 後面，覺得「唔係公開網站」就夠安全。BadHost 麻煩之處正正係：只要某條入口可以由工作站、VPN 用戶、測試環境或被攻陷嘅內部機器打到，path-based middleware 就可能變成弱點。

本地合規角度亦唔可以當純技術補丁。私隱專員公署 2024 年 AI 個人資料保障框架，已經將系統安全、數據安全、持續監察、incident response 放入組織採購同使用 AI 系統嘅建議之中；金管局 GenA.I. Sandbox 首批亦有 10 間銀行同 4 個技術夥伴，use case 集中喺風險管理、反欺詐同客戶體驗。即係話，香港受監管行業已經真係喺試 GenAI，而唔係停留喺 demo。若內部 AI server 可以攞客戶資料、交易文件、KYC 檔案或 Workspace token，Starlette 呢類底層漏洞就要納入供應鏈同部署審計，而唔係交畀一個 developer 自己升 package 算數。

真正訊號：AI stack 已經係高價值入口

BadHost 亦反映咗 2026 年 AI infra 嘅一個新常態：OpenAI-compatible API 已經變成好多公司內部 AI 工具嘅共同語言。vLLM 負責自架模型 serving，LiteLLM 或類似 proxy 負責統一 upstream provider、記錄成本、做 fallback、做權限；MCP server 再將 agent 駁去外部工具。呢個 stack 好方便，但亦代表一個「內部便利入口」同時變成高價值攻擊面。以往 web app auth bypass 可能只係一個頁面；而家 bypass 一個 AI gateway，後面可能係多個模型供應商 key、跨部門資料來源同可執行工具。

所以，今次唔應該只睇 CVSS 數字。官方將 Starlette 本身評為 Moderate 有其道理，因為漏洞要配合錯誤用法先會爆到最大；但實務上，LLM gateway、MCP connector、eval dashboard、model management UI 通常就係最容易有「快捷 middleware」同「內部先用」文化嘅地方。越係話「只係 staging」、「只係 PoC」、「只係畀同事試」，越容易冇完整 reverse proxy、冇 WAF 規則、冇 dependency audit、冇 token rotation。AI agent 保安唔係只防 prompt，亦要防普通到不能再普通嘅 HTTP header。

收結好簡單：今星期內要完成三件事。第一，盤點所有 FastAPI／Starlette／MCP／LiteLLM／vLLM runtime，確認 Starlette 至少 1.0.1。第二，搜尋同改走用 request.url.path 做保安判斷嘅 middleware。第三，確保每個 ASGI app 前面都有經驗證嘅反向代理，並檢查 logs 有冇異常 Host header 嘗試。如果發現受保護 endpoint 曾經可以由未授權路徑入到，就要當成 credential exposure 處理，重發 API key、OAuth secret、service account token，同時補返審計紀錄。呢個漏洞嘅教訓係，AI agent 越似一個「會做事嘅同事」，佢身後嘅 web server 就越唔可以用 demo 級保安。

參考來源

• Ars Technica — Millions of AI agents imperiled by critical vulnerability in open source package — original report
• GitHub Security Advisory GHSA-86qp-5c8j-p5mr — 確認 CVE-2026-48710、受影響版本、修補版本 1.0.1、CVSS 6.5 Moderate 同官方 mitigation。
• X41 D-Sec Advisory X41-2026-002 — 技術分析來源，解釋 Host header 未驗證點樣令 request.url.path 同實際 path 不一致。
• Starlette 1.0.1 release note — 確認 1.0.1 修補內容為構建 request.url 時忽略 malformed Host header。
• OSTIF：Disclosing the BADHOST Vulnerability in Starlette — 補充下游 AI infra 受影響面、反向代理同 request.scope["path"] 等緩解建議。
• Model Context Protocol authorization specification — 確認 MCP HTTP authorization、OAuth Protected Resource Metadata、WWW-Authenticate discovery 等背景。
• 私隱專員公署：Artificial Intelligence Model Personal Data Protection Framework — 香港 AI 系統治理、數據安全、持續監察同 incident response 相關本地參考。
• 金管局：Gen.A.I. Sandbox 首批參與者公布 — 支持香港金融機構已實際試行 GenAI use case，作本地行業脈絡。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。