Amazon Q auto-ran a repo's MCP config, exposing developer cloud keys
Wiz disclosed (June 26, 2026) that Amazon Q Developer auto-launched MCP servers from a repo config file with no consent, so opening a malicious project could run code and steal cloud credentials.
What is this?
On June 26, 2026, Wiz Research published a write-up of a high-severity flaw in Amazon Q Developer, Amazon’s AI coding assistant. The extension automatically loaded and launched Model Context Protocol (MCP) servers defined in a file inside the open project — .amazonq/mcp.json — the moment a developer opened the folder and activated Amazon Q. No prompt, no consent, no workspace-trust check. Because MCP servers are local processes the assistant spawns, and because those processes inherited the developer’s full environment, opening a booby-trapped repository could run arbitrary code with the developer’s live cloud session attached. Coverage followed from The Hacker News, and Amazon published Security Bulletin 2026-047-AWS.
The flaw was reported responsibly by Maor Dokhanian of Wiz: discovered April 17, reported to Amazon April 20, fixed May 12, and publicly disclosed June 26 — well past a coordinated-disclosure window, with a patch already shipped. AWS states there is no known public exploitation.
How it works
The problem is a trust-boundary confusion, not a clever payload. When you open a project folder in an IDE, you implicitly trust dozens of declarative config files — they describe behavior, they don’t execute code. MCP configuration breaks that assumption: an MCP entry names a command to run.
A benign MCP config looks ordinary — a command, its args, and an env block that a legitimate database or build tool would use. Amazon Q read that file straight from the workspace root and started the servers it listed, before the developer had reviewed a single line. Two design choices combined to make it dangerous:
- Auto-execution without consent. The config was loaded on folder open, with no dialog and no workspace-trust gate, so attacker-controlled text in the repo became a running process automatically.
- Full environment inheritance. The spawned process received the developer’s complete environment — cloud access keys, CLI session tokens, API secrets, SSH agent sockets — so whatever ran had the developer’s live credentials in hand.
No working payload is reproduced here; the mechanism is structural. In its proof of concept, Wiz simply had the launched command read the active cloud identity and send the result to an external server, demonstrating that a file in a cloned repo could pivot from “git clone” to cloud compromise. The same patched build also closed a second, related issue: a missing symlink check that could write files outside the workspace boundary — the same class as symlink-approval RCE in coding agents.
Why it matters
The runtime powering Amazon Q ships across VS Code, JetBrains, Eclipse, and Visual Studio, so every plugin that bundled an older copy was exposed. The precondition is a daily developer habit: clone an unfamiliar project — a tempting pull request, a typosquatted package, or a “coding test” sent during a fake job interview — and open it. That makes this a credible supply-chain path, the same family as Agentjacking and the coding-agent credential/identity gap, where untrusted repo content becomes a command executed with the owner’s rights.
Crucially, this is not one vendor’s mistake. Wiz and others documented the same shape across the ecosystem — Claude Code, Cursor, and Windsurf each had project-level MCP config turn into command execution by a slightly different route. Repo-carried configuration that silently configures an AI agent is a systemic anti-pattern, not a one-off bug.
Defenses
The durable fix is to treat any file that can live in a repository as untrusted input, and to require an explicit yes before it can run code.
- Update first. Amazon fixed the issue in Language Servers for AWS 1.65.0; the AWS bulletin advises moving to 1.69.0, which also carries the symlink fix. The language server auto-updates unless the network blocks it — reloading the IDE pulls the latest build. Patched plugin minimums: VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, Visual Studio toolkit 1.94.0.0.
- Gate MCP servers behind consent. Loading an MCP server from workspace config should always prompt. When your assistant flags an untrusted MCP server, read the command before allowing it, and reject anything you did not add.
- Strip the environment. Child processes should get the minimum environment they need, never the full set. Keep cloud keys and
~/.ssh/~/.awsout of reach of anything an agent spawns. - Distrust unfamiliar repos. Check for unexpected
.amazonq/(or equivalent agent-config) folders before opening a project, and never point an agent at a fork’s pull request unattended. - Adopt workspace trust. Use the IDE’s workspace-trust feature so untrusted folders cannot execute extension behavior automatically.
Status
| Item | Reference | Date | Notes |
|---|---|---|---|
| Auto-execution flaw | CVE-2026-12957 (CVSS 8.5) | 2026-06-26 disclosed | Amazon Q loaded workspace MCP config with no consent |
| Symlink write flaw | CVE-2026-12958 | 2026-06-26 disclosed | Missing symlink check; fixed in same build |
| Fixed in | Language Servers for AWS 1.65.0 (AWS advises 1.69.0) | 2026-05-12 fix shipped | Auto-updates unless network-blocked |
| Discoverer | Maor Dokhanian, Wiz Research | 2026-04-17 → 2026-06-26 | Coordinated disclosure; no known public exploitation |
| Same class | Claude Code, Cursor, Windsurf | 2025–2026 | Project-level MCP config → command execution |
The honest framing is not “an AI tool had a bug” — it is that repo-carried config that configures an AI agent is executable input, and turning it into a running process must take an explicit human yes. Until agents gate that handoff by default, the defense is yours: patch, require consent for MCP servers, strip the environment, and treat every unfamiliar repository as untrusted code.