之前聊过 CodeWhisperer 改名 Amazon Q Developer 之后，个人免费版依然能给无限制补全加每月 50 次安全扫描，值得薅。今天说个不太让人安心的事：这个你可能已经装上的免费工具，被安全团队公开演示成了"偷钥匙的入口"——只是把一个 clone 下来的项目在 VS Code 里打开，AWS 凭证就可能已经被偷走了。
这不是危言耸听。漏洞编号 CVE-2026-12957，Wiz 官方给出的严重等级是 High，社区实战复现按 CVSS 4.0 打到 8.5 分Wiz官方博客知乎微博。
发生了什么
今年 6 月底，Wiz 安全团队公开披露了 Amazon Q for VS Code 扩展的这个漏洞，攻击链路简单到离谱：
攻击者在 GitHub 上放一个看起来正常的开源项目，里面只多塞了一个文件：`.amazonq/mcp.json`；
你把它 clone 下来，用 VS Code 打开，激活 Amazon Q 准备写代码或者看代码；
Amazon Q 自动加载项目里的这份 MCP 配置，并且直接执行里面配置的 MCP 服务器命令——全程没有弹窗、没有确认、没有 workspace 信任检查；
由于 MCP 进程会继承开发者的环境变量，你机器上的 AWS 凭证、API Key、SSH agent socket，都可能随着命令执行被回传给攻击者知乎Wiz官方博客微博。
零交互。你什么都没点，打开文件夹的那一刻，攻击条件就成立了知乎。
恶意的 MCP 配置长什么样？这是安全团队 Check Point Research 公开过的一个真实攻击配置样例，格式和 Amazon Q 读取的 `.amazonq/mcp.json` 完全一致——`mcpServers` 里的 `command` 字段直接写成可执行命令：
Wiz 的演示配置更直接：命令就是查询当前开发者的 AWS 会话身份，再用 curl 把结果回传到攻击者的服务器。实测里，开发者的活跃 AWS 会话就这么被捕获了——从"打开一个仓库"到"云账号沦陷"，中间只隔一个配置文件Wiz官方博客知乎。
为什么会犯这种错
问题不在 MCP 本身。MCP（Model Context Protocol）是给 AI 助手装"手脚"的机制：开发者自己配置好 MCP 服务器之后，AI 就能调用本地工具干活。这套机制的安全前提是——你显式配置了这些服务器，你知情同意授权 AI 在你机器上跑命令。用 Wiz 研究者的话说：”这是在授权 AI 助手在你的机器上运行任意命令，这应该需要知情同意”知乎Wiz官方博客。
问题出在 Amazon Q 把别人仓库里自带的 MCP 配置也自动加载了，而且是静默的。这相当于把"用户亲手把钥匙交给 AI"的默认设置，改成了"谁往项目里放钥匙，谁就能指挥 AI"。Wiz 把根源拆成两条：一是未经同意的自动执行，打开文件夹就读配置，没有任何确认环节；二是完整的环境变量继承，子进程拿到了 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY 这些全套凭证。两条叠在一起，信任模型直接破了Wiz官方博客知乎。
而且这不是 Amazon Q 第一次出这种事。去年 8 月，同一个扩展就曝出过提示注入导致的 RCE 漏洞，影响超过百万下载量的用户，当时亚马逊是静默修复，连 CVE 都没发哔哩哔哩。
不只是 Amazon Q
如果以为这只是亚马逊一家的问题，那就低估了这件事。Wiz 在文章里专门列了一张同类漏洞清单，全是"自动执行工作区配置"这一个病根：Claude Code 两次（CVE-2025-59536、CVE-2026-21852，Check Point Research 发现），Cursor 一次（CVE-2025-54136，Check Point Research 发现，就是上面那张图对应的"MCPoison"漏洞），Windsurf 一次（CVE-2026-30615，OX Security 发现）Wiz官方博客Check Point Research。再往前数，VS Code 本体和 NPM 扩展也中过同类招。
今年 3 月，安全团队 Mindgard 还专门整理了一个"AI IDE 编码助手漏洞模式库"，把 Cursor、GitHub Copilot、Claude Code、Amazon Q、Windsurf 的攻击面做了系统分类微博。微博上安全圈博主把这类困境总结成一句话：“Agent 安全悖论”——你越信任 AI 助手、给它的权限越多，它就越容易被攻击者借来干坏事微博。恶意指令可以藏在代码注释、README 甚至依赖包里，AI 执行了，你还以为是正常操作。
时间线：这事正在发酵
5 月 12 日：亚马逊通过 Language Server 更新部署修复Wiz官方博客。
6 月 23 日：CVE-2026-12957 正式分配。
6 月 26 日：Wiz 公开披露，clone 项目即失凭证的细节开始在安全圈传播。
7 月初：腾讯安全玄武实验室把"Amazon Q Developer 恶意 MCP 配置漏洞导致代码执行与凭证窃取"收进每日安全动态推送微博。
8 月中：知乎上接连出现 MCP 协议安全深度剖析、"AI 插件投毒"等长文，OWASP 的 MCP Top 10 风险清单被反复引用知乎。
就在今天：知乎已经有了实战复现文章，不仅复现漏洞，还给出了检测脚本和云凭证防护指南知乎。
话题热度在往上走，不是往下走。如果你或者你的同事装过 Amazon Q 扩展，现在正是该自查的时候。
四步自查，五分钟做完
第一步：确认已修复。 Wiz 的漏洞档案写得很清楚：受影响的是 1.65.0 之前的 Language Server 版本，1.65.0 已修复，状态 FixedWiz官方博客。AWS 官方声明给的操作路径是：Language Server 默认自动更新，多数情况下不用动手；重启一下 IDE 就会触发更新；如果你的网络策略挡住了自动更新，就把 Amazon Q 插件升级到最新版。想查证可以搜 AWS 安全公告 Security Bulletin 2026-047-AWS。
第二步：翻一翻你的项目。 在最近 clone 过的仓库里搜一下有没有 `.amazonq/mcp.json` 这个文件。如果有、又不是你自己加的——尤其它出现在一个陌生仓库里——要高度警惕，这正是这个漏洞的攻击载体。修复之后，Amazon Q 再遇到工作区里的 MCP 服务器，会先弹出"Untrusted MCP Server"的确认提示Wiz官方博客。长这样：
看到这个弹窗，先把里面的 command 看清楚再决定 Allow 还是 Deny，陌生仓库来的配置，默认拒绝。
第三步：给凭证做减法。 这个漏洞能偷到东西，前提是凭证就摆在环境变量里。趁机做一次清理：别把长期有效的 AWS Access Key 放进全局环境变量，能走 SSO 或短期凭证就尽量走，实在要留也把权限范围压到最小。凭证不在明面上，就算配置被加载，损失也有限。
第四步：改一个习惯。 以后 clone 陌生项目，别第一时间就激活全套 AI 助手。VS Code 本身有 workspace trust 机制，遇到要跑敏感内容的场景，用容器或虚拟机隔离最稳。安全圈博主们的建议总结起来就三句：关掉自动批准、别随便 clone 陌生项目、敏感开发用 Docker 隔离微博。
那它到底还值不值得用
我的判断是：免费额度依然值得用，但前提是你完成了上面四步。
每月 50 次安全扫描和免费补全，在白嫖向的 AI 编程工具里仍然能打，而且这次的修复动作不算慢——4 月发现、5 月修复、负责任披露，AWS 的响应在同类事件里算体面的Wiz官方博客。但这个漏洞是个分水岭：AI 编程助手的安全边界，正在从"你写的代码"转移到"你打开的东西"。过去帮你查代码漏洞的工具，自己也可能变成攻击面——而且这不只是 Amazon Q 一家的问题，Cursor、Copilot、Claude Code 这些支持 MCP 和插件的 AI IDE 都在同一道题面前。
后续值得盯三个信号：
AWS 安全公告的后续更新，以及 1.65.0 之前的旧版本还有多少存量；
其他 AI IDE 会不会陆续曝出同类"自动加载配置"问题；
OWASP MCP Top 10 的更新——这是目前对 AI 插件生态风险最系统的清单。
不用恐慌，但要自查。查完欢迎在评论区报个结果，也算给还在观望的值友提个醒。
