AI Coding Assistants’ New Weak Spot: Untrusted Project Configs
AI coding assistant security now includes the risk that configuration files inside a project can cause these tools to execute untrusted commands, expose developer credentials, and open a powerful supply chain attack vector across malicious Git repositories. Amazon Q Developer’s recent CVE-2026-12957 should be treated as a warning shot, not an isolated bug.
The flaw was simple but devastating: a high-severity bug in Amazon Q Developer let a malicious repository run commands and steal a developer's cloud credentials. The problem sat in how the assistant handled Model Context Protocol (MCP) servers, which allow AI tools to launch local processes to reach databases, APIs, or build tools. In other words, the very mechanism that makes these assistants powerful became a direct path from opening a project to handing over the keys to your cloud.
This is not a hypothetical threat. The vulnerability was tracked as CVE-2026-12957 with a CVSS score of 8.5, underscoring how serious the impact can be when cloud-connected development environments start obediently executing whatever their AI sidekick is told.
From Git Clone to Cloud Compromise in One Hidden File
Here is the uncomfortable truth: opening the wrong Git repository in your IDE can now be enough to compromise your environment when an AI assistant is wired in. In the Amazon Q case, the assistant automatically read an MCP configuration file, .amazonq/mcp.json, from the workspace and launched the servers it defined. Those servers are local processes, so launching them means running commands on the machine.
Because these processes inherited the developer's full environment, they gained access to AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets. Put bluntly, a file sitting in a cloned repo could run arbitrary code with the developer's live cloud session attached. Wiz Research showed that a single config file dropped in a repo was enough to go from git clone to cloud compromise. They 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.
In their 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. What happens next depends on the victim’s cloud permissions, but the path from source control to AWS credential theft is now painfully clear.
A Pattern Across AI Coding Tools, Not an Amazon One-Off
Blaming this on a single product misses the real lesson. 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 configuration that led to command execution, while Windsurf (CVE-2026-30615) reached the same outcome through attacker-controlled content rewriting local MCP config to register a malicious server. 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.
The convenience of letting a project folder configure an AI agent is also the attack surface: repo-carried config is untrusted input, and turning it into a running process should take an explicit yes. "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 wrote. According to one research team, attackers have now found a new place to lurk: the hidden files that developers rarely think twice about trusting.
This is what a modern supply chain attack vector looks like: no dependency confusion, no poisoned package index, just a booby-trapped workspace configuration that your AI assistant dutifully obeys.
Patch Status: What Amazon Fixed—and What You Still Need to Do
The immediate Amazon Q issue has been patched, but that does not mean your environment is safe by default. 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 bundled it, so all four were exposed by versions that shipped an older copy. The bug, tracked as CVE-2026-12957, carries a CVSS 8.5 rating, yet there is no known public exploitation; CISA’s ADP entry for the CVE lists exploitation as none.
Amazon has patched it, fixing CVE-2026-12957 in Language Servers for AWS 1.65.0 and advising customers to move to 1.69.0. Existing installations should receive the patched component automatically unless automatic updates have been blocked. The patched plugin minimums are clear: VS Code 2.20 or later, JetBrains 4.3 or later, Eclipse 2.7.4 or later, and the Visual Studio toolkit 1.94.0.0 or later. Wiz found the flaw through research, reported it on April 20, and Amazon shipped a fix on May 12, ahead of the June 26 public write-up.
The patch also adds a missing consent layer: Amazon Q now flags an untrusted MCP server and lets the developer reject the command before it runs, closing the gap where configuration silently turned into execution.
The Bigger Lesson: Treat AI Assistants Like Powerful Shells
The most important takeaway for developers is mindset: AI coding assistants are not harmless autocomplete; they are powerful shells that can run commands with your full privileges. That means every hidden configuration file they read is a potential attack script. The convenience of project-level MCP configuration has created a new supply chain attack vector where a single config file dropped in a repo can bridge the gap from source control to cloud compromise.
This incident also exposes a broader security gap in how AI tools handle untrusted configuration data. Repo-carried config is untrusted input, but too many tools still treat it as a trusted extension of local settings, rather than something that must be gated behind informed consent. It suggests attackers will continue to probe those hidden files that developers rarely question.
The path forward is not abandoning AI coding assistants; it is demanding that they earn their permissions. If a tool can spawn processes and inherit your AWS session, any configuration that controls it must be treated as executable code. Until vendors make that the default, security-conscious developers need to assume every cloned repo is hostile until proven otherwise.
