编一个 Bearer token 就能进 MCP 工具：LiteLLM 认证绕过已被在野利用，CISA 给出的修复期限是 9 月 16 日

AI资讯编辑部今天

CISA 于 9 月 2 日把 CVE-2026-59822 加入已知被利用漏洞目录，依据是存在在野利用证据，美国联邦机构的修复期限定在 9 月 16 日。问题出在 LiteLLM 的 MCP Streamable HTTP 端点：API key 校验失败时，OAuth2 passthrough 的兜底逻辑没有终止请求，而是塞进一个空的 UserAPIKeyAuth() 对象——于是在 Authorization 头里随便编一个 Bearer token 就能过，不需要有效的 LiteLLM key、账号或任何既有访问权限。1.84.0 之前的所有版本受影响，CVSS 4.0 评分 8.8。攻破之后能碰到的是 MCP 工具及其连接的服务，可能连带暴露上游 LLM API key、模型输出和后端凭据。有一个容易踩的坑：为修早前的 CVE-2026-35029 只升到 1.83.0 的实例，仍然低于这次的修复版本。

兜底逻辑写反了方向

漏洞本身很短：校验失败时正确的做法是拒绝请求，而这里的 OAuth2 passthrough 兜底把失败当成了「没有身份」，返回一个空的 `UserAPIKeyAuth()` 让请求继续走下去。结果是任何一个格式正确但内容伪造的 Bearer token 都能穿过认证，落到 MCP 路由上。危害的放大倍数来自 LiteLLM 的位置。它通常被摆在多家模型 provider 前面当统一入口，手里握着的是一整排上游 key，加上代理自己签发的虚拟 key。所以被绕过的后果不是丢一个凭据，是丢一层凭据。已有报道描述的攻击链印证了这一点：攻击者把 Starlette 的 CVE-2026-48710 与 CVE-2026-42271 串起来绕过认证、部署 XMRig 挖矿，随后去翻 `LiteLLM_ProxyModelTable` 和 `LiteLLM_VerificationToken` 收集 provider key 和虚拟 key，并改 `authorized_keys` 做持久化。

入口是 MCP，这一点值得单独说

很多团队是最近半年才把 MCP 路由打开的，安全评估常常还停在「网关本身有没有认证」，没有覆盖新挂上去的这条链路。而 MCP 工具背后往往连着内部系统——一旦认证形同虚设，攻击者拿到的不只是模型调用权，还有这些工具被授予的一切权限。顺带一个信号：这次 CISA 一批加进 KEV 的七个漏洞里，有三个指向 AI 基础设施（LiteLLM、Kestra、以及 Starlette 相关的那条）。AI 侧的中间件正在成为被主动扫的对象，不再只是研究者的靶场。

今天该做的四件事

升级到 **1.84.0 或更高**——这是关键数字。只为修 CVE-2026-35029 升到 1.83.0 的实例仍然中招，很多人会以为自己已经打过补丁了。来不及升级的，先在反向代理或 API 网关上挡掉 `/mcp/` 路径，互联网可达的实例直接把 MCP 路由关掉。盘一遍已连接的 MCP 工具各自被授予了什么权限——这决定了万一被打穿，损失的边界在哪。最后是排查：如果这些路由在暴露期内从不可信网络可达，把访问日志翻一遍，重点看有没有异常的 key 列举、虚拟 key 签发和 `authorized_keys` 变更。截至 9 月 5 日，公开的可用利用代码还很有限（有一个 GitHub 上的 PoC 仓库，未见 Metasploit 模块或 Nuclei 模板），但 KEV 的依据本身就是已经有人在打了。

via: CISA KEV 公告（2026-09-02）、GitHub Advisory 与 CVE-2026-59822 详情、IONIX 威胁分析、Sysdig 关于 LiteLLM 认证路径被快速利用的分析