BadHost 漏洞使 AI 代理、评估器和 LLM 网关面临风险

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 承认该漏洞带来的风险，同时也在此次讨论中提出了更为细致的观点： 我认为，单就这一点来看确实相当严重，但如果你没有将 Starlette/FastAPI 直接暴露在互联网上，情况就会大大缓解。如果你使用了 CDN、负载均衡器/ API 网关或前端 Web 服务器，那么你的服务很可能已经得到保护，因为这些攻击依赖于 DNS 中的无效字符（在前两种情况下，这些字符很可能需要匹配成功后才能将流量路由到正确的客户）。 在 Starlette 1.0.1 版本中，该漏洞已经得到及时修复。你可登录 badhost.org " 免费使用在线扫描工具。 原文链接： https://www.infoq.com/news/2026/06/badhost-ai-systems-vulnerability/ "