你正盯着终端，敲下一句 curl 测试管理后台的访问控制——返回 403，放心了。但你同事把 Host 头悄悄改成 foo?，同样是那个地址，这回返回的是 200，页面完整奉上。没有错误日志，没有告警，门禁像不存在一样。这就是 BadHost 漏洞的体验版，而它影响的，是一个每周被下载 3.25 亿次的 Python Web 框架。

Starlette，这个支撑着 FastAPI 等大量异步服务的轻量级组件，被 Secwest 和 X41 D-Sec 的研究人员挖出一个认证绕过的高危漏洞。漏洞利用简单到只需在 HTTP 的 Host 头里塞一个 /、? 或 # 字符。正常的 Host 头 foo 会被拦截，但 foo? 却能大摇大摆通过，背后的 API、代理、内部服务就这样暴露在畸形请求下。

打开网易新闻 查看精彩图片

这一切的根源在于 Starlette 重建 request.url 的方式。它把 Host 头的值直接和请求路径拼接起来重新解析，却没有按照 RFC 9112 和 RFC 3986 的语法先校验 Host 的合法性。当 Host 里夹带了特殊字符，整个 URL 的 path、query 和 fragment 的解析边界就被挪动了，最终 request.url.path 和 ASGI 服务器实际路由的那个路径早已对不上号。依赖这个 path 做安全决策的中间件，等于在本应关上门的时刻，把钥匙交到了攻击者手里。

漏洞的 CVSS 评分只有 6.5，属于“中等”级别，但研究人员直言这“低估了下游影响”。X41 的分析顺着这个单字符原语一路推演，在多个流行开源项目里复现出认证绕过、服务端请求伪造乃至远程代码执行的全链。发现的过程本身就写满了警示——这个漏洞是在审计 vLLM 的源码时撞上的。用研究者的话说，“从 Starlette 的怪癖到 LLM 服务原语的路径不是理论推演，它就是真实的发现路径。”

更让人捏一把汗的是，大量受影响的 AI 组件并不躲在生产环境标配的反向代理后面。它们跑在内部网络、实验室子网、大模型研究环境里，直接暴露在 BadHost 的可利用面上。MCP 服务器的情况尤其棘手，因为 MCP 规范强制要求提供未经认证的 OAuth 发现端点，这把攻击者的路径焊得更直了。

Claude Mythos 的扫描平台在 Project Glasswing 里揪出了超过 1 万个漏洞，却完美错过了这一个。这不是一个文件或一个代码库的 Bug，编号 CVE-2026-48710 的漏洞横跨三个独立工作的层面：ASGI 服务器