Argo CD MCP server —— argocd-mcp，以 argoproj-labs 名义发布 —— 在 2026 年 8 月 29 日 15:30:21 UTC 获得了 CVE-2026-82456，并在 CVSS 3.1 和 CVSS 4.0 中都被评为 10.0。这已经是该量表允许的最高分。从实质上说，这也并不新。
修复早于该 CVE 18 天
维护者在 8 月 11 日 15:47:14 UTC 就发布了针对这一相同问题的自有安全公告，标注为 “No known CVE”，并在此前 15 分钟、即同日 15:32:50 UTC 发布了补丁，版本为 v0.9.0。他们自己给出的评分也是 10.0。8 月 29 日的记录，只是行业编号体系在追赶一项已公开两周多的修复。
分数不会告诉你的事
问题就在这里：标题中的数字会误导人。该漏洞被归类为 CWE-1327，即绑定到不受限制的地址，影响的是在使用 HTTP 或 SSE transport 时运行的 0.8.0 版本：监听器会绑定所有接口，并在没有身份验证的情况下接受 MCP 会话。但这种传输方式并不是项目会引导任何人使用的默认选项。项目的安装示例配置的是 stdio，它根本无法通过网络访问。10.0 描述的是某种配置下的最坏情况，而文档并不会把这种配置交到你手上。
真正值得关注的是底层设计问题
0.9.0 版本做了三件事：默认将 HTTP 和 SSE 监听绑定到 127.0.0.1，新增单独的 MCP_AUTH_TOKEN 用于验证传入调用者，并且不再把 Argo CD 凭证的存在视为访问控制的一种形式。最后这一点才是真正的教训。ARGOCD_API_TOKEN 是一种 出站 凭证——它用于让服务器向 Argo CD 证明自己的身份。它从未用于验证任何向服务器发起调用的人。0.8.0 版本发布于 6 月 11 日，因此运行网络传输模式的运维人员面临了一个 61 天 的暴露窗口。
而且这份记录再次无法被工具读取
与四分钟前发布的 Skyvern 安全公告一样，CVE-2026-82456 的 GitHub 安全公告记录包含一个 空的结构化漏洞数组——没有包版本范围，也没有首个修复版本。两项发生在智能体基础设施上的最高和接近最高严重级别问题都在同一天下午落地，但都无法被自动匹配到锁定文件。