AI coding assistants now execute your supply chain
AI coding assistant vulnerability in modern IDE plugins refers to the risk that tools like Amazon Q automatically execute project-level configuration files, allowing malicious repository code execution that can run arbitrary commands and steal AWS credentials without clear, explicit user consent when a developer opens a booby-trapped workspace.
The Amazon Q Developer flaw, CVE-2026-12957, is the most recent and clearest warning shot. A single hidden configuration file, .amazonq/mcp.json, in a Git repo was enough to go from "git clone" to live AWS credential theft. When a developer opened the folder and activated Q, the assistant spun up Model Context Protocol (MCP) servers defined by that file and ran their commands automatically. Those processes inherited the full environment: AWS keys, cloud CLI tokens, API secrets, and SSH agent sockets. In other words, the AI helper became an attack proxy wired directly into your cloud session. If you treat these tools as harmless autocomplete, you are already behind; they are closer to remote administration agents with a UX gloss.
How malicious MCP configs became code execution on your laptop
The core problem was silent trust. Amazon Q read .amazonq/mcp.json from the workspace, launched the MCP servers it defined, and ran their commands without a dedicated consent step. According to one research team, "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." That turned repo-carried config into a remote shell. Wiz proved this in a proof-of-concept by running aws sts get-caller-identity and exfiltrating the result to an attacker server, capturing the active AWS session.
This is not a theoretical glitch. A high-severity flaw in Amazon Q Developer let a malicious repository run commands and steal a developer’s cloud credentials. 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. Combine that with inherited secrets and you have a full-blown supply chain security risk: a file sitting in a cloned repo could run arbitrary code with the developer's live cloud session attached. You no longer need to trick a developer into running a script; you only need them to trust a workspace while their AI assistant is enabled.
This is an industry pattern, not an Amazon-only bug
It is tempting to file CVE-2026-12957 as an Amazon mishap and move on. That would be a mistake. Researchers argue this is less an Amazon problem than an industry pattern. 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. Every time a project config file turns into a running process, you open a new attack surface. Repo-carried config is untrusted input; treating it as gospel is how supply chain attacks begin.
We already have proof this pattern repeats. Claude Code (CVE-2025-59536) and Cursor (CVE-2025-54136) both had project-level MCP config that led to command execution, and Windsurf (CVE-2026-30615) reached the same outcome by letting attacker-controlled content rewrite the local MCP config to register a malicious server. The bugs are not identical, but they rhyme: project configuration turns into executable behavior, and the trust checks around that handoff keep failing. Attackers have found a new place to lurk: the hidden files that developers rarely think twice about trusting. If your AI assistant reads config from the workspace and can run commands, assume this class of bug is possible until proven otherwise.
What developers should do now to stay ahead
The Amazon Q issue is patched, but the risk model it exposes is very much alive. CVE-2026-12957 is fixed in Language Servers for AWS 1.65.0, and Amazon’s bulletin tells customers to move to 1.69.0, which also closes a related symlink issue, CVE-2026-12958. The language server auto-updates unless the network blocks it, and reloading the IDE pulls the latest build. On the client side, the patched plugin minimums are clear: 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. Amazon has patched it, and there is no known public exploitation; CISA’s ADP entry for CVE-2026-12957 lists exploitation as none.
- Treat AI assistants like remote shells, not autocomplete. Assume any MCP config could be an MCP config exploit and review .amazonq/mcp.json or equivalents before trusting a workspace.
- Lock down credentials on dev machines. Minimize long-lived AWS keys and tokens in your environment; prefer short-lived sessions and least-privilege roles so stolen sessions limit blast radius.
- Control auto-update and monitoring. Ensure your network is not blocking language server updates, and inventory which teams and IDE versions can run MCP servers.
- Add repo hygiene checks. Extend pre-commit hooks, scanners, or code review templates to flag new AI config files and hidden directories introduced by dependencies.
- Push vendors on explicit consent. Any AI coding assistant that executes commands from project configurations must require a clear, separate yes each time it wires into your toolchain.
Conclusion: stop treating AI assistants as harmless helpers
The uncomfortable truth is that AI coding assistants now sit at the intersection of your source code, local tools, and cloud credentials. They are part of your supply chain, not accessories. CVE-2026-12957 shows how thin the line is between convenience and compromise: a single config file in a cloned repo was enough to execute arbitrary commands and steal a developer’s cloud credentials with no extra interaction beyond opening the workspace. Even with patches in place and no known public exploitation, the attack idea will not disappear.
If you keep using AI assistants as though they were static linters, you will keep granting them runtime power without runtime scrutiny. The safer stance is blunt: no implicit trust for project configs that can launch processes. Make consent explicit, keep plugins updated, and audit every new place your AI tools can read configuration. Supply chain security risk is no longer confined to build pipelines and package registries; it now lives inside the “helpful” agents running inside your editor.
