AI Coding Assistants: From Helper to Hidden Attack Surface
AI coding assistant security describes how tools like Amazon Q, which run code and connect to local resources on behalf of developers, can be abused as attack vectors when they execute untrusted configuration files from projects, exposing cloud credentials and development machines to compromise if safeguards and explicit consent checks are missing.
The uncomfortable takeaway is that AI coding assistants are now part of the supply chain attack surface, not just productivity boosters. The Amazon Q vulnerability tracked as CVE-2026-12957 shows how thin the boundary can be between “smart helper” and “remote shell with your AWS keys attached”. A high-severity flaw in Amazon Q Developer let a malicious repository run commands and steal a developer’s cloud credentials. In other words, opening the wrong Git repo was enough to put your cloud in play. Treating these assistants as benign IDE features is no longer defensible; they must be threat-modeled like any other code execution engine wired into your environment.
How MCP Config Exploitation Turns Repos into Credential Traps
The core Amazon Q vulnerability is brutally simple: the assistant trusted configuration shipped inside the project more than it trusted the developer. Amazon Q read an MCP configuration file, .amazonq/mcp.json, from the open workspace and launched the servers it defined. 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.
MCP servers are local processes that an AI assistant can spawn to reach databases, APIs, or build tools, which means starting one is equivalent to running commands on the machine. The processes inherited the developer’s environment, including AWS credentials, API keys, authentication tokens, and SSH agent sockets already loaded into the session. Put together, a single malicious config file could execute arbitrary commands with full access to the developer’s credentials, no extra prompt, consent, or workspace trust check beyond opening the folder. The security assumption that only the user defines MCP servers collapsed the moment repo-carried config started them automatically.
From Git Clone to AWS Credential Theft and Cloud Compromise
If this sounds like a supply chain attack waiting to happen, that’s because it is. Wiz Research showed that a single config file dropped in a repo was enough to go from git clone to cloud compromise. Opening the project and activating Amazon Q caused the extension to execute a command against AWS using the developer’s existing credentials. In its proof of concept, the malicious file ran aws sts get-caller-identity and shipped the output to an attacker server, capturing the active AWS session.
Those stolen sessions are not abstract risks. The processes spun up by Amazon Q inherited AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets from the developer’s environment. Once an attacker has that, what comes next depends on the developer’s permissions: backdooring IAM users, poking at internal services, or pivoting toward production systems. It suggests attackers have found a new place to lurk: the hidden files that developers rarely think twice about trusting. Supply chain attacks used to live mostly in dependencies and build scripts; now, AI assistant config files belong on the same threat list.
Amazon Q’s Fix and the Wider AI Assistant Pattern
The good news is that this specific Amazon Q vulnerability is fixed. Tracked as CVE-2026-12957 with a CVSS 8.5 score, it lived in the Language Servers for AWS, the runtime that powers Amazon Q across VS Code, JetBrains, Eclipse, and Visual Studio. Amazon fixed the bug in version 1.65.0 of its language server, which powers Amazon Q’s IDE integrations, and their bulletin tells customers to move to 1.69.0. The patched plugin minimums are VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, and Visual Studio toolkit 1.94.0.0. Wiz reported the flaw on April 20 and saw a fix on May 12, ahead of the June 26 public write-up. There is no known public exploitation; CISA’s ADP entry lists it as none.
Calling this “an Amazon problem” misses the point. 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 via attacker-controlled content rewriting the local MCP config. Researchers note that similar workspace configuration flaws have recently surfaced in other AI coding tools. As more assistants adopt MCP to connect models to local tools and services, allowing them to execute commands on developers’ machines, we’re watching a pattern emerge: repo-carried config is untrusted input, yet too many assistants treat it as policy. That’s a design mistake, not an implementation bug.
Opinion: Treat AI Coding Assistants as Untrusted Code Runners
The Amazon Q vulnerability should end any illusion that AI coding assistants are harmless autocomplete features. They are programmable agents with the ability to run commands in rich environments loaded with secrets. The convenience of letting a project folder configure an AI agent is also the attack surface. Turning repo settings into running processes without explicit, contextual consent is unsafe by design. “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.”
Developers and security teams should treat any AI coding assistant capable of executing commands as part of their attack surface. Repo-carried config is untrusted input and must never silently cross the line into execution. If your assistant can start MCP servers, assume attackers will try to plant malicious configs in Git repos and hidden project files because, as the research shows, a single file can be enough to bridge from workstation to cloud. AI tooling has earned a place in modern development, but it also needs a place in threat models, review checklists, and security budgets. Otherwise, the next “helper” will be the one that ships your AWS credentials to an attacker before you finish your morning coffee.
