3.25亿次下载,Starlette击穿AI基础设施

2026年5月下旬，安全公司X41 D-Sec在审计vLLM时发现了一个隐蔽的认证绕过漏洞。它藏在Starlette框架里，代号BadHost，CVE编号CVE-2026-48710。

Starlette周下载量3.25亿次。它是FastAPI的底层基础，而FastAPI是目前AI应用开发中最流行的Python Web框架。vLLM推理服务器、LiteLLM代理网关、MCP服务器、大量AI Agent框架，都跑在这套栈上。当下AI基础设施的一大半，根基在这里。

攻击者只需要在HTTP Host头里注入一个斜杠，就能让基于路径的授权中间件失效。补丁已经在Starlette 1.0.1中发布，但大量生产环境还在用旧版本。

漏洞是怎么工作的

HTTP请求里有个Host字段，告诉服务器客户端想访问哪个域名。正常情况下它就是域名，比如api.example.com。

Starlette在构建request.url对象时，直接把Host头的值和请求路径拼在一起。它不对Host头做任何校验。

攻击者可以这么构造请求：把Host头设为example.com/health?x=，后面带问号和等号，然后在真实请求路径中访问/api/admin。

这时候发生了微妙的事。路由层看到的请求路径依然是/api/admin，请求会被路由到受保护的管理接口。但中间件检查request.url.path时，拿到的却是/health。因为Starlette把Host头和路径拼在一起后重新解析URL，request.url.path指向了攻击者注入的伪装路径。

如果中间件根据request.url.path判断是否需要认证，它就会认为这个请求访问的是/health这个公开接口，于是放行。请求最终到达/api/admin，认证被完全绕过。

整个过程只需要在Host头里多写一个斜杠。

为什么AI基础设施特别危险

漏洞本身不限于AI领域，但AI生态踩中了所有触发条件。

首先是MCP服务器。MCP是Model Context Protocol的缩写，允许AI Agent访问外部数据库、邮箱、日历等资源。MCP规范本身就要求提供不需要认证的OAuth发现端点，这给了攻击者可靠的利用入口。

其次是AI推理服务器和代理网关。vLLM、LiteLLM、Text Generation Inference都构建在FastAPI和Starlette之上，它们普遍用路径认证中间件保护API端点。认证被绕过，模型访问权限、API密钥、内部工具接口都会暴露。

安全研究人员已经扫描出大量正在暴露敏感数据的实例。包括生物制药企业的临床试验数据库和并购数据、身份验证系统的人脸分析和实时个人身份信息、工业物联网设备通过堡垒机的SSH访问、完整的邮箱读写删除权限和S3数据导出、人力资源系统的候选人个人数据和招聘流程数据、内容管理系统的订阅者列表和邮件群发能力、云监控服务的AWS拓扑结构和分布式追踪数据，甚至个人健康和财务记录。

这不是理论风险，是正在发生的事实。

发现与修复过程

这个漏洞是X41 D-Sec在OSTIF赞助的安全审计中发现的。最初研究目标是vLLM，深入分析后发现根问题出在更底层的Starlette框架上。

有趣的是，Anthropic的Claude Mythos工具通过Project Glasswing项目已经发现了超过一万个漏洞，但没有发现这一个。原因在于这个漏洞的形态特殊。它横跨三个独立层面的交互问题，不是单点bug。ASGI服务器直接传递原始Host头，Starlette信任这个值来构建URL，中间件开发者假设request.url.path用于认证决策是安全的。每个组件在隔离状态下都表现正常，漏洞只有在它们组合在一起时才会出现。

理解漏洞类型之后，测量实际影响是另一项独立工作。研究人员编写了自定义的CodeQL查询，对Starlette在GitHub上的超过40万个依赖项目进行了大规模扫描。

Nemesis安全团队还开发了一个在线扫描工具，可以检测MCP端点和常见推理API路径是否受到CVE-2026-48710影响。

修复方案方面，Starlette 1.0.1版本已经发布。新版本会忽略包含无效字符的Host头，不再用它们来构建URL。

给运维和开发者的建议

如果你的系统使用了Starlette或FastAPI，有几件应该优先做的事情。

第一件是确认Starlette版本。检查依赖锁文件，确保Starlette已升级到1.0.1或更高版本。对于使用pip的项目，运行pip install starlette>=1.0.1。使用Poetry的项目更新pyproject.toml中的版本约束后执行poetry update starlette。

第二件是审查认证中间件的使用方式。基于request.url.path做认证决策的中间件在设计上就存在脆弱性。认证应该绑定到端点本身，而不是用来到达端点的路径。推荐使用Starlette的requires()装饰器，或者FastAPI的Depends()和Security()机制，这些基于实际端点进行安全校验。

第三件是在ASGI服务器前面部署反向代理。符合RFC标准的反向代理如nginx、Caddy、Traefik、HAProxy会在转发请求之前校验和规范化Host头，从而从根本上阻止这类注入攻击。很多开发环境和自托管实例直接把ASGI服务器暴露在外网，没有反向代理保护，这是最危险的部署方式。

如果必须用中间件做路径检查，应该使用scope["path"]而不是request.url.path。ASGI scope中的path来自HTTP请求行，无法通过Host头操纵。

第四件是用工具自查。X41公开了一个代码仓库，包含Python概念验证利用代码、Semgrep静态检测规则和CodeQL查询。可以用Semgrep规则检查自己代码库的中间件文件中是否存在request.url.path的使用，或者运行CodeQL查询扫描整个Python项目。

关于漏洞严重性评级

CVE-2026-48710的CVSS评分是7分。安全公司Secwest认为这个评级明显低估了实际威胁。X41 D-Sec直接将其定性为critical severity。

评分和实际影响之间的差距来自评分体系的局限性。CVSS评分主要评估漏洞本身的技术属性，不会充分考虑下游依赖项目的规模和暴露面。一个7分的底层框架漏洞，当它影响到3.25亿周下载量生态中的认证链路时，实际风险远超评分本身。

你目前使用的AI基础设施是否基于FastAPI或Starlette。升级到1.0.1之后是否审查过认证中间件的实现方式。欢迎在评论区分享你的排查经验和修复方案。如果这篇文章对你有帮助，可以收藏备用，也欢迎转发给团队里负责运维和安全的同事。

参考资料

https://badhost.org/

https://arstechnica.com/information-technology/2026/05/millions-of-ai-agents-imperiled-by-critical-vulnerability-in-open-source-package/

https://x41-dsec.de/lab/advisories/x41-2026-002-starlette/

https://github.com/x41sec/poc/tree/master/starlette-host-header

https://github.com/Kludex/starlette/security/advisories/GHSA-86qp-5c8j-p5mr