在 8 月 27 日 17:20:51.183 至 17:21:03.677 UTC 之间，VulnCheck 发布了 60 个 CVE。其中 13 个指向 MCP 服务器和 AI agent 工具：CVE-2026-81091 至 81102，外加针对 ByteDance 的 UI-TARS-desktop 的 CVE-2026-81735。被点名的项目包括 mcp-use、mark3labs/mcp-go、Apify、mcp-router、Timescale 的 pg-aiguide、Harvard 的 ToolUniverse、rails-mcp-server、Telnyx、Timescale 的 tiger-slack 和 tiger-gh-mcp-server、Airtable 的 MCP CLI 以及 Dropbox Dash。
一个上游默认设置解释了其中大多数问题
这些描述如出一辙。ByteDance 的 startServer.ts “在未提供主机时将其监听地址默认设为 '::'”。mcp-router 的 CLI “在每个接口上提供其 MCP 聚合器，仅在……时强制身份验证”。pg-aiguide “在未启用底层 SDK 提供的主机允许列表的情况下启动了其 MCP HTTP 传输”。mcp-go “在其 HTTP 传输上接受请求时未检查 Host 头”。这并不是 13 个彼此独立的失误——而是同一个 SDK，其中 DNS 重绑定防护是可选启用，而且其中三条是同一个 Timescale 模式在兄弟仓库中的重复出现。
评分自相矛盾
每个指标块在主、次 CVSS 中都标注了 [email protected]——没有厂商评分，也没有 NVD 评分。在 6 个条目上，这两组 VulnCheck 向量跨越了严重性边界。ToolUniverse 因同一个漏洞、同一天发布，分别被标为 9.3 CRITICAL 和 10.0 CRITICAL。mcp-go、pg-aiguide、tiger-slack 和 tiger-gh-mcp-server 则各自同时为 7.6 HIGH 和 6.8 MEDIUM。下游扫描器无论采信哪一个数字，都近乎任意。这 13 个条目中没有一个带有 CPE 版本范围。
常见叙事哪里错了
这则故事看起来像一场针对 MCP 的协同行动。其实不是。这 13 个条目只是一次 60 个 CVE 的批量积压清理中的六分之一——其中 27 个属于一个无关的密码学项目，而这一批还顺带覆盖了 Ruby 的 resolv gem、Craft CMS 和 FrontAccounting。若据此解读为“MCP 正在遭受攻击”，那读到的是一次批量导入留下的痕迹。
第二个需要纠正的地方是时间。每个修复都早在披露前就已合并——Apify 的修复早了 50 到 161 天不等，mcp-go 的则早在 7 月 8 日。Apify 的 CVE 指向一个文件，而拉取请求 #572 作为依赖清理的附带影响将其 删除；自 3 月的 0.9.12 版本起，该文件就已从 npm 中消失，当前版本为 0.15.3。最明确的是：Telnyx 的“修复”拉取请求，加入了 CVE 所称存在漏洞的那个文件。