BadHost 是广泛使用的 Python Web 框架 Starlette 中一个高危的身份验证绕过漏洞。该框架每周的下载量达 3.25 亿次。该漏洞允许攻击者利用格式错误的 HTTP Host 头绕过基于路径的访问控制从而访问敏感的 AI 代理基础设施及其他系统。该漏洞由 Secwest 和 X41 D-Sec 的安全研究人员所发现只需在 Host 头中加入 /、? 或 # 字符即可轻松利用该漏洞curl -i -H Host: foo http://target/admin # 403拒绝访问curl -i -H Host: foo? http://target/admin # 200成功返回Starlette 通过将 HTTP Host 头与请求路径拼接起来并对结果进行重新解析从而重建 request.url。在重建之前它不会根据 RFC 9112 / RFC 3986 语法对 Host 值进行验证。包含 /、? 或 # 的 Host 头会在重新解析时改变路径、查询和片段的边界因此 request.url.path 将不再与 ASGI 服务器实际接收并用于路由的路径相匹配。尽管该漏洞被评定为 6.5 分中等风险但研究人员认为这一评分“低估了其下游影响”并且指出该漏洞应被视为“严重”级别因为它影响所有下游用户X41 的分析发现在多个流行的开源项目中其中间件会根据 request.url 来决定与安全相关的操作并且已经证实这个单字符的原始参数可以引发身份验证绕过、SSRF 以及远程代码执行等漏洞。这一严重性还体现在该漏洞是在对 vLLM 进行源代码审计时发现的这表明“从 Starlette 漏洞到 LLM 服务原语的路径并非理论上的而是实际发现的路径”。更糟糕的是受影响的 AI 服务通常部署在内部网络、实验室子网和 LLM 研究环境中这些环境缺乏生产系统中常见的反向代理保护导致它们直接暴露在 BadHost 的攻击之下。MCP 服务器面临着特别高的风险正如研究人员所指出的那样“MCP 规范要求使用未经身份验证的 OAuth 发现端点这为攻击者提供了可靠的利用途径”。值得注意的是Claude Mythos 未能发现该漏洞但它在 Glasswing 项目中识别出了超过 10000 个漏洞。对此研究人员指出CVE-2026-48710 并非某个文件或某个存储库中的漏洞。它涉及三个独立的层ASGI 服务器传递原始的 Host 头Starlette 在构建 URL 时信任该头而中间件作者则认为 request.url.path 在身份验证决策中是安全的。每个组件在孤立状态下均行为正常。该漏洞仅在它们相互交互时才会显现。在 Hacker News 上ostif-derek 警告说这可真是个大麻烦。将其评定为“中等”严重性低估了它对数千个下游项目和数十亿次安装造成的冲击。大家必须尽快打补丁。我通常反对那种“给漏洞起名字、设计标志、建网站”的做法但这次正因为将其评为“中等”严重性导致补丁部署率很低。用户 acdha 承认该漏洞带来的风险www.ntjrcw.com同时也在此次讨论中提出了更为细致的观点我认为单就这一点来看确实相当严重但如果你没有将 Starlette/FastAPI 直接暴露在互联网上情况就会大大缓解。如果你使用了 CDN、负载均衡器/ API 网关或前端 Web 服务器那么你的服务很可能已经得到保护因为这些攻击依赖于 DNS 中的无效字符在前两种情况下这些字符很可能需要匹配成功后才能将流量路由到正确的客户。