Starlette框架身份验证绕过漏洞波及FastAPI及AI工具生态

一个畸形字符就能让未经身份验证的攻击者绕过访问控制，波及所有基于Starlette构建的应用程序。Starlette是驱动FastAPI的开源Python框架，研究人员对此发出警告。

该漏洞编号为CVE-2026-48710，据网络安全公司X41 D-Sec发布的安全公告显示，攻击者可利用畸形Host头绕过主机验证保护机制。攻击者无需密码，也无需受害者做出任何操作即可实施攻击。

漏洞披露与修复过程

Starlette的维护者在X41 D-Sec通过开源技术改进基金（OSTIF）协调披露该漏洞后，已通过官方GitHub安全公告发布了补丁。研究人员在一次针对其他项目的源代码审计中意外发现了该漏洞，并将其追溯至Starlette框架本身，而非被审计的应用程序。

OSTIF表示："这个漏洞是典型的'责任缺口'问题——如果维护者不打补丁，数千个受影响的项目将不得不各自独立修复安全问题。"

研究人员还创建了一个测试网站badhost.org，用于检测网站是否存在该漏洞。

漏洞技术原理

根据X41 D-Sec的分析，该漏洞存在于Starlette重建传入请求地址的方式中。该框架将客户端发送的Host头与请求路径拼接，形成完整的URL，但在验证完整URL与各组成部分时使用了不同的规则。

研究人员指出，如果Host头中包含斜杠、问号或井号等字符，会导致路径起始位置发生偏移，使Starlette报告的路径与服务器实际接收到的路径不一致。

这一偏差正是风险所在。Starlette会将请求路由到真实路径，但中间件和端点读取的却是被篡改后的路径。如果应用程序通过检查其所见路径来限制敏感路由的访问，就可能在放行请求的同时仍然执行了受保护的路由。

实际攻击演示

X41 D-Sec随安全公告发布了攻击演示。研究人员向一个受保护的管理页面发送请求，收到了"403 Forbidden"（禁止访问）响应；随后在Host头中仅添加一个额外字符重新发送相同请求，该页面返回了"200 OK"（请求成功）。

类似的身份验证绕过模式近期也在其他开源AI框架的漏洞中出现过。

漏洞严重程度评估

Starlette维护者在GitHub安全公告中将该漏洞的CVSS评分定为6.5分（中等级别），而X41 D-Sec将其评为7.0分（高危级别），并表示基于Starlette构建的软件所面临的实际风险高于上述任何评分所呈现的程度。

攻击者能造成的实际危害取决于各应用程序如何处理被伪造的路径。X41 D-Sec表示，已发现多个开源项目的安全检查依赖于重建后的地址。在这些项目中，这一单字符漏洞可能触发连锁攻击，"从身份验证绕过演变为服务器端请求伪造（SSRF）及其他问题，在某些情况下甚至导致对受影响系统的远程代码执行"。

广泛的下游影响

该漏洞的影响范围远超Starlette本身。安全公司Secwest针对该漏洞发布的独立公告指出，官方评分"严重低估了下游影响"，并警告该漏洞涉及"过去两年内搭建的大多数模型服务、API网关、代理、评估、智能体及MCP服务器基础设施"。

据X41 D-Sec和Secwest介绍，受影响的软件包括基于FastAPI构建的模型服务工具、API网关、OpenAI兼容代理、智能体框架以及模型上下文协议（MCP）服务器。

X41 D-Sec还特别指出，即使开发者从未主动安装Starlette，其应用程序也可能受到影响，因为其他依赖组件可能已间接引入了Starlette。目前在GitHub上，Starlette的依赖项目已超过40万个。

高风险群体

X41 D-Sec强调，并非所有依赖该框架的项目都面临同等风险，实际暴露程度取决于应用程序的部署方式。

关键分界线在于反向代理：nginx或Apache HTTP Server等代理会在恶意请求到达应用程序之前将其拒绝，而生产环境网站通常部署在此类代理层之后。然而，AI软件的研究、评估和开发环境往往不具备这一保护层，许多应用服务器直接暴露在网络中。

以下三类群体面临最高风险：在没有合规反向代理的情况下直接运行FastAPI或Starlette应用服务器的用户；将LiteLLM或vLLM等模型代理作为可直接访问端点公开的用户；以及访问控制代码依赖重建后请求地址而非原始路径的用户。

修复建议

研究人员建议所有相关团队升级至Starlette 1.0.1或更高版本，该版本已对Host头进行验证并拒绝畸形值。

Q&A

Q1：CVE-2026-48710漏洞具体是怎么利用的？

A：攻击者只需在HTTP请求的Host头中加入斜杠、问号或井号等特殊字符，就能让Starlette框架解析出错误的请求路径。由于中间件和端点读取的是被篡改后的路径，而框架实际路由到的是真实路径，两者不一致导致访问控制失效。整个攻击过程无需密码，也不需要受害者配合，研究人员实测仅添加一个字符就能将403禁止访问变为200成功响应。

Q2：不使用FastAPI的项目会受到Starlette漏洞影响吗？

A：有可能。即使开发者没有直接安装Starlette，项目中其他依赖组件也可能间接引入了它。目前GitHub上Starlette的依赖项目已超过40万个，受影响范围包括模型服务工具、API网关、OpenAI兼容代理、智能体框架及MCP服务器等。建议检查项目的完整依赖树，确认是否间接依赖了Starlette。

Q3：如何判断自己的应用是否存在这个漏洞风险？

A：风险高低主要取决于部署方式。如果应用前置了nginx或Apache等合规反向代理，这类代理会在请求到达应用前将畸形请求拦截，风险较低。最高风险情况是：直接将FastAPI或Starlette应用暴露在网络中且无反向代理；或将LiteLLM、vLLM等模型代理作为可直接访问的端点。可访问badhost.org网站检测是否存在漏洞，并尽快升级至Starlette 1.0.1或更高版本。