一幅关于网络路径上身份验证检查点的抽象技术插画。由细薄的同心矩形框架构成的高大门户矗立在近乎黑色的海军蓝背景上,背景中带有微弱的已路由连接线。近侧,若干小型琥珀色令牌形状在一道道细薄屏障后排成队列,而单个琥珀色令牌毫无阻碍地穿过门户开口,并拖曳出一道光线。虚线从门户向外呈扇形展开,向下延伸至一簇松散排列的小型几何服务节点。冷峻的板岩色结构,克制的青绿色与琥珀色点缀,扁平、类矢量的线条风格,无文字、无数字、无任何组织的标志,也无人物。OrcaRouter 标志合成在右下角。
AI Safety Incidents

CISA 将 LiteLLM 的 MCP 认证绕过漏洞加入 KEV:任意 Bearer Token 均可通过

作者

Rowan Sterling

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

2026年9月2日,美国网络安全和基础设施安全局将CVE-2026-59822以“BerriAI LiteLLM 身份验证不当漏洞”之名加入其已知被利用漏洞目录,这是当日批次中七个漏洞之一。该漏洞位于 LiteLLM 的 MCP Streamable HTTP 端点:当 LiteLLM 密钥验证失败时,OAuth2 直通回退逻辑并未拒绝请求,而是用一个空的 UserAPIKeyAuth() 对象取而代之,因此任何伪造的 Authorization Bearer 标头都能开启一个经过身份验证的 MCP 会话。能够访问该端点的攻击者可列出并调用网关配置的所有 MCP 工具,并通过这些工具访问其背后的服务。1.84.0 之前的所有版本均受影响,联邦文职机构被要求在 9 月 16 日前完成修复。该记录——LiteLLM MCP 身份验证绕过漏洞的 KEV 收录条目——是OrcaRouter AI Incident Archive中的一条条目,该档案包含完整记录集以及此事件的相邻条目。

代理中的一个漏洞之所以比其 CVSS 分数所显示的更重要,原因在于代理背后所承载的东西。Wiz 的威胁研究团队直言:“LiteLLM 代理可以持有它路由到的每个模型提供商的密钥,包括 OpenAI、Anthropic、Azure 和 Gemini。它还可能以云 IAM 权限运行,并通过 MCP 工具服务器连接内部服务。一次入侵就可能让攻击者获取代理下游的凭据和服务,而不仅仅是代理本身。”Wiz Research 表示其发现了该漏洞,Wiz 的蜜罐后来记录到了利用它的尝试。

机制:一次失败的检查却返回了有效会话

BerriAI 自己的安全公告 GHSA-7488-6r32-c95q 用两句话描述了该缺陷:“MCP 认证处理器支持对上游 MCP 服务器的 OAuth2 透传,但回退路径可能会用空的 UserAPIKeyAuth() 对象替代失败的 LiteLLM 密钥验证。这使得携带伪造 Authorization 头的请求能够在没有有效 LiteLLM 密钥的情况下到达 MCP 工具。”重要的词是 fallback。代码中有一个分支,用于那些直接透传上游 MCP 服务器 OAuth 令牌的部署;当 LiteLLM 密钥验证失败时,该分支返回的是一个空认证对象,而不是错误。

Screenshot of the GitHub security advisory GHSA-7488-6r32-c95q, titled 'MCP Authentication Bypass via OAuth2 Passthrough Fallback' and marked High with a CVSS v4 score of 8.8 out of 10. The package table shows litellm on pip, affected versions below 1.84.0, patched versions at or above 1.84.0. The Impact section states that LiteLLM's MCP Streamable HTTP endpoint could allow an unauthenticated attacker to establish an authenticated MCP session using an arbitrary Bearer token, that the MCP auth handler's OAuth2 passthrough fallback could replace failed LiteLLM key validation with an empty UserAPIKeyAuth() object, and that an attacker could list and call configured MCP tools and access connected services exposed through MCP. A Patches section says the issue is fixed in 1.84.0. A Workarounds section says that if upgrading is not immediately possible, disable MCP routes or block access to /mcp/ and related MCP endpoints at the reverse proxy or API gateway. The severity panel lists Attack Vector Network, Complexity Low, Requirements None, Privileges Required None; the CVE ID field reads CVE-2026-59822.

空认证对象与没有认证对象并不相同。下游代码看到一个成功构造的 UserAPIKeyAuth 后便继续执行,而该对象未附加任何租户、用户和范围。Wiz 的文章更直白地指出了实际后果:“当令牌验证失败时,服务器不会拒绝请求,而是返回一个没有任何限制的空 UserAPIKeyAuth() 对象。任何 Bearer 令牌(哪怕只有一个字符,例如 x)都会授予完整的 MCP 访问权限。”

