CISA将LiteLLM身份验证漏洞列入已知被利用漏洞目录

CISA已将涉及BerriAI LiteLLM的CVE-2026-59822列入“已知被利用漏洞”目录，确认存在在野利用证据但未说明攻击规模。开发者已在1.84.0中修复相关OAuth 2.0透传和MCP公开路由问题，建议尽快升级并检查日志与MCP暴露情况。

美国网络安全与基础设施安全局（CISA）9月2日将包括BerriAI LiteLLM身份验证漏洞在内的7个漏洞加入“已知被利用漏洞”（Known Exploited Vulnerabilities，KEV）目录。此次列入意味着CISA掌握了这些漏洞已在野外遭利用的证据，但并不等同于已经确认存在针对LiteLLM用户的大规模攻击。

被列入的LiteLLM漏洞编号为CVE-2026-59822，CISA给出的名称是“BerriAI LiteLLM Improper Authentication Vulnerability”。同批加入目录的还包括Sangoma Switchvox、Kludex Starlette、Kestra OSS、JFrog Artifactory以及SonicWall SMA1000设备相关漏洞。

CISA在公告中表示，这些漏洞是恶意网络行为者经常利用的攻击入口，并可能对联邦企业环境构成重大风险。该机构同时强调，KEV目录的作用是帮助组织按照风险和实际威胁活动安排漏洞修复优先级。

漏洞影响MCP工具调用的身份验证边界

根据LiteLLM在GitHub发布的安全公告，CVE-2026-59822影响LiteLLM的MCP Streamable HTTP端点。LiteLLM是一种代理服务器和AI网关，可用统一接口调用不同的大型语言模型；MCP则被越来越多的AI客户端和代理用来连接外部工具与服务。

公告称，在受影响版本中，未认证攻击者可以使用伪造的Bearer令牌，触发OAuth 2.0透传的回退路径。该路径可能把失败的LiteLLM密钥验证替换为空的UserAPIKeyAuth()对象，使请求在没有有效LiteLLM密钥的情况下继续到达MCP工具。

如果相关服务已经配置了MCP工具和外部连接，这种越过网关身份验证的方式可能让攻击者列出并调用已配置的工具，或接触通过MCP暴露的连接服务。美国国家标准与技术研究院（NIST）的NVD条目也采用了这一描述，并确认该漏洞已经进入CISA的KEV目录。

LiteLLM项目维护者在后续修复中进一步收紧了两条路径：一是将公开路由的判断限制在/.well-known/路径前缀，避免攻击者通过查询字符串、主机名或更深层路径“夹带”标记；二是只有当请求目标明确对应到运营者配置为auth_type=oauth2的MCP服务器时，OAuth 2.0透传回退才会生效。对于无法解析目标、目标为空或使用其他认证类型的服务器，认证失败应当直接终止请求。

相关改动见LiteLLM的修复提交和拉取请求。

修复版本与联邦机构期限

GitHub安全公告列出的受影响范围是LiteLLM 1.84.0之前的版本，修复版本为1.84.0及之后版本。LiteLLM的v1.84.0发布页面也将收紧MCP公开路由检测和OAuth 2.0回退控制列为变更之一。公告建议用户升级到1.84.0或更高版本；若暂时不能升级，应在反向代理或API网关阻断/mcp/及相关MCP端点，或直接禁用MCP路由。

NVD记录显示，该漏洞的CVSS 4.0基础评分为8.8，攻击向量为网络，攻击复杂度低，不需要预先权限或用户交互；其主要影响被描述为未经授权访问MCP工具可能接触的机密信息。评分反映的是漏洞的技术风险属性，不代表实际攻击规模或任何特定组织已经遭受的损失。

对美国联邦民事行政部门而言，NVD列出的修复期限为2026年9月16日。CISA的相关要求主要通过面向联邦民事行政部门的约束性指令执行；CISA也鼓励政府以外的组织采用基于风险的漏洞管理方法。

这类要求尤其值得部署AI代理、MCP服务器和统一模型网关的团队关注。AI代理的风险并不只来自模型本身，也来自代理能够调用哪些工具、工具背后连接了哪些系统，以及网关是否在每一次请求中正确验证调用者身份和目标范围。AIFlux此前报道的阿里云开源ApsaraDB MCP Server显示，临时账号、命令分级和人工确认正在成为工具层权限控制的一部分；而OpenAI公布的AI代理安全事件技术报告则说明，工具链和共享服务的边界会影响代理行为最终能延伸到哪里。

KEV列名不等于攻击范围已经明朗

目前可以确认的是，CISA已将CVE-2026-59822列入KEV目录，并依据其目录标准认定存在在野利用证据；LiteLLM官方安全公告说明了漏洞的认证绕过机制、影响范围和修复版本；NVD则记录了受影响版本、修复版本以及联邦机构期限。

但公开的CISA公告没有披露具体攻击组织、受害者、攻击时间窗口、利用样本或攻击规模。现有材料也不足以证明LiteLLM部署已经遭遇普遍性或大规模攻击。部署方应把“存在在野利用证据”理解为提高处置优先级的信号，同时根据自身是否启用了MCP Streamable HTTP端点、是否将服务暴露在互联网、配置了哪些工具和外部连接，判断实际风险。

下一步的重点是核对LiteLLM版本和MCP路由暴露情况，升级至1.84.0或更高版本，并检查访问日志、认证失败记录、MCP工具调用记录及相关外部服务日志。若系统曾在暴露状态下运行，单纯升级并不能替代对历史访问的审查；具体调查范围和取证方式仍应以LiteLLM后续安全通告、组织自身日志以及CISA的指导为准。

来源：CISA安全公告、CISA KEV目录、BerriAI LiteLLM安全公告、NIST NVD。