Starlette 3.25亿下载量,一个Host字符把门撬开

昨天我刷到一个安全圈讨论帖，群里做 agent 的朋友直接甩来一句：一个 Host 头里的字符，居然能把认证绕过去。我第一反应是不信，结果越往下看越像那种典型的技术圈大瓜——单个环节都没问题，拼起来却翻车了。

我觉得这事值得看完。因为它表面上是在说 BadHost 和 Starlette，实际上暴露的是很多 AI 基础设施共同的习惯：大家默认某个字段可信，最后却被一个没人注意的小细节击穿。

一个字符引发的连锁反应

这次被讨论最多的是 BadHost。它出现在广泛使用的 Python Web 框架 Starlette 中，而文章给出的数字非常扎眼：每周下载量达到 3.25 亿次。

事情最离谱的地方在于，攻击方式并不复杂。研究人员发现，只要在 Host 头里加入特定字符，就可能让原本应该被拦截的请求被正常处理。也正因为门槛不高，很多人看到演示后第一反应都是：这居然能成功？

发现问题的是 Secwest 和 X41 D-Sec。按照他们的分析，Starlette 在重建 request.url 时，会把 HTTP Host 头和请求路径拼接后重新解析。而 Host 的内容在重建前没有按照 RFC 9112 和 RFC 3986 的语法进行校验。

结果就是，当 Host 头里出现特殊字符时，重新解析后的路径边界发生变化。系统真正收到并路由的路径，和后续用于权限判断的路径，可能已经不是同一个东西。

X41 D-Sec 认为，单个字符带来的影响并不只是认证绕过，还可能进一步连接到 SSRF 以及 remote code execution 等问题。

所以争议来了。这个漏洞被赋予了 6.5 的 moderate 风险评分，但研究人员公开表示，这个评分低估了真实影响。他们认为很多下游项目都会受到波及，实际危险程度更接近关键级别问题。

真正的反转不在漏洞本身

我觉得最值得吃瓜的，其实不是漏洞，而是它被发现的路径。

文章提到，这个问题是在对 vLLM 进行源码审计时发现的。换句话说，从 Starlette 的一个小特性，到最终影响 LLM-serving 场景，这条链路并不是安全研究员硬想出来的理论攻击路线，而是真实挖掘过程中走出来的发现路径。

研究人员还特别点名了 MCP servers。他们认为 MCP spec 要求存在未认证的 OAuth discovery endpoints，这让攻击者拥有更加稳定的利用入口。

更有意思的是另一段内容。Claude Mythos 并没有发现这个漏洞，却在 Project Glasswing 里识别出了超过 10000 个漏洞。

这一下把讨论推向了另一个方向：有些问题不是单个文件的问题，不是单个仓库的问题，甚至不是单个组件的问题。

CVE-2026-48710 spans three independent layers. Each component behaves correctly in isolation. The vulnerability only emerges from the interaction between them.

说白了，ASGI servers 传递原始 Host，Starlette 信任它来构造 URL，中间件又默认 request.url.path 可以用于安全决策。单看每一层，好像都没毛病；三层叠在一起，问题就出现了。

这种故事在 AI 圈其实特别常见。大家总喜欢讨论哪个模型更强、哪个系统更稳，但很多事故最后都不是单点失败，而是多个合理设计组合后的意外结果。

社区已经开始站队了

Hacker News 上的讨论也很有意思。

ostif-derek 的态度非常直接。他认为把这个问题定成 medium 风险，掩盖了它对海量下游项目和大量安装实例的真实冲击。他甚至表示，大家应该尽快修复。

This is a bad one. People need to patch asap.

但另一边，acdha 的观点就冷静很多。

他认为问题确实存在，但如果服务并不是直接暴露在互联网，而是前面还有 CDN、load-balancer、API Gateway 或前置 Web 服务，那么风险会被明显削弱。因为攻击依赖的字符本身并不符合 DNS 规则，在很多基础设施层面就可能被挡掉。

于是整个讨论变成了两派。

一派认为这是被低估的大雷；另一派认为这是部署方式决定风险等级的典型案例。双方都没完全否定对方，但关注点完全不同。

如果你是 AI 团队、产品经理、运营或者招聘侧的人，我觉得这件事释放了一个很现实的信号：很多 AI 服务的风险并不来自模型本身，而来自外围基础设施。尤其是内部实验环境、研究网络、测试集群，往往没有生产环境那样完整的保护链路。

文章提到，受影响场景往往部署在内部网络、实验室子网以及 LLM 研究环境里。这些地方恰恰容易因为默认信任而忽略边界防护。所以别把它理解成单纯的 Starlette 漏洞新闻，更像是在提醒所有做 AI 基础设施的人：你以为安全的地方，可能才是最脆弱的地方。

目前 Starlette 1.0.1 已经完成修复。同时还有一个免费在线扫描工具可用：

badhost.org

我自己的感受是，这次事件最值得关注的不是那个特殊字符，而是它再次证明了一件事：很多最危险的问题，都诞生于系统之间的缝隙。单独审查一个组件，可能永远看不到风险；只有把整条链路放在一起看，漏洞才会浮出水面。

留言聊聊
你也觉得这个漏洞被低估了吗？

往期推荐

• ·AI 内容误导超 50%案例，我朋友都惊呆了
• ·DSLR+深度学习识别10万蚊子，Steven Cheng 激光全灭体验
• ·Reddit 12秒采购Agent，最危险的是完美执行

点击公众号头像 → 历史消息，可翻阅以上文章