整理 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

過去幾年，AI 圈一直在瘋狂討論“大模型能力邊界”。

但很多人忽略了一件事：真正危險的，未必是模型本身，而是那些把模型連接到真實世界的基礎設施。當 AI Agent 開始接管郵箱、數據庫、企業(yè) SaaS、代碼倉庫、云資源，甚至工業(yè)設備時，一個原本看起來“普通”的 Web 框架漏洞，可能就會瞬間變成現(xiàn)實世界的安全災難。

最近，安全研究人員就發(fā)現(xiàn)了這樣一個問題：一個僅需“1 個字符”即可觸發(fā)的漏洞，正在威脅大量 AI Agent 與 MCP（Model Context Protocol）基礎設施。攻擊者甚至可能繞過認證機制，直接訪問郵箱系統(tǒng)、用戶數據庫、企業(yè)云環(huán)境，以及部分工業(yè)設備控制入口。

更關鍵的是：這個漏洞并不藏在某個冷門項目里。它存在于 Python 開源框架 Starlette 中——一個每周下載量高達約 3.25 億次的基礎組件。而 FastAPI、vLLM、LiteLLM 等大量 AI 基礎設施，又恰恰建立在它之上。

一個“地基級”漏洞：整個 Python AI 生態(tài)都可能中招

這個漏洞目前已經被登記為CVE-2026-48710，代號 “BadHost”。此次問題的核心，出現(xiàn)在 Starlette 對 HTTP Host Header 的處理邏輯上。

如果你做過 Web 開發(fā)，大概率知道：當瀏覽器或客戶端向服務器發(fā)送請求時，會帶上一個 Host Header，用來告訴服務器“我要訪問哪個域名”。Starlette 會根據這個 Header 重建請求 URL，可問題在于：它從來沒有檢查這個 Header 是否合法。

于是，攻擊者就可以構造一個惡意 Header，在 URL 中插入額外路徑信息，從而制造“系統(tǒng)認知錯位”：

● 路由系統(tǒng)：檢查真實請求路徑，發(fā)現(xiàn)一切正常。

● 認證系統(tǒng)：檢查重建后的 URL，結果被誤導，以為用戶訪問的是“允許訪問”的資源。

最終：認證通過，攻擊者成功進入系統(tǒng)。

整個漏洞核心，其實就是：認證層與路由層，對同一個請求產生了解析不一致（Parsing Inconsistency）。這種漏洞最可怕的地方在于：它事后看起來非常簡單，甚至有些“低級”。但也正因為如此，它極容易長期潛伏。

在形容這個漏洞的危險程度時，研究人員直言：“只需要一個字符，門就開了。”

免費領100 小時云算力｜CSDN 讀者專屬福利

適配 DeepSeek、Qwen 等主流大模型

掃碼即刻領取，每月還有顯卡、AIPC等實物好禮抽獎

咖啡領取鏈接： https://s.csdn.cn/4nPsOp

為什么 AI Agent 場景特別危險？

如果這是一個普通網站漏洞，問題或許還沒那么嚴重。但偏偏，這幾年 AI Agent 與 MCP Server 的爆發(fā)，讓事情變得異常敏感。

簡單來說，MCP Server 的核心職責，是幫助 AI Agent 連接真實世界資源。比如Gmail 郵箱、日歷、企業(yè)數據庫、Slack、GitHub、AWS、CRM、內部 SaaS、工業(yè)控制系統(tǒng)等。而為了實現(xiàn)這些能力，MCP Server 往往需要長期保存各種高權限 Credential，包括OAuth Token、API Key、SSH 憑證、企業(yè)訪問密鑰等。

所以，它天然就是攻擊者最想拿下的位置。而 BadHost 恰好可以讓攻擊者繞過認證邏輯，直接進入這些系統(tǒng)。

