过去几年，AI 圈一直在疯狂讨论“大模型能力边界”。

但很多人忽略了一件事：真正危险的，未必是模型本身，而是那些把模型连接到真实世界的基础设施。当 AI Agent 开始接管邮箱、数据库、企业 SaaS、代码仓库、云资源，甚至工业设备时，一个原本看起来“普通”的 Web 框架漏洞，可能就会瞬间变成现实世界的安全灾难。

最近，安全研究人员就发现了这样一个问题：一个仅需“1 个字符”即可触发的漏洞，正在威胁大量 AI Agent 与 MCP（Model Context Protocol）基础设施。攻击者甚至可能绕过认证机制，直接访问邮箱系统、用户数据库、企业云环境，以及部分工业设备控制入口。

更关键的是：这个漏洞并不藏在某个冷门项目里。它存在于 Python 开源框架 Starlette 中——一个每周下载量高达约 3.25 亿次的基础组件。而 FastAPI、vLLM、LiteLLM 等大量 AI 基础设施，又恰恰建立在它之上。

一个“地基级”漏洞：整个 Python AI 生态都可能中招

这个漏洞目前已经被登记为CVE-2026-48710，代号 “BadHost”。此次问题的核心，出现在 Starlette 对 HTTP Host Header 的处理逻辑上。

如果你做过 Web 开发，大概率知道：当浏览器或客户端向服务器发送请求时，会带上一个 Host Header，用来告诉服务器“我要访问哪个域名”。Starlette 会根据这个 Header 重建请求 URL，可问题在于：它从来没有检查这个 Header 是否合法。

于是，攻击者就可以构造一个恶意 Header，在 URL 中插入额外路径信息，从而制造“系统认知错位”：

● 路由系统：检查真实请求路径，发现一切正常。

● 认证系统：检查重建后的 URL，结果被误导，以为用户访问的是“允许访问”的资源。

最终：认证通过，攻击者成功进入系统。

整个漏洞核心，其实就是：认证层与路由层，对同一个请求产生了解析不一致（Parsing Inconsistency）。这种漏洞最可怕的地方在于：它事后看起来非常简单，甚至有些“低级”。但也正因为如此，它极容易长期潜伏。

在形容这个漏洞的危险程度时，研究人员直言：“只需要一个字符，门就开了。”

为什么 AI Agent 场景特别危险？

如果这是一个普通网站漏洞，问题或许还没那么严重。但偏偏，这几年 AI Agent 与 MCP Server 的爆发，让事情变得异常敏感。

简单来说，MCP Server 的核心职责，是帮助 AI Agent 连接真实世界资源。比如Gmail 邮箱、日历、企业数据库、Slack、GitHub、AWS、CRM、内部 SaaS、工业控制系统等。而为了实现这些能力，MCP Server 往往需要长期保存各种高权限 Credential，包括OAuth Token、API Key、SSH 凭证、企业访问密钥等。

所以，它天然就是攻击者最想拿下的位置。而 BadHost 恰好可以让攻击者绕过认证逻辑，直接进入这些系统。

可对于这个漏洞，Starlette 的维护团队在 GitHub 安全公告中给出的 CVSS 评分仅为 6.5（中等威胁）。对此，很多安全研究人员认为官方 CVSS 严重性评分，低估了这个漏洞的真实危险程度——因为它影响的，不只是 Web 服务本身，而是整个 AI Agent 权限链条。

研究人员扫描后，发现互联网已经“敞开大门”

更让人后背发凉的是：这个漏洞并不只停留在理论上。

安全机构 X41 D-Sec 在互联网进行了实际扫描，结果他们发现了大量可被 BadHost 直接触达的生产系统，涉及的敏感数据类型令人不寒而栗：生物制药公司的临床试验数据库、企业邮件系统完整访问权限、SaaS 平台后台、AWS 云基础设施拓扑、身份验证公司的实名数据、招聘平台候选人隐私信息、邮件营销系统订阅列表、健康与金融 App 用户数据等等。

甚至，研究人员还发现了更敏感的目标：某些工业设备通过 Bastion Host（堡垒机）开放 SSH 访问。也就是说，一旦攻击成功，理论上攻击者是可以直接获得工业基础设施的远程代码执行能力（RCE）。

从“数据泄露”升级到“物理设备控制”，这个漏洞的危险等级就完全不同了。

为什么影响范围会这么大？

原因很简单：Starlette 在 Python AI 生态中的位置，实在太核心了。

它本身是 ASGI 框架，虽不是一个面向最终用户的应用程序，但是一个基础设施组件——就像地基，你看不到它，但少了它整栋楼都会塌。最主要的是，Starlette 是 FastAPI 的核心依赖，而 FastAPI 几乎撑起了整个 Python AI 工具生态的“半边天”。

过去两年，大量 AI 基础设施都基于 FastAPI 开发，包括 vLLM、LiteLLM、Text Generation Inference（TGI）、OpenAI-compatible Proxy、MCP Server、Agent Gateway 以及各类 AI 推理 API。

因此，大多数 Python AI 项目并不直接依赖 Starlette，而是通过 FastAPI 等上层框架间接引入的，导致很多团队根本没意识到：自己的项目已经间接依赖了 Starlette。这也是现代软件供应链最危险的问题之一：真正的风险，往往藏在开发者从未直接接触过的底层依赖里。

目前，官方已经在 Starlette 1.0.1 中修复了问题，但很多团队升级的只是顶层应用，而漏洞真正存在的，是深层依赖链。

对此，研究人员特别提醒：即便你没有直接安装 Starlette，也可能依旧受到影响。如果你正在使用 FastAPI、LiteLLM、vLLM、OpenAI Proxy、MCP Framework，都应该立刻检查完整的依赖树。

此外，X41 D-Sec 与 Nemesis 也发布了公开扫描工具（https://mcp-scan.nemesis.services/），用于检测服务器是否仍运行存在漏洞的版本。

显然，当 AI 系统开始拥有真实世界操作权限时，一个底层框架的小漏洞，已足以演变成系统级风险。这一次，漏洞幸运地被公开了，也已有补丁，但下一次又会如何呢？

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