OrcaRouter card titled 'What the fallback path did', subtitled that the failure happened after validation rather than before it, in every version before LiteLLM 1.84.0. Four stages run left to right. Stage 1, Request arrives: the attacker holds no LiteLLM key, and a code block shows GET /mcp/ with the header Authorization: Bearer x. Stage 2, Key validation: the supplied token is checked and does not resolve to a key, marked FAIL, with a red tag reading NO REJECTION. Stage 3, OAuth2 passthrough fallback: intended for upstream OAuth tokens, it returned an object rather than an error, showing UserAPIKeyAuth(), with an amber tag reading EMPTY, NO SCOPE. Stage 4, MCP tooling: tools can be listed and called and connected services reached, showing tools/list followed by tools/call, with a green tag reading SESSION AUTHENTICATED. A lower band headed 'Why it held' explains that the branch returned a constructed authentication object rather than a boolean, so downstream code had a valid-looking UserAPIKeyAuth to read and no reason to ask whether the key behind it existed. A footer credits BerriAI advisory GHSA-7488-6r32-c95q and Wiz Research's 27 August 2026 write-up.

这相当于给攻击者提供了一份菜单。MCP 协议会公开工具清单,因此通过身份验证的会话会返回网关已配置可访问的每个工具的名称和架构——在 Wiz 的示例中包括数据库、代码仓库、内部 API。厂商公告直白地说明了影响:“攻击者可以利用这一点列出并调用已配置的 MCP 工具,并访问通过 MCP 暴露的连接服务。”随后,这些工具调用会以代理自身对这些后端所拥有的权限执行,这正是 Wiz 所描述的凭据集中问题。

五月修复,七月CVE,九月联邦截止日期

这些日期并不像读者可能以为的那样彼此对得上,而其中的间隔才是耐人寻味之处。根据包索引自身的发布元数据,LiteLLM 1.84.0——公告中指明的首个已修复版本——于 2026 年 5 月 14 日上传至 PyPI。该 CVE 编号于 2026 年 7 月 7 日通过 CVE Program 预留,记录于次日 7 月 8 日发布;OSV 条目 PYSEC-2026-3479 随后于 7 月 23 日出现。KEV 清单于 9 月 2 日收录,修复截止日期为 9 月 16 日。

OrcaRouter timeline card titled 'From patch to federal deadline', subtitled that the fixed build shipped sixteen weeks before the KEV listing and that the patch was never the bottleneck. Five dated rows, each with the source that records it: 14 May 2026, LiteLLM 1.84.0 published, per PyPI release metadata; 7 July 2026, CVE identifier reserved with the CVE Program, per the CVE.org record; 8 July 2026, CVE-2026-59822 published, assigned by GitHub as CNA, with the OSV record PYSEC-2026-3479 following on 23 July; 2 September 2026, added to CISA KEV as one of seven entries that day, added on evidence of active exploitation; 16 September 2026, federal remediation deadline, due date set for federal civilian agencies under BOD 26-04. A footer reads that dates are as recorded by each source named in the right-hand column.

由此可得出两点。第一,在 CISA 将该漏洞列为已遭利用之前,修补后的版本已公开超过三个月——因此,受该截止期限约束的组织全程都有可用的升级版本,而 KEV 收录并不是修复方案出现的时刻。第二,自那以后版本差距进一步扩大:PyPI 上当前的 LiteLLM 版本是 1.106.5,于 2026 年 10 月 27 日上传。仍停留在低于 1.84.0 的任何版本上的部署,如今已落后二十多个次要版本,而不仅仅是少了一个补丁。

该清单确立了哪些内容,以及没有确立哪些内容

CISA针对该批次的公告称,这些新增条目是“基于存在活跃利用的证据”而加入的;目录中 CVE-2026-59822 的机器可读条目载明:添加日期为 2026 年 9 月 2 日,截止日期为 2026 年 9 月 16 日,已知勒索软件活动使用值为“Unknown”,并列出两个弱点:CWE-287(身份验证不当)和 CWE-306(关键功能缺少身份验证)。

• 已确认:CISA 评估该漏洞已被积极利用,并将其列入联邦修复清单。NVD 的 SSVC 记录归因于 CISA 协调员,时间戳为 2026 年 9 月 2 日,其中记录利用状态为“活跃”、可自动化性为“是”、技术影响为“部分”。

• 已确认:在受控环境中观察到了利用行为。Wiz 发布了蜜罐流量,显示使用单字符令牌的请求探测模型枚举端点:向 /v1/models 发送带有“Authorization: Bearer x”的 GET 请求。The Hacker News 在 9 月 3 日报道 KEV 批次时,将同一活动描述为 Wiz 观察到“涉及 CVE-2026-59822 针对其蜜罐的利用尝试,以探测模型枚举端点”。

