AI coding assistants now run your configs—and attackers know it
AI coding assistant security refers to the risks that arise when tools like Amazon Q automatically execute project configuration files, allowing malicious repositories to trigger code execution and steal cloud credentials without explicit user consent. In CVE-2026-12957, a high-severity flaw in Amazon Q Developer let a malicious repository run commands and steal a developer's cloud credentials. Put the two together, and a file sitting in a cloned repo could run arbitrary code with the developer's live cloud session attached. This is not a theoretical edge case; it is a design pattern that turns convenience into a code execution vulnerability, and it is spreading across modern AI coding assistants.
In plain terms: opening the wrong Git repository while your AI helper is enabled can be enough to hand attackers both a shell and your cloud keys. 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. That is a malicious repository attack baked into everyday workflows, and treating it as a one-off bug misses the real problem.
How CVE-2026-12957 turned a config file into a cloud breach
CVE-2026-12957 is a CVSS 8.5 code execution vulnerability in Amazon Q’s handling of Model Context Protocol (MCP) configurations. 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 start to reach databases, APIs, or build tools; starting one means running commands on the machine.
Here is the dangerous part: those processes inherited the developer's full environment, including AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets. 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 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.
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. From there, the attacker can do whatever that identity allows: backdoor an IAM user, reach internal services, or move toward production. If you think of MCP configs as data, this bug proves they are code with teeth.
This is bigger than Amazon Q: AI tooling is auto-running untrusted configs
It is tempting to frame CVE-2026-12957 as an Amazon mishap, but that misses the pattern. Wiz argues the bug is less an Amazon problem than an industry one, as more AI coding assistants adopt MCP to connect models to local tools and services, allowing them to execute commands on developers' machines. Amazon Q is not the first coding assistant to trip over MCP trust. Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) both had project-level MCP config that led to command execution, while Windsurf (CVE-2026-30615) reached the same end by rewriting local MCP config to register a malicious server.
The core mistake is architectural: project configuration turns into executable behavior, and the trust checks around that handoff keep failing. Repo-carried config is untrusted input. Turning it into a running process should take an explicit yes. Instead, we now have AI assistants where opening a workspace means silently spawning processes that inherit AWS credential theft opportunities from the environment. A high-severity flaw in Amazon Q Developer let a malicious repository run commands and steal a developer's cloud credentials, and similar patterns are surfacing elsewhere. Attackers have found a new place to lurk: the hidden files developers rarely think twice about trusting.
If your workflow involves AI assistants and random GitHub repos, you should assume that any .amazonq/mcp.json or similar file could be as dangerous as a shell script.
Who was exposed, what was fixed, and why your risk isn’t gone
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. 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. Amazon fixed the bug in version 1.65.0 of its language server, which powers Amazon Q's IDE integrations. The patched plugin minimums are VS Code 2.20 or later, JetBrains 4.3 or later, Eclipse 2.7.4 or later, and Visual Studio toolkit 1.94.0.0 or later.
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. The language server auto-updates unless the network blocks it, and reloading the IDE pulls the latest build. But do not mistake "no known exploitation" for safety. Developers using these tools risk credential theft and unauthorized code execution when working with untrusted or compromised repositories, and the broader architectural risk persists across similar AI-assisted development tools.
The uncomfortable truth: we patched one manifestation of a design flaw, not the design flaw itself.
Practical steps: treat AI assistants like privileged shells, not friendly bots
If AI coding assistants can execute commands and reach your cloud, they deserve the same paranoia as a root shell. First, update now: 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. Ensure your IDE plugins meet at least these versions: VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, Visual Studio toolkit 1.94.0.0. Reload your IDE to pull the latest language server, especially if your network blocks auto-updates.
Second, change how you treat untrusted repos. 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. Do not activate AI assistants by default on unfamiliar projects. Inspect hidden config directories (.amazonq, .cursor, etc.) before trusting a workspace. Disable or restrict MCP-like features in high-privilege environments, and avoid loading long-lived AWS credentials into your dev sessions if you can rely on scoped, short-lived tokens instead.
Finally, as an industry, we should stop normalizing silent auto-execution of repo configs. The convenience of letting a project folder configure an AI agent is also the attack surface. If an assistant wants to run commands, it should have to ask—and you should treat that prompt as if a stranger just requested sudo.
