自己搭了 MCP 服务器、用 HTTP + OAuth 对外开放的，这两条公告要一起看：升级完不改配置，漏洞还在。 事实部分（来源：AWS 安全公告 202… · @0xwolverines · TwKit

@0xwolverines

自己搭了 MCP 服务器、用 HTTP + OAuth 对外开放的，这两条公告要一起看：升级完不改配置，漏洞还在。 事实部分（来源：AWS 安全公告 2026-152-AWS（10/27）、MCP Python SDK 的 GitHub 公告 GHSA-w4fh-qvv9-3v23，北京时间 10/30 核验）： 1. 同一个毛病：服务器只验 token 的签名、签发方和有效期，不验"这张 token 是发给谁"（aud 字段）。同一个身份平台给别的应用签的 token，拿来也能用。 2. AWS API MCP Server（CVE-2026-115413）：影响 1.3.0 到 1.6.0 之前，只在 streamable-http + OAuth 模式下。后果是别人可能用你主机上配的 AWS 凭证调 AWS API。 3. AWS 的修法：升到 1.6.0，并且设置 AUTH_AUDIENCE；用 Amazon Cognito 这类 token 里没有 aud 的，改设 AUTH_CLIENT_ID。暂时升不了，就退回默认的 stdio 模式。 4. MCP Python SDK（CVE-2026-116684，CVSS 6.8）：影响 mcp 1.10.0–1.29.1、2.0.0–2.1.1，修复版是 1.30.0 / 2.2.0。 5. 公告原话是"Upgrading alone changes nothing"：新版加的 validate_token_resource 默认关闭，要同时设 resource_server_url，并在 verify_token() 里把 token 的 aud 返回成 AccessToken.resource。只开第一项，所有请求都会 401。3.0 才会默认开启。 我的判断： 这类洞不靠什么高超攻击，前提只是"你的身份平台同时给好几个应用发 token"，公司内部这很常见。更麻烦的是修复默认不生效，扫描器看版本号显示已修，实际照样放行。MCP 服务器后面接的往往是云账号、数据库这种高权限凭证，所以我会把它当高危处理，不看 6.8 这个分。 我会这么做： 1. pip show awslabs.aws-api-mcp-server 和 pip show mcp，对一下版本。 2. 升级后用一张发给别的应用的 token 去请求自己的服务器，返回 401 才算修好。 3. 给 MCP 服务器配的云凭证收到最小权限，别直接给管理员角色。 4. 只在本机用的，就保持 stdio，不开 HTTP。 利益说明：与 AWS、Anthropic 无合作或推广关系；这是安全信息整理，未在生产环境复现。 你的 MCP 服务器是怎么验 token 的？ #AI安全 #MCP #Agent

曝光 18 · 评论 2 · 点赞 0 · 书签 0