Amazon Q security flaw let malicious Git repos execute code and steal AWS credentials via MCP

Amazon Q flaw let booby-trapped Git repos execute code, swipe cloud creds

Researchers warn many AI coding assistants now execute commands from project configurations A high-severity flaw in Amazon's AI coding assistant for Visual Studio Code meant that opening the wrong Git repository could allow an attacker to execute code on a developer's machine and potentially hand them the keys to the dev's cloud environment. The bug, tracked as CVE-2026-12957 and assigned a CVSS 4.0 score of 8.5, centers on how Amazon Q handled Model Context Protocol (MCP) server configurations. Wiz found the extension would automatically load a repository's .amazonq/mcp.json file and execute the commands it contained when a developer opened the project and activated Amazon Q. "The security model assumes the user explicitly configures these servers. After all, you're granting an AI assistant permission to run arbitrary commands on your machine. This should require informed consent," the researchers write. "The vulnerability arose when this assumption was violated: Amazon Q automatically loaded MCP configurations from .amazonq/mcp.json within the workspace - no prompt, no consent, no workspace trust check." MCP lets AI assistants launch local processes to carry out tasks. In Amazon Q's case, those processes inherited the developer's environment, giving them access to AWS credentials, API keys, authentication tokens, SSH agent sockets, and other secrets already loaded into the session. "The combination meant that a single malicious config file could execute arbitrary commands with full access to the developer's credentials - no user interaction required beyond opening the folder and activating Amazon Q," Wiz said. To prove the attack worked, Wiz built a repository with a malicious MCP configuration. Opening the project and activating Amazon Q caused the extension to execute a command against AWS using the developer's existing credentials. Amazon fixed the bug in version 1.65.0 of its language server, which powers Amazon Q's IDE integrations. Existing installations should receive the patched component automatically unless you've blocked automatic updates. "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," Amazon said in an advisory, though it didn't respond to The Register's questions. Wiz argues the bug is less an Amazon problem than an industry one. More and more AI coding assistants are adopting MCP to connect models to local tools and services, allowing them to execute commands on developers' machines. According to the researchers, similar workspace configuration flaws have recently surfaced in other AI coding tools. It suggests attackers have found a new place to lurk: the hidden files that developers rarely think twice about trusting. ®

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

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. The flaw lives in Language Servers for AWS, the runtime that powers Amazon Q across VS Code, JetBrains, Eclipse, and Visual Studio. All four plugins bundle it, so all four were exposed by versions that shipped an older copy. What to do Update. CVE-2026-12957 is fixed in Language Servers for AWS 1.65.0, but AWS's bulletin tells customers to move to 1.69.0. That build also closes a second issue, CVE-2026-12958, a missing symlink check that could allow arbitrary file writes outside the workspace trust boundary. The patched plugin minimums: * VS Code: 2.20 or later * JetBrains: 4.3 or later * Eclipse: 2.7.4 or later * Visual Studio toolkit: 1.94.0.0 or later The language server auto-updates unless the network blocks it, and reloading the IDE pulls the latest build. There is no known public exploitation; CISA's ADP entry for CVE-2026-12957 lists it as none. Wiz found the flaw through research and disclosed it in coordination with Amazon, reporting it on April 20 and seeing a fix on May 12, ahead of the June 26 public write-up. A pattern, not a one-off Amazon Q is not the first coding assistant to trip over MCP trust. The bugs are not identical, but they rhyme: project configuration turns into executable behavior, and the trust checks around that handoff keep failing. Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) both had project-level MCP config that led to command execution. Windsurf (CVE-2026-30615) reached the same end by a different path, with attacker-controlled content rewriting the local MCP config to register a malicious server. The convenience of letting a project folder configure an AI agent is also the attack surface. Repo-carried config is untrusted input. Turning it into a running process should take an explicit yes.

Amazon Q Developer flaw let malicious repos steal AWS credentials via rogue MCP servers

A flaw in Amazon Q Developer auto-loaded rogue MCP servers from cloned repos, letting attackers steal AWS credentials silently. A high-severity flaw in Amazon Q Developer allowed a malicious code repository to silently execute commands on a developer's machine and steal their AWS credentials. Wiz Research discovered the vulnerability, tracked as CVE-2026-12957, and reported it to Amazon on April 20. Amazon patched the issue on May 12, and the disclosure went public today. The attack exploited how Amazon Q Developer handles MCP servers, a protocol that lets AI coding assistants connect to external tools and data sources. A configuration file placed inside a repository would automatically register and start an attacker-controlled MCP server the moment a developer cloned the project, with no prompt or consent step. That server inherited the developer's full AWS credentials, IAM role, and any other environment variables available to the IDE plugin. Wiz researchers demonstrated the attack by building a proof of concept that ran a standard AWS identity command through the malicious MCP server and sent the output to an external server. The command returns the developer's AWS account ID, user ARN, and session credentials, everything an attacker needs to access cloud resources. Because the MCP server launched automatically when the repository opened, the attack required no interaction beyond cloning the code, a pattern that has already enabled supply chain compromises in other AI coding tools. Amazon fixed the vulnerability by requiring explicit user approval before any MCP server can start, and by restricting the environment variables that MCP servers can access. A second flaw found in the same audit, CVE-2026-12958, revealed that the plugin failed to check for symbolic links when writing workspace files, allowing an attacker to write arbitrary files anywhere on the developer's system. Amazon patched both issues in updated versions of Language Servers for AWS and the corresponding IDE plugins for VS Code, JetBrains, Eclipse, and Visual Studio. The disclosure adds Amazon Q Developer to a growing list of AI coding tools found vulnerable to supply chain attacks that exploit the trust these tools place in repository contents. Anthropic's Claude Code was found vulnerable to a similar credential-theft attack through prompt injection in GitHub Actions earlier this year. Cursor and Codeium's Windsurf have also disclosed MCP-related vulnerabilities in recent months. The underlying problem is that MCP, by design, gives AI assistants the ability to call external tools with whatever permissions the host application holds. When a repository can silently register an MCP server that inherits a developer's cloud credentials, the attack surface expands from the code itself to every service the developer can access. Amazon says there is no evidence the flaw was exploited in the wild, and CISA's advisory database lists no known attacks. Developers using Amazon Q Developer should update their IDE plugins to the latest available versions immediately and audit any repositories they have recently cloned for unexpected configuration files. The broader lesson is the same one that keeps repeating across AI developer tooling: any configuration file that can trigger code execution at clone time is a weapon, and the tools that auto-execute it are the ones holding the safety off.