AI coding assistants now execute your repos, not just your code
AI coding assistant security now hinges on a dangerous assumption: that configuration files inside a project are trustworthy, even when they come from unvetted git repositories, because many assistants will read these configs, spawn local tools via protocols like MCP, and execute commands on the developer’s machine with their real environment and credentials attached.
The Amazon Q Developer flaw tracked as CVE-2026-12957 makes this painfully clear: a single booby-trapped repository could execute arbitrary commands and steal a developer’s cloud credentials by abusing Model Context Protocol (MCP) server configuration handling. This is malicious code execution hiding in plain sight, smuggled through what looks like a harmless helper file. The issue did not live in your code; it lived in the AI assistant’s habit of automatically turning project configuration into running processes, without asking whether the project should be trusted. That is a supply chain problem, not a one-off bug.
From git clone to AWS credential theft in one workflow
The attack chain behind CVE-2026-12957 is frighteningly short: malicious repo → MCP config → code execution → credential exposure, all inside a normal developer workflow. Amazon Q Developer would scan the workspace for .amazonq/mcp.json, automatically load it, and launch every MCP server defined there when the assistant was activated. Those MCP servers are not abstract: they are local processes, started with whatever command the config specifies, and they inherit the developer’s full environment—AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets.
Wiz’s proof of concept had the malicious configuration run aws sts get-caller-identity and exfiltrate the output to an attacker-controlled server, capturing the active AWS session. Once you have that, AWS credential theft stops being theoretical. The attacker can use the developer’s existing permissions to backdoor IAM identities, reach internal services, or pivot toward production systems. “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,” the researchers noted.
This is an MCP configuration vulnerability—and an industry habit
Technically, CVE-2026-12957 is an MCP configuration vulnerability: Amazon Q read .amazonq/mcp.json from the workspace and launched every server it declared, with no extra consent or trust check. The security model assumed developers would explicitly configure these servers and understand they were granting permission to run arbitrary commands locally. The bug arose when that assumption collided with automation: Amazon Q auto-loaded MCP configs from the project folder—no prompt, no informed consent, and initially no separate approval for those processes to start.
Blaming Amazon alone misses the point. Researchers have already reported similar AI coding assistant security failures elsewhere: Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) both turned project-level MCP configuration into command execution, and Windsurf (CVE-2026-30615) reached the same outcome by rewriting local MCP configs with attacker-controlled content. More assistants are adopting MCP to reach databases, APIs, and build tools, which means more tools are now willing to execute commands from hidden project files. Repo-carried configuration is untrusted input; turning it into running processes without an explicit yes is an industry-wide anti-pattern.
Who was exposed, how it was fixed, and why this isn’t over
The flaw lived in Language Servers for AWS, the runtime that powers Amazon Q’s integrations for VS Code, JetBrains IDEs, Eclipse, and Visual Studio; all four plugin families bundled the vulnerable language server, so all four were exposed while they shipped older copies. CVE-2026-12957 carries a CVSS 4.0 score of 8.5, reflecting high-severity malicious code execution and AWS credential theft risk. Wiz reported the issue on April 20 and Amazon shipped a fix on May 12, later publishing details in late June. There is no known public exploitation; CISA’s entry for CVE-2026-12957 lists exploitation as none so far.
Amazon fixed the bug in Language Servers for AWS version 1.65.0, and now recommends upgrading to 1.69.0 for additional hardening. Patched plugin minimums are VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, and Visual Studio toolkit 1.94.0.0 or later. Existing installations should receive the patched language server automatically unless automatic updates are blocked. The patch adds checks for untrusted MCP servers so developers can reject commands before they run. That is progress, but not a cure: as long as AI tools auto-wire themselves to project configs, any missed trust boundary will turn git repositories into attack surfaces.
Turn your AI assistant into a read-only helper, not a silent operator
Developers cannot treat AI coding assistants as harmless autocomplete anymore. They are automation hubs with shell access. The safest stance is to treat every project-level MCP configuration as hostile until proven otherwise. That means inspecting files like .amazonq/mcp.json before trusting a workspace, and pushing vendors to make “ask before running anything” the default. The convenience of letting a project folder configure an AI agent is the same pathway attackers now use; repo-carried config must never silently become live processes.
In practice, lock assistants down to read-only where possible: allow them to read code, propose changes, and draft commands, but require explicit human approval before anything executes. Disable or tightly scope MCP servers to tools you control, and keep automatic updates enabled so language servers reach at least the patched versions for CVE-2026-12957. The long-term fix is cultural as much as technical: stop treating git repositories as extensions of your local machine’s trust and start treating them as input from strangers. If your AI helper runs what they suggest without asking you, it is not assisting you—it is speaking for you.
