SURIQ
A developer's editor has quietly become one of the most privileged machines in an organization. It holds live cloud session tokens, SSH keys, and API secrets, and it routinely opens code written by strangers. Wiz Research showed on June 26 that those two facts collide badly inside Amazon Q Developer: a single file dropped into a Git repository could run as the developer, with the developer's AWS session attached. No second login, no exploit chain. Open the repo, and the attacker's process is already running with your keys.
Amazon has patched it. There is no sign anyone used it in the wild, and it is not on CISA's exploited list. The bug itself is almost beside the point. What matters is the shape of it, because the same shape keeps appearing across every AI coding tool shipping right now.
What actually broke
The flaw, CVE-2026-12957 (CVSS 8.5), sat in how Amazon Q handled the Model Context Protocol (MCP), the standard that lets an AI assistant talk to external tools. When you opened a project, Amazon Q looked for a file named .amazonq/mcp.json inside it and started whatever MCP servers that file listed. Those servers are ordinary local processes, and they inherited the full environment of the editor that launched them.
On a working developer's machine that environment is a treasure chest: whatever AWS keys the person is currently signed in with, the cloud CLI tokens, the API secrets, and the SSH agent socket their own shell can already reach. So a config file committed to a repository could name a command, Amazon Q would run that command for you, and the command would carry your cloud identity. Wiz described a chain that begins at a routine clone and ends inside the cloud account, which is exactly what it is.
Affected versions and the fix
The vulnerable code lives in a component Amazon calls Language Servers for AWS, the engine that drives Amazon Q inside every editor it supports: Visual Studio Code, the JetBrains family, Eclipse, and Visual Studio. The first fix shipped in version 1.65.0 on May 12, but Amazon's bulletin tells customers to move to 1.69.0, which also closes a second issue, CVE-2026-12958, a gap in symlink handling that let file writes escape the workspace boundary.
The plugin floors Amazon lists are specific: Visual Studio Code at 2.20, JetBrains at 4.3, Eclipse at 2.7.4, and the Visual Studio toolkit at 1.94.0.0. Anything below those still carries the bug. The runtime is supposed to update itself on reload, but that quiet auto-update is also the trap. On a machine that blocks the update endpoint, or one that rarely restarts the editor, the language server can sit on an old build while the developer assumes the assistant fixed itself. Auto-updating and patched are not the same claim, and only one of them is verifiable.
The trust prompt was never meant to carry this weight
Editors already ship something that sounds like the answer: workspace trust, the dialog that asks whether you trust the folder you just opened. Amazon's fix leans on the same idea, popping a prompt that lets the developer refuse a repo-supplied MCP server before anything starts. That is the right immediate move. It is also asking an old control to do a job it was never designed for.
Workspace trust was built to gate a narrow set of actions, mostly task runners and debug configurations. It was not built to be the sandbox for an autonomous agent that reads arbitrary files in a repo and spawns long-running processes carrying your identity. Bolting a yes-or-no dialog onto that is a stopgap, and the next failure is easy to predict. A developer who clicks through twenty consent prompts a day will click through the twenty-first without reading it. Consent fatigue is the successor to this bug, not its cure.
This is a pattern, not a one-off
Strip the Amazon branding and you have seen this story here before. An AI agent that trusts its own localhost turned a web page into a takeover. A rigged container image seized root through Docker's MCP tooling. The app under test hijacked the AI agent testing it through an Appium MCP flaw. Prompt injection inside Microsoft 365 Copilot reopened doors people thought were shut, and IDE plugins have been quietly skimming AI API keys. Different vendors, one root cause: agentic tools keep erasing the line between data they read and instructions they execute.
The MCP config file is the clearest example yet. It looks like data, it sits in a repo like data, and it silently becomes executable the moment a trusting agent reads it. That is the same trap that made project files and build scripts dangerous a decade ago, except the process that runs now holds a live cloud session instead of a local shell. The blast radius moved from the laptop to the account.
What to do this week
Treat this as same-week work if your team uses Amazon Q, even with nothing exploited yet. The window between a silent fix and a public writeup is exactly when attackers start reading the patch.
- Update and verify. Move Language Servers for AWS to 1.69.0 and confirm the running build in the IDE. Do not assume the reload took or that the auto-updater reached the machine.
- Scope the credentials, not just the tool. The deeper fix is that an editor should not be holding long-lived cloud keys at all. Issue short-lived, scoped session credentials to developer machines, and stop passing your full shell environment into child processes by default.
- Hunt for the behavior. Look for the language server or IDE process spawning unexpected children, reads of
.amazonq/mcp.jsonin repositories your team did not author, and fresh outbound connections from a developer host right after a clone. - Scan repos for agent config. Add a check in CI or a pre-clone hook for
.amazonq/and the equivalent config directories of other AI assistants, the same way you already scan for secrets.
The uncomfortable part is that Amazon did everything right: fast triage, a real fix, coordinated disclosure with the timeline laid out in public. The bug still existed because the industry is shipping agents that act with a developer's full authority before anyone has agreed where the guardrails go. Until that settles, the safe assumption is that any file an AI assistant reads can run. Review the config files in your repos the way you review the code.