2026 年 9 月 2 日，美国网络安全与基础设施安全局（CISA）将 CVE-2026-59822 列入「已知利用漏洞目录」（Known Exploited Vulnerabilities，KEV）。这本身不算新闻——KEV 目录每周都在更新。但这次不一样：被列入的是一个 MCP 协议栈组件的漏洞，而且 CISA 给出的修复截止日期是 9 月 16 日，意味着联邦机构必须在一周内打补丁或下线。

这是 MCP（Model Context Protocol）诞生以来，第一次以「正在被积极利用的安全漏洞」身份登上政府级强制修复清单。

对 MCP 生态来说，这不是一次普通的漏洞披露，而是一个信号：MCP 已经从「实验性协议」进入「生产基础设施」阶段——而生产基础设施的第一个标志，就是它开始被攻击者认真对待。

漏洞本身：LiteLLM 的 MCP 端点授权绕过

被列入 KEV 的漏洞编号是 CVE-2026-59822，CVSS 8.8（高危），影响的是 BerriAI 的 LiteLLM 代理——一个被 Docker 拉取超过 2.4 亿次的流行开源 AI 网关。

问题出在 LiteLLM 的 MCP Streamable HTTP 端点。正常流程应该是：客户端发送 Bearer Token → 服务端验证签名、发行者、受众、有效期和撤销状态 → 将可信主体映射到会话。但漏洞路径把「请求带了 Authorization 头」和「这个令牌代表合法用户」混为一谈——任意字符串一旦通过错误分支，就获得了已认证会话的状态标签。

换句话说：攻击者可以用任意伪造的 Token，在 MCP 代理上建立一个完全认证的会话。然后，他们可以枚举代理暴露的所有工具、资源和提示，按协议发起调用。如果 LiteLLM 代理同时连接了云模型 API、数据库 MCP 服务器、文件系统工具或内部 HTTP 服务——这些能力全部沿代理身份向下传播，攻击者获得的不只是「聊天权限」，而是 Agent 控制面的入口。

这还不是唯一的问题。Wiz Research 对 3,074 个暴露在公网上的 LiteLLM 实例做了一次扫描，结果令人不安：

• 9.6% 的实例接受默认主密钥 sk-1234 或根本不需要身份验证
• 约 1/3 的云环境运行着 LiteLLM 部署
• CVE-2026-59821：任何有效 API Key 都可以在容器内以 root 权限执行 Python 代码
• CVE-2026-59822：MCP 端点允许无凭证登录并访问已连接的工具

两个漏洞都已修补，但 Wiz 指出第三个问题「不会修」：LiteLLM 的 pass-through 端点不做 URL 验证，持有主密钥的人可以把它指向 169.254.169.254（云元数据服务），直接读取实例角色凭证。IMDSv2 也救不了——因为 x-pass- 头会去掉前缀转发。

不只是 LiteLLM：AWS MCP 数据库服务器的 SQL 注入

几乎同一时间，AWS Labs 自维护的 MCP 服务器也暴露了两个 CVE：

• CVE-2026-87911（PostgreSQL MCP Server，1.1.7 之前版本）：通过 COPY ... TO PROGRAM 配合 PG_WIRE_PROTOCOL 和超级用户权限，在只读模式下实现操作系统命令执行。
• CVE-2026-85788（MySQL MCP Server，1.0.21 及更早版本）：SQL 行内注释绕过只读过滤，1.0.23 已修复。

两个漏洞暴露的是同一个结构性问题：基于字符串匹配的只读强制执行，不足以作为 AI 到数据库访问的最后一道防线。 当大模型生成的 SQL 包含精心构造的行内注释时，简单的关键词过滤会被绕过；而当 MCP 服务器在数据库中以高权限运行时，一个 COPY ... TO PROGRAM 就能变成 RCE。

把这三个事件放在一起看，图案就清晰了：MCP 的攻击面不是某个实现的单点缺陷，而是协议生态在快速扩张中积累的结构性安全债。

MCP 2.1 与 OpenMCP 2.0：协议层在补课

安全漏洞的集中爆发倒逼协议层加速成熟。本周 MCP 联盟发布了规范 2.1 版本，最重要的变化是双向流式传输——服务器可以在不轮询的情况下主动向客户端推送上下文更新，在 Agent 到 Agent 的场景中延迟降低最多 80%。Anthropic、微软和谷歌已承诺在 2026 年第四季度前完成实现。

