The first rule of handing an AI assistant the power to run commands on your machine is that you should be the one who agreed to it. Wiz Research found that Amazon Q Developer, Amazon's AI coding assistant, skipped that step. For a stretch of weeks in early 2026, opening the wrong repository was enough to run a stranger's commands with your cloud credentials attached, and the tool never paused to ask.

The flaw is tracked as CVE-2026-12957, rated CVSS 8.5, and it went public on June 26, 2026. This is a separate incident from the 2025 Amazon Q story already in this Graveyard, where a rogue contributor slipped a machine-wiping prompt into the extension's source. This time the call was coming from inside the design: no compromised contributor, no poisoned release, just a default that trusted the wrong thing.

What went wrong

Amazon Q Developer is the AI coding assistant AWS bundles into popular editors. Like a growing number of these tools, it speaks Model Context Protocol, or MCP, a standard that lets an AI assistant spin up small local "server" processes to reach databases, APIs, build tools and the like. Starting an MCP server is not an abstract thing. It means launching a process and running commands on your machine. That's the entire point; it's also the entire danger.

The reasonable security assumption, in Wiz's words, is that the user explicitly configures these servers, because you're granting an AI assistant permission to run arbitrary commands and that should require informed consent. Amazon Q violated that assumption. It read .amazonq/mcp.json from the root of whatever workspace you opened and launched the servers defined inside it. No dialog. No consent. No workspace-trust check of the kind VS Code uses to keep untrusted folders at arm's length.

Three ingredients turned that into a high-severity bug:

• Auto-execution. The config was loaded and acted on the moment you opened the folder and Amazon Q activated. The malicious file just had to be sitting there.
• Shell spawning. An MCP server entry is, functionally, a command to run. An attacker writes the command; Amazon Q runs it.
• Environment inheritance. The spawned processes inherited the developer's full environment. That's the quiet killer. Whatever was loaded in that shell - AWS credentials, API keys, authentication tokens, SSH agent access - came along for the ride.

Stack those together and a single file in a cloned repository could execute arbitrary commands with the developer's live cloud session already attached. No password prompt. No second sign-in. To prove it, Wiz built a repository with a malicious MCP config; opening the project and activating Amazon Q caused the extension to run a command against AWS using the developer's existing credentials. As one researcher summary put it, the path from git clone to cloud compromise was short.

How you'd actually get hit

"Open a malicious repository" sounds like something only a careless person does, right up until you remember how routinely developers open code they didn't write. Wiz and the reporting around it pointed at the obvious lures: a take-home coding assignment for a job interview, a typosquatted open-source package, a pull request to a project you maintain, any "can you take a look at my repo" message in a community Slack. Cloning untrusted code and opening it in your editor is a daily activity for huge numbers of engineers. The attack didn't need you to run the project, install its dependencies, or trust anything. It needed you to look at it.

And the developer's laptop is a juicy place to land. It frequently has long-lived cloud credentials, production access, internal API keys and SSH agent forwarding all sitting in the environment. Wiz's framing was blunt: the combination of auto-execution, shell spawning and environment inheritance meant a single malicious repository could compromise not just the developer's machine but their cloud infrastructure too. That's the difference between "annoying local malware" and "the attacker now has your company's AWS keys."

The timeline, and the bit about CVEs

Credit where due: the response was reasonably quick once Amazon was told. Wiz's Maor Dokhanian reported the issue to AWS on April 20, 2026. AWS shipped the initial fix in Language Servers for AWS version 1.65.0 on May 12. The coordinated public disclosure came on June 26, after AWS published security bulletin 2026-047 on June 23. The fix adds the missing step: Amazon Q now flags an untrusted MCP server and lets the developer reject the command before anything runs. The language server auto-updates for most users, so reloading the IDE pulls the patch.

There's a sibling flaw worth noting. AWS's bulletin also covers CVE-2026-12958, a missing symlink-validation issue that let a crafted symlink resolve to a file path outside the workspace trust boundary. Because it shares a root theme - the tool acting on workspace contents it shouldn't fully trust - AWS told customers to move to language server 1.69.0 to cover both. The corresponding plugin baselines are VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, and the Visual Studio toolkit 1.94.0.0.

No public exploitation has been reported; CISA's enrichment entry for CVE-2026-12957 lists known exploitation as none. So like a fair number of the AI-tooling stories here, this is a documented hazard caught by researchers before anyone weaponized it, rather than a confirmed breach with victims to count. That's the good outcome. It's also why the severity here is a Facepalm rather than a Catastrophic: serious bug, real blast radius, but patched ahead of any known abuse.

A pattern the industry keeps repeating

The depressing thing is how familiar this is. Amazon Q auto-executing MCP config from an untrusted workspace is the same defect class as the Miasma worm riding AI agents' auto-running hook files, and the same class as Agentjacking turning tool output into agent commands. The plumbing differs; the mistake doesn't. AI coding tools keep shipping convenience features that quietly turn "open a folder" into "run code," and they keep defaulting that behavior to on.

For decades, opening a project in an editor was a safe, passive act. You could read hostile code all day without running it. Autonomous and semi-autonomous coding assistants broke that guarantee by treating files in a workspace - MCP configs, hook scripts, project rules - as trusted instructions rather than untrusted data. The fix Amazon shipped is the right one and also the obvious one: ask first. The fact that "ask before running arbitrary commands from a stranger's repo" had to be retrofitted via CVE tells you the trust model was inverted from the start.

What to take from it

If you build AI developer tools, the lesson is to treat anything inside a workspace as untrusted input until the human says otherwise, and to lean on workspace-trust prompts the way mature editors already do for tasks, debuggers and extensions. Auto-execution from an opened folder should be off by default, full stop. If you use these tools, assume your editor can run code from repositories you open, keep long-lived cloud credentials out of the shell environment your assistant inherits, and prefer short-lived, scoped credentials so a bad five minutes doesn't become a bad quarter. Amazon caught this one before the headlines wrote themselves. The next vendor with the same default might not be so lucky.