Amazon Q Developer MCP Auto-Execution: Git Clone to Cloud Compromise (CVE-2026-12957)
Opening a malicious repository in VS Code was enough to steal a developer's AWS credentials. Amazon Q Developer silently read a repository's <code>.amazonq/mcp.json</code> file, spawned the MCP servers it defined, and those processes inherited the developer's full environment, including AWS access keys, session tokens, and API secrets. Wiz Research built a proof of concept: one file, one git clone, zero prompts. Amazon fixed it in May and disclosed publicly in June. A second CVE, CVE-2026-12958, covered a related symlink validation gap that allowed arbitrary file writes outside the workspace boundary.
What happened
Amazon Q Developer's VS Code extension connects AI-assisted coding to local tools via MCP. When a developer opens a workspace, the extension reads .amazonq/mcp.json and starts the MCP servers it lists. That is the intended flow, and it is fine when the configuration comes from a project you own and trust.
CVE-2026-12957 is what happens when the configuration comes from a repository you just cloned. Amazon Q loaded the file and launched the servers without a separate consent step for the MCP configuration itself, treating the workspace trust prompt as sufficient. Wiz Research identified the gap: the security model assumed the user had explicitly chosen to configure those servers. The vulnerability arose when that assumption was violated for a file an attacker could control from outside the organisation.
MCP STDIO servers are child processes. Child processes inherit their parent's environment. In a developer's terminal that environment typically includes AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, SSH agent sockets, and whatever API tokens are set for the current project. Wiz's PoC ran aws sts get-caller-identity and exfiltrated the output. No pop-up, no warning, no indication anything had happened.
CVE-2026-12958, fixed in the same release cycle, was a missing symlink validation that allowed the spawned MCP process to write files outside the workspace trust boundary. Amazon's language server powers Amazon Q across four IDEs, so all four were exposed by versions that bundled a pre-patch copy. The fix in Language Servers for AWS 1.65.0 added an explicit consent gate before MCP servers from an untrusted workspace are allowed to run; 1.69.0 is the recommended target and also closes the symlink issue.
The PolicyLayer angle
This attack works because MCP STDIO servers are processes, and processes inherit credentials. The policy question is not whether Amazon Q had a bug; it did and it is fixed. The question is what stops the next tool that ships MCP support without getting this consent boundary right, because the pattern is not vendor-specific. OX Security found the same mistake in Windsurf, Gemini CLI, and others within the same disclosure window.
The control that breaks this attack regardless of whether the IDE enforces workspace trust correctly is a deny-by-default policy on MCP server launches from unverified sources. Specifically: MCP STDIO servers should not launch from repository-local configuration files unless the repository has been explicitly added to a trust list by an administrator or developer. That is a separate approval from trusting the workspace; it is approval to execute code on behalf of the user, which is a materially higher bar.
Scoped credential injection is the second line. If the MCP process's environment does not contain production AWS keys, the PoC is a no-op. Running Amazon Q with short-lived, task-scoped credentials rather than ambient developer credentials limits the blast radius to the current task, not the entire cloud account. These two controls together are stronger than any single vendor getting workspace trust exactly right on the first shipping version.
Mitigations
Update to Language Servers for AWS 1.69.0 or later and reload your IDE. Auto-update applies the patch on restart for most users. Rotate any AWS credentials that were active in a developer environment where a repository of uncertain provenance was opened between roughly October 2025 and May 12, 2026. Audit .amazonq/mcp.json files in repositories before opening them in Amazon Q-enabled IDEs. Treat repository-local MCP configuration files as untrusted code, not declarative configuration.
FAQs
No. The attack requires opening a repository that contains a malicious .amazonq/mcp.json file. Developers working exclusively in their own codebases or in repositories from known-trusted organisations are not affected by the original vector. The symlink issue in CVE-2026-12958 could affect more configurations but is also patched in 1.69.0.
MCP has no standard definition of workspace trust. Each vendor implemented their own version of 'should I execute this configuration file?', and several arrived at the same wrong answer: treat workspace trust as sufficient consent for MCP server launch. OX Security found the same class in Windsurf; Check Point found it in Claude Code. The bug is the same; the products are different.
Yes, if you confirm the attack has not been used to create persistent IAM resources. The PoC captured ambient credentials and exfiltrated them; it did not modify infrastructure. Rotate the affected key pair, revoke any active sessions, and review CloudTrail for anomalous calls during the exposure window.
References
- Amazon Q Vulnerability: Compromise via MCP Auto-Execution↗
- Amazon Q Developer Flaw Could Let Malicious Repos Run Code via MCP Configs↗
- Amazon Q flaw let booby-trapped Git repos execute code, swipe cloud creds↗
- Amazon Q Developer Vulnerability Allows Cloud Credential Theft via Malicious Repositories↗