同时获批的 OpenMCP 2.0 引入了标准化的向量存储集成和跨提供者的上下文可移植性——这意味着一个 MCP 客户端配置的上下文可以在不同模型提供者之间迁移，减少锁定。

MCP SDK 下载量已达到 9700 万次。Broadcom、Citrix、CrowdStrike、ServiceNow 和 Genesys 五家企业级厂商在两周窗口内独立交付了几乎相同的三层 Agent 基础设施栈。协议正在从「连接器」变成「架构」。

MCPA：第一张 MCP 职业认证

9 月 14 日，Agentic AI Foundation（AAIF）发布了 Model Context Protocol Associate（MCPA）认证——首个厂商中立的 MCP 资格考试。

考试是在线监考的选择题，基于 2026 年 7 月 28 日发布的 MCP 规范版本，覆盖五个领域：

安全与治理占比 24%，仅次于交互与执行——这直接反映了 KEV 事件带来的行业反思。候选人需要理解权限、同意、可审计性和信任边界。NSA 在 2026 年 5 月 20 日发布的指导文件为这种强调提供了制度支撑：该文件标识了序列化风险、隐式信任关系、动态工具调用、上下文共享和未验证任务传播等风险。

不过，认证能证明工程师知道术语和预期控制，不能证明工程师能运维一个安全的生产部署。MCPA 是知识考试，不是性能测试——候选人不需要构建、调试或加固一个真实运行的 MCP 系统。

该做什么：MCP 安全审查清单

如果你在运行 MCP 基础设施，以下是一个务实的行动清单：

1. 立即审计所有 MCP 端点。不要只查公网资产——Wiz 的数据显示内网实例同样暴露于浏览器侧请求或被攻陷服务的横向触达。
2. 修补 LiteLLM。如果部署了 LiteLLM 代理，升级到已修复版本，关闭非必要的 MCP 能力，从网络层限制入口。
3. 轮换可能被接触的凭证。升级代码不会自动让既有会话、缓存或刷新令牌失效。需要关闭存量连接、清理服务端会话状态，确保新版本拒绝旧的伪造令牌。
4. 审查数据库 MCP 服务器的只读强制。字符串匹配不是防线。使用最小权限的数据库账户，而不是靠关键词过滤。
5. 验证而非检查。不能只在反向代理上要求 Authorization 头存在——代理必须验证令牌真实有效，或把认证交给一个唯一、可审计的身份组件。
6. 考虑 MCPA 认证。如果团队在规模化部署 MCP，MCPA 可以作为技能基线——但要清楚它是入门证书，不是运维能力的证明。

协议成熟的代价

MCP 的安全成人礼来了。一个协议从「值得尝试」到「必须加固」的转折点，往往不是某个里程碑式的发布，而是第一个被政府级机构确认「正在被积极利用」的漏洞。HTTP 经历过这个阶段，TLS 经历过这个阶段，现在轮到 MCP 了。

好消息是：协议层在响应。规范 2.1 的双向流、OpenMCP 2.0 的可移植性、MCPA 认证的安全占比——这些都是在「补课」。坏消息是：生态中 9.6% 的实例还在用默认密码裸奔，而攻击者已经知道这件事了。

参考来源

• CISA KEV 目录：https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Wiz Research: LiteLLM 扫描报告：https://cybernews.com/security/litellm-servers-exposed-require-no-password/
• CVE-2026-59822 NVD 条目：https://nvd.nist.gov/vuln/detail/CVE-2026-59822
• CVE-2026-87911 AWS PostgreSQL MCP Server：https://github.com/awslabs/mcp-postgresql
• CVE-2026-85788 AWS MySQL MCP Server：https://github.com/awslabs/mcp-mysql
• Agentic AI Foundation MCPA 认证公告：https://runtimewire.com/article/agentic-ai-foundation-mcpa-mcp-certification
• MCP 2.1 规范：https://modelcontextprotocol.io/specification
• OpenClaw Weekly MCP 安全综述：https://www.bighatgroup.com/blog/openclaw-weekly-2026-09-14
• AWS Security Digest LiteLLM 分析：https://awssecuritydigest.com/past-issues/aws-security-digest-278
• CVE-2026-53937 MCP Kotlin SDK OOM：https://ctiwatch.com/vulnerabilities/CVE-2026-53937