可對于這個漏洞，Starlette 的維護團隊在 GitHub 安全公告中給出的 CVSS 評分僅為 6.5（中等威脅）。對此，很多安全研究人員認為官方 CVSS 嚴重性評分，低估了這個漏洞的真實危險程度——因為它影響的，不只是 Web 服務本身，而是整個 AI Agent 權限鏈條。

研究人員掃描后，發(fā)現(xiàn)互聯(lián)網已經“敞開大門”

更讓人后背發(fā)涼的是：這個漏洞并不只停留在理論上。

安全機構 X41 D-Sec 在互聯(lián)網進行了實際掃描，結果他們發(fā)現(xiàn)了大量可被 BadHost 直接觸達的生產系統(tǒng)，涉及的敏感數據類型令人不寒而栗：生物制藥公司的臨床試驗數據庫、企業(yè)郵件系統(tǒng)完整訪問權限、SaaS 平臺后臺、AWS 云基礎設施拓撲、身份驗證公司的實名數據、招聘平臺候選人隱私信息、郵件營銷系統(tǒng)訂閱列表、健康與金融 App 用戶數據等等。

甚至，研究人員還發(fā)現(xiàn)了更敏感的目標：某些工業(yè)設備通過 Bastion Host（堡壘機）開放 SSH 訪問。也就是說，一旦攻擊成功，理論上攻擊者是可以直接獲得工業(yè)基礎設施的遠程代碼執(zhí)行能力（RCE）。

從“數據泄露”升級到“物理設備控制”，這個漏洞的危險等級就完全不同了。

為什么影響范圍會這么大？

原因很簡單：Starlette 在 Python AI 生態(tài)中的位置，實在太核心了。

它本身是 ASGI 框架，雖不是一個面向最終用戶的應用程序，但是一個基礎設施組件——就像地基，你看不到它，但少了它整棟樓都會塌。最主要的是，Starlette 是 FastAPI 的核心依賴，而 FastAPI 幾乎撐起了整個 Python AI 工具生態(tài)的“半邊天”。

過去兩年，大量 AI 基礎設施都基于 FastAPI 開發(fā)，包括 vLLM、LiteLLM、Text Generation Inference（TGI）、OpenAI-compatible Proxy、MCP Server、Agent Gateway 以及各類 AI 推理 API。

因此，大多數 Python AI 項目并不直接依賴 Starlette，而是通過 FastAPI 等上層框架間接引入的，導致很多團隊根本沒意識到：自己的項目已經間接依賴了 Starlette。這也是現(xiàn)代軟件供應鏈最危險的問題之一：真正的風險，往往藏在開發(fā)者從未直接接觸過的底層依賴里。

目前，官方已經在 Starlette 1.0.1 中修復了問題，但很多團隊升級的只是頂層應用，而漏洞真正存在的，是深層依賴鏈。

對此，研究人員特別提醒：即便你沒有直接安裝 Starlette，也可能依舊受到影響。如果你正在使用 FastAPI、LiteLLM、vLLM、OpenAI Proxy、MCP Framework，都應該立刻檢查完整的依賴樹。

此外，X41 D-Sec 與 Nemesis 也發(fā)布了公開掃描工具（https://mcp-scan.nemesis.services/），用于檢測服務器是否仍運行存在漏洞的版本。

顯然，當 AI 系統(tǒng)開始擁有真實世界操作權限時，一個底層框架的小漏洞，已足以演變成系統(tǒng)級風險。這一次，漏洞幸運地被公開了，也已有補丁，但下一次又會如何呢？

參考鏈接：https://firethering.com/badhost-starlette-critical-vulnerability-ai-agents/

免費領取 100 小時 AI 算力｜CSDN 讀者福利

加入 AI 開發(fā)者計劃獲取：

? AI 算力資源

? 官方技術社群

? Workshop 與 AI Academy

? 開發(fā)者專屬福利

立即掃碼，前 50 名額外領取「瑞幸咖啡」

咖啡領取鏈接： https://s.csdn.cn/4nPsOp