CVE-2026-108586：1MCP Agent 的 OAuth 标签作用域被取反表达式绕过
NVD 十月十四日收录 CVE-2026-108586：1MCP Agent（@1mcp/agent）0.20.0 到 0.39.0 存在授权错误。攻击者持有一个单标签的 OAuth token，本应只能访问带该标签的工具；但高级标签过滤器支持取反表达式 not ，攻击者可以发「not 已授权标签」这样的过滤器，列出并调用后端 MCP 服务器上所有不在授权范围内的工具。NVD 把这个归为 incorrect authorization（CWE-863）。 取反表达式为什么会变成越权通道？ 授权模型的设计是：token 授予了标签 A，客户端只能请求 tag=A 的工具。但过滤器语法支持 not A，语义是「所有不带 A 的工具」。服务端在解析过滤器时，把 not A 当成一个合法查询条件去执行，而不是在授权层拒绝。这是典型的「查询条件 vs 授权条件」混淆——服务端把过滤器当成数据查询，却忘记了授权范围是「只能在 A 里查」，不是「可以在全表里查 not A」。 攻击影响有多大？ MCP 服务器通常把数据库、文件系统、内部 API 都暴露成工具。一个本该只读客户标签的 token，通过 not 过滤器可以列出所有内部工具、调用管理员接口、读别的租户数据。这不是读少了，是直接越权到全量工具。NVD 描述里明确写了「list and invoke tools on backend MCP servers outside their granted scopes」。 修复和教训是什么？ 升级到 0.39.0 之后版本。对所有实现 tag-based 授权的团队，教训是：过滤器表达式在授权层必须先求授权范围的交集，而不是直接下推到数据层。任何支持 not、or、通配符的过滤语法，都是越权重灾区——默认拒绝，而不是默认放行。 还要补一个设计层面的教训。基于标签的授权模型本身是好设计——它让权限粒度到工具级。但只要过滤器语法支持否定、集合运算，授权层就不能简单信任客户端传来的过滤条件。正确做法是：服务端先把 token 允许的标签集合算出来，然后把客户端的过滤器跟这个集合求交集，而不是让过滤器直接作用于全表。所有做 MCP 网关、agent 平台的团队，都应该立刻审计自己的标签过滤实现。这个洞的 CVSS 还在评估，但从「越权调用任意后端工具」看，至少是高危。 ...