KEV 清单上首例 MCP CVE 抵达联邦修复期限:LiteLLM 与默认密钥保险库
CVE-2026-59822 是 BerriAI LiteLLM 代理中的认证绕过——该开源网关在应用与 100 多个模型提供商之间路由流量——并于 2026 年 9 月 16 日抵达其联邦修复截止日期。CISA 于 9 月 2 日将该漏洞加入其已知被利用漏洞目录,根据 BOD 26-04 将截止日期定为今日,使其成为首个被国家级漏洞管理当局列为积极利用的 Model Context Protocol 实现(NVD;The Hacker News)。利用并非理论上的:Wiz 的蜜罐基础设施于 7 月 7 日——即列入 KEV 名单 56 天前——观测到 CVE-2026-59822 在野外被使用(Wiz)。而且该 CVE 甚至不是进入这些网关最常见的方式。Wiz 2026 年 2 月对 3,074 个面向互联网的 LiteLLM 实例的扫描发现 294 个——9.6%——接受 LiteLLM 自家文档中印出的示例主密钥 sk-1234,另有 191 个完全未配置认证(Wiz;The Hacker News)。
本文覆盖工程负责人或平台主管在下一次审计在其网络中发现 LiteLLM 实例之前需要的四件事:绕过如何在一次请求中生效、为什么主密钥使网关成为云凭证保险库、KEV 期限实际要求什么,以及关闭暴露面的六项核查——外加要从你拥有的每个 MCP 认证处理器中禁用的代码模式。
核心要点
- CVE-2026-59822 是 CISA KEV 清单上首例 MCP 专属 CVE——2026 年 9 月 2 日加入,联邦修复截止日期为 2026 年 9 月 16 日,CVSS 8.8,影响 1.84.0 之前的所有 LiteLLM 版本。
- Wiz 的蜜罐于 2026 年 7 月 7 日观测到利用——比 KEV 列名早 56 天——单个字符的 Bearer 令牌即可建立完全认证的 MCP 会话。
- 3,074 个面向互联网的 LiteLLM 网关中有 294 个(9.6%)接受文档记载的示例主密钥
sk-1234或完全不设认证——其中 191 个不需要任何凭证,据 Wiz 2026 年 2 月的 Shodan 扫描。 - 主密钥是一座云凭证保险库:持有有效管理员身份(或握有密钥的攻击者)可以通过直通路由读取 AWS 实例元数据并取回 IAM 凭证,IMDSv2 无法阻止,因为代理会转发
x-pass-前缀的头。 - 绕过是代码模式,不只是缺陷:捕获认证失败并替换为空认证对象。ACM 发表的 "Puppet" 研究显示这一混淆代理类攻击的工具选择劫持成功率达 90.89%,且对 MCP-Scan 与 McpSafetyScanner 不可见。
24 小时的时钟,以及绕过如何在一次请求中生效
时间线之所以重要,是因为它表明利用在每个阶段都跑在联邦响应前面。Wiz 于 2026 年 2 月 18 日向 LiteLLM 维护者报告该漏洞;修复于 4 月 25 日随 LiteLLM 1.84.0 发布;Wiz 的蜜罐于 7 月 7 日记录到真实世界的利用;漏洞于 7 月 8 日公开;CISA 于 9 月 2 日将其加入 KEV 目录——并将修复截止日期定在 14 天后(Wiz;NVD)。
机制是 LiteLLM MCP 端点中的 fail-open 回退。该端点支持两种认证模式:LiteLLM 原生密钥和透传给上游 MCP 服务器的 OAuth2 令牌。当 Bearer 令牌以 401 或 403 未通过 LiteLLM 密钥验证时,处理器本应向上游转发该令牌。实际上它捕获错误并返回空的 UserAPIKeyAuth() 对象——一个背后没有任何身份的已认证会话(Wiz;GitLab 公告数据库)。Wiz 的演示使用 Authorization: Bearer *** ——单个字符——并收到带有效 mcp-session-id` 的 HTTP 200。
该会话能触及什么完全取决于部署配置。连接了数据库查询工具的网关会把查询权限交给攻击者;GitHub 集成交出仓库读取和 issue 创建;文件系统连接器交出读写文件权限。LiteLLM 文档记载的 allow_all_keys 旗标——LiteLLM 自己为"低风险工具"推荐——使每个已配置的 MCP 服务器都可被绕过创建的空凭证触达(Hive Security)。爆炸半径不是代理本身。是代理的 MCP 服务器接触到的每一个系统。
三种失效,一个网关
Wiz 的研究在 LiteLLM 中发现了四个前提条件各不相同的问题——把它们压扁成一条"魔法链"既误报严重性也误导应对(Wiz):
- CVE-2026-59822 —— MCP 认证绕过。 无需认证,一次请求,1.84.0 之前版本。已在 1.84.0 修复。
- CVE-2026-59821 —— 通过自定义 guardrail 实现的 root 级代码执行。 guardrail 注册端点把管理员提交的 Python 传给
exec(),未套用 UI 测试路径上的沙箱(builtins 剥离、禁止模式检查)。Wiz 观测到代码在代理容器中以 root 运行。已在 1.82.0-stable 修复。这一条需要管理员权限——但与失效模式 3 组合后实际上变成预认证可利用。 - 默认或缺失认证。 即 294/3,074 的扫描结果。当未配置主密钥时,LiteLLM 向每个调用方授予
PROXY_ADMIN访问——一种与 CVE-2026-59821 一同修复的无 CVE 设计行为。 - 直通路由到云元数据。 已认证的管理员可以把直通路由指向 AWS 实例元数据服务,并借助代理剥离
x-pass-前缀的行为转发 IMDSv2 会话令牌头。Wiz 与 LiteLLM 将其归类为预期的管理员行为——无 CVE、无修复。但一旦默认或泄露的主密钥抹掉了"只有可信管理员持有密钥"这一假设,这种"预期"能力就成为从应用失陷走向云账户失陷的路径(CSA)。
叠加才是故事。LiteLLM 保存着每个已配置模型提供商的 API 密钥——OpenAI、Anthropic、AWS Bedrock、Azure、Google Vertex AI——并且约三分之一的受调查云环境运行着部署(CSA)。CSA 的研究简报把主密钥配置称为"云凭证保险库"。这座保险库已被清空过一次:在 2026 年 8 月公开披露的一次失陷中,攻击者通过在网关主机上的代码执行读取容器环境变量,取回主密钥和一条数据库连接串,并直接从网关背后的 PostgreSQL 数据库中复制记录(CSA)。
打了补丁的实例不是安全实例。一台补到 1.84.0 仍然应答 sk-1234 的网关,对任何知道默认密钥的人都是失陷的——而读过 README 的人都知道。
KEV 列名实际要求什么
已知被利用漏洞目录不是严重性排序。它是一个带约束时钟的积极利用认定:根据 BOD 26-04,联邦文职机构必须在截止日期前应用厂商缓解措施或停用该产品,且机构须优先处理面向互联网的实例。今天到期的期限直接适用于联邦机构——但其影响延伸得更远,因为越来越多的网络保险保单和供应商风险问卷将 KEV 目录引用为基线(Tech Insider)。未修复的 CVE-2026-59822 实例如今对任何其合规制度继承 KEV 清单的组织都是审计发现项,无论该组织是否为联邦机构。
这一里程碑的意义在于协议本身,而不仅是产品。CVE-2026-42271——LiteLLM 测试端点命令注入,更早批次加入 KEV——是 MCP 邻接的。CVE-2026-59822 是 MCP 专属的:被利用的面就是 MCP Streamable HTTP 端点及其认证处理器。首个带联邦修复要求的 MCP 漏洞预示了下一批将从哪里来。UltraViolet Cyber 的威胁通告统计 2026 年单年针对 MCP 实现披露的 CVE 已超过 40 个(UltraViolet Cyber),Bitsight 的互联网扫描发现约 1,000 个暴露的 MCP 服务器在无授权情况下提供完整工具清单(Bitsight),Practical DevSecOps 测得 30–82% 的公共 MCP 服务器携带可利用缺陷(Practical DevSecOps)。首例 KEV 列名背后的暴露面栈不是离群值。它就是总体。
下面的图把事件压缩进一分钟:跑在联邦响应前面的时间线、共享同一网关的四种失效模式,以及关闭暴露面的六项核查。
六项核查
把主文精炼为 12 项控制的 MCP 安全加固清单现在补上网关专属的增补。六项,每项都可在数分钟内核验:
- 可证明地失效关闭。 向网关的
/mcp/端点发送 `Authorization: Bearer ***。配置正确的实例返回 401 或 403。易受攻击的实例返回 200 和会话 ID。这就是 CVE-2026-59822 测试,只需一次请求。 - 盘点并升级。 找出每个 LiteLLM 实例——包括开发者栈里的影子部署——记录其版本与镜像摘要,并钉住一个当前稳定版本。1.84.0 首次修复 CVE-2026-59822;1.82.0-stable 修复 CVE-2026-59821;此后仍有新公告,不要冻结在这两个最低版本上(Hive Security)。若无法立即升级,公告的临时缓解是在边缘封锁
/mcp/及相关路由。 - 轮换主密钥及其后的一切。 替换
sk-1234与任何复用的密钥。若怀疑暴露或可疑访问,轮换模型提供商、数据库、OAuth 与 MCP 连接服务凭证并撤销派生会话——文档化的失陷链显示网关失陷会直接级联为提供商密钥泄露与数据库拖库(CSA)。 - 约束 MCP 工具访问。 从敏感集成中移除
allow_all_keys,读写工具分离,并要求按团队授权。绕过授予的是会话能触及的一切——工具配置就是爆炸半径。 - 圈住控制平面。 除非明确要求,移除公开暴露;拒绝工作负载访问云元数据服务;对出口目的地设白名单;容器以非 root 且无特权挂载方式运行。IMDSv2 防不住这条路径,因为代理可以自己发起令牌请求并转发头部(Wiz)。
- 在日志过期前狩猎。 检查反向代理与 LiteLLM 日志中的垃圾令牌
/mcp/会话、意外工具调用、guardrail 创建事件和直通配置变更。与进程、DNS 和云审计日志关联——并在重启前保存证据,因为重启会清除内存状态但不会撤销被窃的凭证(Hive Security)。
第 1 和第 3 项是期限日的优先级:第一项证明漏洞,第二项关闭任何补丁都无法触及的长期暴露。
这对 LiteLLM 之外意味着什么
两个模式具有普适性,且都应进入此后每一次 MCP 认证评审。
第一:fail-open 回退是代码坏味道,不是 LiteLLM 独有的缺陷。 绕过只有三行——捕获 401,替换为空认证对象,继续。任何通过 passthrough 回退把认证委托给上游提供商的 MCP 代理都属于同一类。修复是一项评审标准,不是一次版本升级:上游验证失败时,请求终止。绝不带着未认证身份继续。
第二:网关是控制平面,混淆代理研究表明它们在元数据层失守。 ACM 发表的 "Puppet" 研究在 2 个 MCP 主机上对 14 个模型评估混淆代理攻击,测得工具选择劫持率最高 90.89%、端到端载荷执行率最高 86.46%——且对 MCP-Scan 与 McpSafetyScanner 不可见,二者在架构上无法捕捉元数据层操纵(ACM)。把模型凭证、提示可见性与工具访问集中到单一认证边界之后的网关,正是 CSA 的 AI Controls Matrix 为身份与密钥管理控制所标记的同一集中化(CSA)。操作层面的翻译:把网关当作控制平面来认证,当作失陷边界来圈限——最小权限 IAM、无默认凭证、元数据不可达、出口白名单。
更大的背景是一个从"可选授权"走向联邦执法的协议。Bitsight 2025 年 12 月的扫描发现约 1,000 个无授权暴露的 MCP 服务器(Bitsight);Wiz 2026 年 8 月的蜜罐分析记录了针对 LiteLLM、MCP 服务器与 AI 框架的活跃攻击活动——通过 RCE、盲提示注入与内存凭证窃取(Wiz);而 LiteLLM 的第三个认证绕过——CVE-2026-49468,2026 年 5 月 28 日披露的 Host 头注入——完成了 2026 年模式:同一产品在一年内内置了三个不同的认证失效(GitHub 公告)。KEV 列名正是该模式从研究课题变为合规清单项的节点。
MCP 2026-07-28 规范把协议推向无状态核心,生态系统的授权工作正走向带受众绑定令牌的 OAuth 2.1。架构能关闭整类漏洞。但 LiteLLM 事件证明运营层决定结果:一台无状态、符合规范、却仍接受示例主密钥的部署,依然是失陷的。先补 CVE,再审计默认配置——按这个顺序,在下一个期限之前。
相关阅读
- MCP 安全加固清单:1,467 个暴露服务器与关闭它们的控制——母篇文章:横跨传输、认证、工具注册、运行时与审计的 12 项加固控制,每项可在五分钟内核验
- MCP 悖论:为什么无摩擦即脆弱——协议层风险分析:让集成无摩擦的标准为何同时把失陷爆炸半径集中起来
- MCP 2026-07-28:无状态协议对 B2B 代理部署意味着什么——消除此类 CVE 所利用的会话状态攻击面的无状态协议核心
一家中型分销商运行着报价对象为 NetSuite、BigCommerce 和三个供应商目录的采购代理,由一台 LiteLLM 网关路由模型流量并暴露代理的 MCP 工具。对 /mcp/ 的一次单请求验证证明网关失效关闭;主密钥来自密钥管理器,而非 README;网关的 IAM 角色无法触及实例元数据;代理可调用的 MCP 工具被限定为读取价格和写入报价——别无其他。当下一份 KEV 列名落地时,修复是一次版本升级,而不是一次失陷调查。
申请一个范围明确的构建。一周发现期。您将获得系统清单、工作流地图和固定范围——无论您是否与我们合作构建。
想为您的系统构建这个吗?
这里的每份文档都来自真实的生产工作。如果您有目标系统和工作流想法,我们可以在一周内确定范围。
申请定制开发为期一周的发现阶段。您会拿到系统清单、工作流地图和固定范围——无论您最终是否与我们合作开发。