Open The Folder, Lose Your AWS Keys. Amazon Q Auto-Ran Whatever a Repo Told It To. CVE-2026-12957.
- Patrick Duggan
- 4 minutes ago
- 4 min read
The promise of an AI coding assistant is that it does things for you. The danger of an AI coding assistant is that it does things for you. CVE-2026-12957 is what happens when the second sentence wins and nobody put a gate between them.
The Mechanism, Stripped Down
Amazon Q Developer, the AI assistant that plugs into IDEs, supports the Model Context Protocol — the standard that lets an assistant spawn helper processes to reach databases, APIs, and build tools. You point it at an MCP server, the assistant launches that server as a local process, and now the model can use it. Powerful, and increasingly standard across the whole agentic-AI ecosystem.
The flaw was in where Amazon Q looked for those server definitions and how much it trusted them. The extension automatically read a file inside the project workspace — .amazonq/mcp.json — and executed the commands that file specified, the moment a developer opened the folder and activated Amazon Q. No prompt. No consent dialog. No workspace-trust check of the kind every modern editor learned to ship years ago. If the file was there, the commands ran.
Why A Config File Becomes Credential Theft
Here is the part that turns an annoyance into an 8.5. MCP servers are local processes, and local processes inherit the environment of whatever launched them. A developer's shell environment is not empty — it is the most privileged real estate on the machine. It holds AWS access keys, cloud CLI session tokens, API secrets for whatever the team integrates with, and a live SSH agent socket. When Amazon Q auto-spawned a server defined by an untrusted repository, that attacker-authored command ran inside the developer's own credential context.
Wiz Research built the proof of concept and kept it deliberately mundane: a repository containing a malicious MCP configuration. Open the project, activate Amazon Q, and the extension executed a command that reached out to AWS using the developer's existing credentials. No exploit chain, no memory corruption, no second stage. The entire attack is "clone an interesting-looking repo and open it," which is a thing developers do dozens of times a week without a second thought.
This Is The Supply-Chain Pattern Wearing A New Hat
We have spent this whole year writing about install-time and build-time execution in the software supply chain — the Nx compromise, the Shai-Hulud worm variants, malicious npm and PyPI packages that run code during install rather than at runtime. CVE-2026-12957 is the same disease in a new organ. The execution trigger moved from "npm install" to "open the folder in an AI-assisted IDE." The malicious payload moved from a postinstall script to a JSON config the assistant reads automatically. The victim is the same: a developer whose machine is a skeleton key to the company's cloud.
The lesson generalizes past Amazon specifically. Every AI coding assistant that auto-discovers configuration from the working directory has this shape of risk. The protocol is not the problem — the Model Context Protocol is a transport, and a good one. The problem is auto-executing a transport's instructions from an untrusted source without a trust boundary in front of it. Convenience without consent is just remote code execution with better marketing.
The Fix, And The Primitive Underneath It
Amazon fixed it in version 1.65.0 of the language server that powers Amazon Q's IDE integrations. The corrected behavior is exactly what was missing: Amazon Q now flags an untrusted MCP server and lets the developer reject the command before it runs. Update to 1.65.0 or later. If you use Amazon Q across a team, treat the extension version as a fleet-management item, not an each-developer-eventually thing — and audit whether any repository you have opened recently shipped an .amazonq/mcp.json you did not write.
Where we sit on this one is closer to home than most, and we have history here. Back in November 2025 our own edge auto-blocker flagged traffic whose ISP claimed to be "Anthropic, PBC" — and it traced back to AWS infrastructure, not Anthropic. We wrote it up at the time, called it what it was, and did not soften it because it was inconvenient: AWS weaponizing Anthropic's name. That is a different incident from this CVE, and we are not pretending otherwise. But it means we come to an Amazon AI-assistant story with a track record of saying the quiet part out loud about how AWS handles the Claude relationship. We use AWS as an instrument. Anthropic is the partnership. We hold both to the same standard and we have proven we will.
Butterbot's whole architecture is connective — it uses many models and many MCP tools as instruments. So the trust boundary in front of an MCP server is not an abstract concern for us; it is a thing we build. Our own deployment gate judges MCP server invocations before they run — checking the server's identity and its dependency graph for supply-chain risk — precisely because "the assistant launched a helper process" is the exact moment where an attacker wants to be standing. The Amazon Q bug is a clean illustration of the failure mode that gate exists to prevent: the difference between an assistant that asks and an assistant that just acts. We are not going to claim we predicted this specific CVE. We will claim, flatly, that auto-executing untrusted MCP configs was always going to produce a CVE like this, and that the answer is the same every time — trust before execution, consent before action, a gate in front of the process spawn.
Patch to 1.65.0, then look in your last few cloned repositories for a config file you never put there.
Sources: Wiz Blog (Amazon Q vulnerability research); The Hacker News; The Register; SecurityWeek; CyberSecurityNews; SC Media. CVE-2026-12957, CVSS 8.5; fixed in Amazon Q language server 1.65.0.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.