The Amazon Q developer vulnerability disclosed last week (CVE-2026-12957, CVSS 8.5) is getting coverage as a patched VS Code extension flaw. It deserves a wider reading. The bug was fixed in May. But the conditions that created it still exist across AI coding tools, and the patch alone does not explain why the same mistake appeared in at least three products from three separate vendors.
The Amazon Q Developer Vulnerability in Brief
Amazon Q automatically executed MCP (Model Context Protocol) server configurations embedded in any repository a developer opened. The servers ran as child processes. Child processes inherit the parent’s full environment, including AWS credentials and API tokens. Wiz Research published a proof of concept: one malicious .amazonq/mcp.json file, one aws sts get-caller-identity command piped to an attacker server, zero user prompts. Amazon patched this on May 12, 2026, updating the language server to version 1.65.0. The fix adds a consent prompt before MCP configs are loaded.
The disclosure came on June 26, 2026. Update your Amazon Q extension to language server 1.65.0 or later and reload VS Code if you have not done so since mid-May.
Why This Keeps Happening
This Amazon Q developer vulnerability is the latest in a cluster. Check Point Research disclosed CVE-2025-59536 and CVE-2026-21852 in Claude Code. OX Security disclosed CVE-2026-30615 in Windsurf. Google also patched a code execution flaw in Gemini CLI last year. Each case traced back to the same design decision: workspace configuration files in a repository were treated as trusted and executed without requiring user consent.
These are not bugs that slipped through code review. They are the predictable result of shipping MCP support fast, without a shared baseline for what “workspace trust” means. The Model Context Protocol itself does not define one. So each vendor built their own version, and several got it wrong in the same direction.
The push to ship MCP integration mattered commercially. But the protocol specification never said “require explicit user approval before executing workspace configurations.” Some vendors added that control anyway. Others did not. Those are the ones generating CVEs now.
What a Trust Model Should Look Like
VS Code has had a workspace trust system since 2021. When you open a folder from an unfamiliar location, the editor asks whether you trust it before enabling features that can run code. The model is not perfect, but it is explicit. Extensions that handle dangerous operations should hook into that system instead of building their own.
For AI tools with MCP support, the minimum bar should be this: any configuration file that spawns a process or makes network requests needs explicit user approval first. Not a global toggle. Not a warning dismissed at install time. A per-workspace consent check on the specific commands about to run. Amazon’s fix for the Amazon Q developer vulnerability moves in this direction. The question is whether every other MCP-capable tool gets there on its own, or whether a coordinated standard makes the safe path the default.
The Attack Surface This Creates
Developer machines are high-value targets. They hold cloud credentials, reach internal services, bypass perimeter controls, and are trusted by CI/CD pipelines. A malicious repository that runs code the moment a developer opens it is not theoretical. It is a practical supply-chain attack. It needs no elevated privileges and no social engineering beyond getting someone to clone a repo.
Public GitHub repositories, pull requests, and shared project templates are all delivery vectors. So are dependency repositories where an attacker adds a benign-looking commit that plants an .amazonq/mcp.json file. Where developers have AWS access to production environments, that translates to cloud infrastructure access at scale.
The Right Response Is Not Just Patching
Applying the Amazon Q update is the immediate step. But security teams should also inventory which AI coding tools are installed across their developer fleets. For each one, ask the vendor directly: does your product execute workspace configuration files without per-workspace user consent? If the answer is not a clear yes, that product needs a closer look before it reaches production developer environments.
The MCP auto-execution cluster is a signal for anyone evaluating new AI tools. Support for a new protocol says nothing about the security of its implementation. The question to ask before adopting any tool that reads from a repository: what does it do with those files, and when does it do it?