• 已确认:严重性评分既存在,又因框架而异。BerriAI 的公告按 CVSS 4.0 将该漏洞评为 8.8,属于高危,其中机密性高、完整性低、可用性无;NIST 自己的 CVSS 3.1 评估(在 NVD 中为主要评分)则将其定为 8.2。这两个数字描述的是不同评分体系下的同一缺陷,不应把它们当作一个取代另一个来比较。

• 尚未确认:任何具名受害者。CISA 的警报、BerriAI 的公告、Wiz 的分析文章以及 The Hacker News 的报道,均未指明有哪个组织的 MCP 工具通过该漏洞被访问,也未报告从任何组织获取了凭据或数据。公开的利用记录是蜜罐遥测数据和一项联邦认定,而非已披露的入侵事件。

• 尚未证实:没有任何勒索软件团伙使用它。KEV 字段显示为“Unknown”,这是 CISA 分配的一个值,并非表明其不存在(无论哪种情况)的认定。

六月的先例,以及这并非远程代码执行链

这是2026年第二个进入KEV目录的LiteLLM漏洞,而较早的那个很容易与它混淆。CVE-2026-42271于2026年6月8日被加入,截止日期为6月22日,是LiteLLM的MCP服务器测试端点中的命令注入漏洞:Wiz描述称,这些端点允许用户在保存前测试MCP服务器配置,其中command字段未经校验就被传递给子进程执行。攻击者提交了一个伪造的stdio服务器配置,其command下载并运行了加密货币挖矿程序,并返回了一个看似有效的MCP握手,使测试看起来成功。CISA针对该漏洞的条目列出了CWE-78和CWE-77——命令注入和参数注入,而非认证问题。

那个缺陷才是可被串联利用的。Wiz 表示,CVE-2026-42271“可与 Starlette 主机头校验绕过(CVE-2026-48710)串联,从而实现完全未认证的 RCE”,并且外部研究人员已将 Qilin 勒索软件团伙与该利用链的实际利用联系起来。CVE-2026-48710 与 LiteLLM 绕过漏洞在同一批(9 月 2 日)被加入 KEV 目录,截止日期也同为 9 月 16 日,而 CISA 自己针对 Starlette 漏洞的目录说明称,该漏洞可与 CVE-2026-42271 串联。Qilin 的关联属于这一配对。它不是关于 CVE-2026-59822 的发现,且所审查的来源中没有任何内容将勒索软件团伙与身份验证绕过联系起来。

一个行政细节将两个 LiteLLM 条目区分开来:6 月清单中的所需行动引用的是较早的约束性运营指令 BOD 22-01,而 9 月清单引用的是 BOD 26-04《基于风险优先处理安全更新》。CISA 的警报没有解释这一变化,目录也没有对此加以注释。

之后发生了什么变化

修复路径很短。BerriAI 的公告建议升级到 1.84.0 或更高版本,并为无法立即升级的团队提供了一种变通方案:“禁用 MCP 路由,或在反向代理或 API 网关处阻止对 /mcp/ 及相关 MCP 端点的访问。”这种变通方案是一种粗暴手段——它移除了该能力,而不是对其进行访问控制——但这是厂商为未打补丁的部署指出的唯一缓解措施。

CISA针对这些入口点给出的“必需行动”说明,让联邦机构面临同样的权衡:按照供应商说明并遵照BOD 26-04应用缓解措施,“或在无法获得缓解措施的情况下停止使用该产品”,同时由各机构自行负责评估资产的互联网暴露情况。该指令仅对联邦文职行政部门机构具有约束力;CISA鼓励其他组织采用同样的基于风险的优先级排序方法,但并不强制要求。

除蜜罐之外是否有人在该截止日期前采取行动,目前尚不公开。CISA 和 BerriAI 均未公布以下数据:有多少 LiteLLM 部署遭到暴露、有多少在 9 月 16 日前完成修补,以及有多少通过该绕过方式被触及。

尚待解决的事项

有三处空白值得点明,而不是加以粉饰。没有公开的事件报告将 CVE-2026-59822 与某次具体入侵关联起来,因此 KEV 收录依据的是 CISA 的利用证据和 Wiz 的蜜罐观察结果,而不是有记录在案的受害者。厂商没有说明回退路径为何会写成那样,也没有说明它在 1.84.0 之前存在了多久——公告描述的是缺陷及其修复,而不是其历史。而且这批条目的截止期限并不统一:9 月 2 日新增的七个条目中有五个的截止日期为 9 月 5 日,而 LiteLLM 和 Starlette 条目则为 9 月 16 日。CISA 没有说明原因。

已经确定的部分比那个评分更窄,也更有用。在受影响的版本上,Authorization 头里的单个字符,对 MCP 端点来说与一个有效密钥无法区分——而那些表现出这种行为的版本,到 2026 年 5 月就不再是当前版本了。