Amazon Q auto-ran booby-trapped.amazonq/mcp.json, executing AWS commands with 8.5 CVSS

If a developer opens the wrong Git repo and turns on Amazon Q, the repo’s hidden file can decide what the AI runs. Wiz reports that Amazon Q automatically loads a workspace MCP configuration from.amazonq/mcp.json and executes the commands it contains, without a prompt, consent, or workspace trust check. In other words, the “AI coding assistant” can become a delivery mechanism for attacker-controlled execution, starting the moment a folder is opened.

The flaw is tracked as CVE-2026-12957 and carries a CVSS 4.0 score of 8.5, a severity level that matters for any company with developer tooling, cloud keys, and a standard “just open the repo” workflow. The core risk: MCP lets AI assistants launch local processes, and in Amazon Q’s case those processes inherit the developer’s environment, including AWS credentials, API keys, authentication tokens, SSH agent sockets, and other secrets already loaded into the session. Wiz’s demonstration is blunt: a malicious MCP configuration executed a command against AWS using the developer’s existing credentials after the developer activated Amazon Q.

To understand why this went wrong, zoom in on the security model the researchers say Amazon Q depended on. The researchers describe an assumption that the user explicitly configures MCP servers. That model effectively says, “You are granting an AI assistant permission to run arbitrary commands on your machine.” If that permission comes only after informed, explicit setup, then the system can treat the commands as trusted. Wiz argues the vulnerability came from violating that assumption: Amazon Q automatically loaded MCP configurations from.amazonq/mcp.json within the workspace. No workspace trust check. No prompt. No consent.

This is the part executives should not miss: the attacker does not need the developer to click a link, accept a warning, or run a tool. The attack can be triggered by routine behavior: cloning or opening a repository, then activating the assistant in the IDE. The combo of “no prompt” plus “inherited environment” is what turns a “configuration file” into a credential theft shortcut. Wiz describes it as a single malicious config file executing arbitrary commands with full access to the developer’s credentials, no user interaction required beyond opening the folder and activating Amazon Q.

Amazon fixed the issue in language server version 1.65.0, which powers Amazon Q’s IDE integrations. Existing installations should receive the patched component automatically unless automatic updates are blocked. In an advisory, Amazon said: “We would like to thank Wiz for collaborating with us on this issue. We have remediated this issue in language server version 1.65.0,” and, per The Register, Amazon did not respond to The Register’s questions.

Now for the broader industry implication, which Wiz frames as less of a one-company mistake and more of a pattern problem. As more AI coding assistants adopt MCP to connect models to local tools and services, they increasingly gain the ability to execute commands on developers’ machines. And once assistants can execute local processes, the “trust boundary” becomes dangerously porous. Researchers say similar workspace configuration flaws have recently surfaced in other AI coding tools. The hidden files developers rarely think twice about trusting are becoming a new place to lurk.

For decision-makers, this is not just an incident response item. It is a governance and platform risk question: what does it mean to “trust a repo” when the software you are running is an AI assistant that can interpret configuration embedded in the workspace? Boards and security teams should assume that developer productivity tooling will keep expanding its permissions because MCP-based workflows are compelling. The catch is that permission must be paired with enforceable consent and robust workspace trust controls. Without that, the second-order effect is predictable: a supply chain attack can jump from code to execution, and from execution to secrets, through developer environments that were never designed to treat configuration files like high-risk actions.