All posts
Unproven Execution

Amazon Q's MCP Loader: One Repo File, Full Cloud Reach

CVE-2026-12957 (CVSS 8.5): Amazon Q's VS Code extension auto-launched MCP servers from a workspace's .amazonq/mcp.json with no Q-side consent gate

Securityv0 Intelligence Team OWASP: ASI05 sv0 finding: unproven_execution
amazon-q mcp vs-code ai-coding-agent unproven-execution cve-2026-12957

The Incident

On 2026-06-26, AWS and Wiz Research jointly disclosed CVE-2026-12957 (CVSS 8.5) in Amazon Q Developer, alongside the companion path-traversal flaw CVE-2026-12958. The bug sits in Language Servers for AWS, the runtime under every Amazon Q Developer IDE plugin (VS Code, JetBrains, Eclipse, Visual Studio). When a developer opened a folder containing a .amazonq/mcp.json file at the workspace root, Amazon Q’s MCP loader auto-started every server defined in that JSON immediately, with no Amazon-Q-side consent dialog of its own. The spawned process inherited the developer’s full environment — AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, CLI tokens, and the SSH agent socket — turning a cloned repository into a one-step cloud-credential exfiltration path.

Wiz researcher Maor Dokhanian discovered the flaw on 2026-04-17 and reported it to Amazon on 2026-04-20. AWS shipped an initial server-side mitigation in Language Servers for AWS 1.65.0 on 2026-05-12 and the full fix in 1.69.0, with patched plugin versions VS Code 2.20+, JetBrains 4.3+, Eclipse 2.7.4+, and AWS Toolkit for Visual Studio 1.94.0.0+. The fixed loader prompts the developer before starting any workspace-defined MCP server. AWS reports no observed in-the-wild exploitation as of the 2026-06-26 public disclosure.

MITRE ATT&CK coverage: T1059 (Command and Scripting Interpreter), T1552.001 (Unsecured Credentials: Credentials in Files).

The Authority Path That Failed

The identity at the moment of failure was the developer’s local user session, with Amazon Q Developer running as an IDE extension under that session’s process tree. The scope it held was the developer’s full local credential graph — AWS profile keys and SSO session tokens, kube and cloud CLI tokens, GitHub tokens reachable through the SSH agent socket, and every environment secret VS Code inherited at launch. The scope the developer intended the agent to exercise when opening a repo was “AI coding assistance over open files.” The scope it actually exercised on .amazonq/mcp.json parse was “spawn arbitrary child processes named by a JSON file checked into the repository.”

The trust anchor that failed first was Amazon Q’s MCP registration model. Q’s design treated MCP server configuration as a user-authored, machine-local artifact — the canonical path is ~/.aws/amazonq/mcp.json. The loader, however, treated a workspace-local .amazonq/mcp.json as equally authoritative, with no per-tool prompt and no workspace-trust check of Q’s own. Trusting a folder to read its code was sufficient to spawn every subprocess that folder named. The gap between held scope (full developer env) and exercised scope (arbitrary subprocess) was statically visible at build time: a default-deny prompt on the first MCP load from any workspace-relative path would have surfaced it.

SecurityV0 Perspective

This is unproven_execution (ASI05): an AI agent shipped with code-execution capability gated only by a trust check the operator never made. It is also the fourth instance in eight months of the same authority-shape failure across coding-agent vendors — Claude Code (CVE-2025-59536), Cursor (CVE-2025-54136, the “MCPoison” bypass), Windsurf (CVE-2026-30615), and now Amazon Q. The pattern: an agent’s MCP loader overloads “workspace trust” — meant to gate reading code — into a gate for spawning subprocesses, because the loader treats workspace-controlled config as authorized configuration.

The evidence pack SecurityV0 would produce for this class names every IDE-resident agent on developer hosts (Amazon Q, Cursor, Claude Code, Copilot, Windsurf), each agent’s workspace-config search paths (.amazonq/mcp.json, .cursor/mcp.json, .claude/settings.json), the env each runs under (which AWS profile, which kube context, which SSH agent socket), and a mapping from each agent’s “spawn a subprocess” capability to whether the operator explicitly registered each tool versus inherited it from a workspace file. Pre-incident, that pack answers: “if a developer opens a hostile repo today, what executes before they read a line of code?” Post-incident, it answers: “which clones, on which hosts, in which time windows, granted which agent unauthorized subprocess authority — and which AWS credentials sat in that process’s env when it ran?”

What To Do

  • Force Language Servers for AWS 1.69.0+ on every developer host. Don’t trust IDE auto-update. Audit the installed version per plugin (VS Code 2.20+, JetBrains 4.3+, Eclipse 2.7.4+, AWS Toolkit for Visual Studio 1.94.0.0+) and pin a minimum via your endpoint-management tool. Roll a sweep across hosts to confirm — silent partial fixes shipped on 2026-05-12.
  • Treat workspace-local MCP configs as untrusted by default. Any .amazonq/mcp.json, .cursor/mcp.json, or .claude/settings.json arriving in a clone should fire an alert before the IDE opens the folder. A pre-clone or pre-open hook that inventories these files and requires an explicit operator decision per project is cheaper than auditing them after the fact.
  • Stop materializing long-lived AWS keys in the IDE process environment. Move developer credentials to short-lived IAM Identity Center sessions via aws sso login so a compromised subprocess holds a session that expires, not a static AWS_ACCESS_KEY_ID. Audit ~/.aws/credentials for static keys still in use and rotate every one that has been resident on a host that opened an untrusted repo since 2026-05-12.
  • Maintain an org allow-list of permitted MCP server binaries. A signed list of binary paths and hashes that each AI coding agent may spawn — checked in the agent’s pre-launch hook, not in post-hoc EDR — turns “open a hostile workspace” into a rejected launch, not a forensic question. Reject everything else, including same-named binaries at unexpected paths.
  • Alert on IDE-parented child processes that aren’t on the allow-list. Process-tree telemetry where code, idea, cursor, or other IDE binaries spawn a child outside the allow-list, with a working directory inside an untrusted clone, is a deterministic signal. It beats trying to detect malicious .json files heuristically.

Sources

All posts