Amazon Q VS Code MCP Auto-Execution - CVE-2026-12957

CVE-2026-12957 is a High-severity vulnerability in the Amazon Q Developer extension for Visual Studio Code, disclosed by Wiz Research on June 26, 2026. The flaw let a malicious repository run arbitrary commands on a developer's machine the moment the folder was opened - with no prompt, no consent, and no workspace-trust check - by abusing how Amazon Q auto-loaded Model Context Protocol (MCP) server configurations. Because spawned processes inherited the developer's full environment, a minimal proof-of-concept exfiltrated live AWS session credentials with no clicks and no warning. It affects the shared Language Servers for AWS before version 1.65.0 and was fixed in a language-server update deployed around May 12, 2026. This advisory covers what happened, why it is an agentic-endpoint problem rather than a single-product bug, and how Anomity surfaces and governs the MCP and AI-tooling layer it lives in.

What happened

Amazon Q Developer is Amazon's AI coding assistant, delivered as an IDE extension and powered by a shared component called Language Servers for AWS. Wiz Research found that the extension automatically read and loaded MCP server configurations from a .amazonq/mcp.json file inside the open workspace. There was no approval dialog, no consent prompt, and no check against the editor's workspace-trust model. Any MCP server declared in that file was started as soon as the folder opened.

MCP servers over the stdio transport are launched as local child processes, and here those processes inherited the developer's complete environment. That environment routinely holds AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN, along with cloud CLI tokens, API keys, and SSH agent sockets. An MCP server entry in .amazonq/mcp.json is just a command and its arguments, so whatever an attacker placed there ran with all of that within reach.

The attack needed no social engineering beyond getting a developer to open a repository. An attacker commits a .amazonq/mcp.json to a public project, a dependency, or a pull request; the developer clones it and opens the folder; the declared command executes silently with the developer's credentials and cloud access. Wiz's proof-of-concept did exactly this, sending active AWS session credentials to an attacker-controlled endpoint with no clicks, no prompts, and no warning. From arbitrary execution on a developer laptop, the realistic follow-on is cloud credential theft across AWS, GCP, and Azure, persistence, lateral movement, and supply-chain risk to anything that developer can push to.

Amazon fixed the issue in Language Servers for AWS 1.65.0, deployed around May 12, 2026, roughly a month before the public write-up. The patched behavior prompts for explicit consent before loading MCP servers from a workspace configuration and restricts the environment variables those servers can see. A related symlink-validation flaw, CVE-2026-12958, was addressed in the same remediation effort, so updating to the latest Language Servers for AWS release is the safe baseline. The language server auto-updates in most setups when the IDE reloads. This is the second significant issue reported in this product in recent memory, after the prompt-injection wiper incident - same tool, a different failure mode.

Why this is an agentic-endpoint risk

The bug that mattered was not in a network service or a known-bad binary. It was a trusted, signed IDE extension doing precisely what it was built to do - reading its own configuration file and starting the tools that file declared. The malicious intent lived in workspace data, .amazonq/mcp.json, committed to a repository. That is the defining shape of the agentic-endpoint problem: capability is defined in configuration that changes without review, and the thing executing it is a legitimate developer tool. It is the same trust-boundary failure behind Cursor's MCPoison workspace-trust bypass and CurXecute, and the stdio-execution class we cover in the LibreChat MCP advisory.

MCP is spreading precisely because it makes agents easy to wire into local tools, which is why auto-loading a workspace config felt like a convenience feature rather than an execution primitive. But an MCP server entry is a command to run, and a config file that runs commands on folder-open is an untrusted-code-execution surface. We walk through this trust model in Model Context Protocol security explained.

For a security team, the hard part is not the patch - it is knowing where Amazon Q is installed, which language-server version each instance runs, and whether any workspace on any endpoint still carries a pre-fix .amazonq/mcp.json. Endpoint EDR sees a signed extension starting a child process and has no reason to object. This is the blind spot Anomity was built to close.

How Anomity surfaces and governs it

Anomity's unprivileged Endpoint Sensor runs on Windows, macOS, and Linux and inventories eight AI artifact types - AI agents, MCP servers, extensions, plugins, skills, secrets, hooks, and CLIs. The Amazon Q extension and its CLI show up as artifacts, and each MCP server they can load is inventoried alongside them. Finding every endpoint running a language server before 1.65.0, and every workspace MCP configuration on disk, becomes one query rather than a fleet-wide hunt.

On agents that expose a hook - for example the PreToolUse event in Claude Code - Anomity applies runtime governance, returning allow, deny, or log on each MCP tool call before it runs. Where a client exposes that control point, a config-driven server launch that does not match policy is denied rather than trusted by default, so an unexpected MCP invocation is evaluated first instead of executed silently.

Every install, version change, and policy decision lands in a queryable 90-day audit trail, giving responders a precise exposure window - which machines ran a vulnerable version, and when. Anomity collects metadata only, with on-endpoint secret redaction, so the AWS keys and session tokens this flaw targets are never carried off the host by Anomity. Findings route to your SIEM, Slack, email, or Jira, and the platform is SOC 2 Type II. None of this replaces patching or your existing stack - it complements EDR, DLP, network, and GRC tooling at the AI-artifact layer they were never designed to see.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint for the Amazon Q Developer extension and CLI and record the Language Servers for AWS version; update anything before 1.65.0 to the latest available release.
• Confirm the language-server auto-update actually applied - reload each IDE and verify the running version rather than assuming it patched itself.
• Scan repositories and open workspaces for .amazonq/mcp.json files, especially in cloned third-party, dependency, or public projects.
• Treat any pre-fix .amazonq/mcp.json as suspect and review the commands and arguments it declared before opening the folder again.
• Rotate cloud credentials, CLI tokens, and API keys for any developer who opened an untrusted repository before the patch was applied.
• Verify the patched consent prompt is active and that MCP servers no longer start on folder-open without explicit approval.
• Set a fleet policy that MCP server configurations are reviewed like code, and that AI IDE extensions honor workspace trust before executing anything.
• Extend the same inventory-and-review approach to other AI coding tools, per securing AI coding agents and CLIs.

CVE-2026-12957 is a clean example of the thesis behind this research: AI agents and MCP servers are the new shadow IT, and you can't govern what you can't see. This advisory is part of our MCP Server Security guide, which covers workspace trust, the stdio execution pattern, and how to inventory and govern every server across your fleet - see also the most-adopted MCP servers of 2026. To see which endpoints in your own fleet run a vulnerable Amazon Q build and what runtime governance would deny, request early access.