Amazon Q Developer Flaw Could Let Malicious Repos Run Code via MCP Configs

Swati KhandelwalJun 26, 2026AI Security / Vulnerability

A high-severity flaw in Amazon Q Developer let a malicious repository run commands and steal a developer’s cloud credentials. The path was short: a developer opens the repo, trusts the workspace, and Amazon Q does the rest. Amazon has patched it.

Tracked as CVE-2026-12957 (CVSS 8.5), the bug sat in how Amazon’s AI coding assistant handled Model Context Protocol (MCP) servers.

Wiz Research, which found and reported it, showed that a single config file dropped in a repo was enough to go from git clone to cloud compromise.

How the attack worked

Amazon Q read an MCP configuration file, .amazonq/mcp.json, from the open workspace and launched the servers it defined. MCP servers are local processes that an AI assistant can spawn to reach databases, APIs, or build tools, so starting one means running commands on the machine.

Those processes inherited the developer’s full environment. That usually means AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets.

Put the two together, and a file sitting in a cloned repo could run arbitrary code with the developer’s live cloud session attached. No password, no second sign-in.

In its proof of concept, Wiz had the file run aws sts get-caller-identity and ship the output to an attacker server, capturing the active AWS session. What comes next depends on that developer’s cloud permissions: backdoor an IAM user for persistence, reach internal services, or pivot toward production.

AWS and Wiz frame the consent step differently. Amazon’s advisory says the user has to trust the workspace when prompted, and CVSS rates the user interaction as passive.

Wiz reported there was no separate consent step for the MCP servers themselves before the fix. The patch closes that gap: Amazon Q now flags an untrusted MCP server and lets the developer reject the command before it runs.