A Config File With Too Much Power
Security researchers at Wiz disclosed this week that Amazon Q Developer, the AI coding assistant embedded in popular IDEs, contained a flaw that turned an ordinary repository into a launchpad for cloud compromise. Tracked as CVE-2026-12957 with a CVSS score of 8.5, the vulnerability lived in how Q handled Model Context Protocol servers. A repository could ship a configuration file at the path dot amazonq slash mcp dot json. When a developer opened that repository and trusted the workspace, Q would obediently start every MCP server defined in the file, without asking for consent server by server.
What made the flaw dangerous was inheritance. Those servers ran with the developer's full environment, which on most engineering laptops means AWS credentials, cloud CLI tokens, and a small library of secrets that never should leave the machine. As Wiz summarized the impact, a single config file dropped in a repo was enough to go from git clone to cloud compromise. We have seen plenty of supply chain attacks that depend on a victim running a build. This one needed nothing more than opening a project, the most reflexive action a developer performs in a day.
Why AI Assistants Are a New Class of Privileged Software
The instinct among many security teams is to file this under AWS problems and move on. We think that is the wrong reading. The deeper issue is that AI coding assistants have quietly become privileged software running inside the most trusted process on an engineer's machine. They read source, write files, execute commands, and increasingly orchestrate external tools through protocols like MCP. Each of those capabilities is useful, and each one expands the blast radius when the assistant can be steered by attacker controlled input sitting in a repository.
This is the part that should give CIOs pause. The credentials at risk were not stored insecurely. The developer did nothing reckless beyond cloning a project and clicking trust. The vulnerability emerged from the gap between what users think a trust prompt means and what it actually authorizes. A prompt that reads like a courtesy turned out to be the only thing standing between an untrusted file and command execution with cloud reach. When the consent model is that thin, the assistant is effectively running attacker code with the keys to production.
How the Exploit Actually Worked
The mechanics are worth understanding because they generalize. MCP is a standard that lets an AI client connect to external tools and data sources through small server processes. Configuration tells the client which servers to start and how. Amazon Q read that configuration from the repository itself, then launched the servers automatically once the workspace was trusted, passing along the environment it was running in. A malicious server could therefore read environment variables, call cloud APIs with the inherited tokens, and exfiltrate whatever it found.
AWS addressed the root cause by changing the consent flow. The patched releases require Language Servers for AWS version 1.69.0, with minimum plugin versions of VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, and Visual Studio 1.94.0.0. Critically, the fix introduces a separate consent step for untrusted MCP servers, so trusting a workspace no longer silently authorizes arbitrary server execution. Wiz reported the flaw on April 20 and AWS shipped the fix on May 12, a reasonable turnaround for a vulnerability of this severity.
The Disclosure Timeline and What It Signals
The roughly three week gap between report and patch is encouraging, and the public writeup landing in late June gives defenders time to verify their fleets are updated before exploitation becomes commodity. We would not assume that window stays open. Proof of concept details for MCP abuse are now circulating, and the pattern of dropping a poisoned config into a public repository is trivially repeatable. Any organization that allows AI assistants on developer machines should confirm the minimum plugin versions are enforced through their endpoint management rather than left to individual updates.
There is also a secondary vulnerability, CVE-2026-12958, bundled into the same advisory, which reinforces that the MCP handling surface had more than one weak spot. When a feature area produces multiple CVEs in a single disclosure, it usually means the design assumed a level of input trust that no longer holds. We expect more findings in this space as researchers turn their attention to how assistants broker tools, and we expect vendors to keep tightening consent flows in response.
What Security Leaders Should Do This Week
The immediate action is mechanical: inventory every machine running Amazon Q Developer, push the patched plugin versions, and verify the Language Server floor of 1.69.0. The harder work is policy. Treat AI coding assistants as a managed software category with their own update SLAs, allowlists, and configuration baselines, the same way you would treat a VPN client or an endpoint agent. If an assistant can execute code and reach cloud APIs, it deserves that scrutiny regardless of how productive it makes the team.
Beyond the specific product, this is a prompt to revisit credential hygiene on developer endpoints. Long lived AWS keys sitting in environment variables are exactly the prize this flaw exposed. Short lived credentials brokered through identity providers, scoped down to least privilege, would have blunted the impact even if the assistant misbehaved. The uncomfortable truth is that the convenience of having cloud tokens always present in the shell is the same convenience attackers are learning to harvest through the AI layer.
A Preview of the Agentic Attack Surface
We read CVE-2026-12957 as an early entry in a genre that will define the next few years of application security. As assistants gain the ability to call tools, run subagents, and act with delegated authority, the boundary between reading untrusted content and executing untrusted intent keeps eroding. The repository was the delivery vehicle here, but the underlying weakness, an agent that trusts its inputs too readily, will reappear in browsers, ticketing systems, email, and anywhere else an assistant ingests data it did not author.
For boards asking whether AI tooling is safe to adopt, the honest answer is that it is adoptable with discipline. The productivity gains are real, and pulling assistants out of the workflow is neither practical nor wise. What changes is the operating model: assistants must be patched aggressively, scoped tightly, and assumed to be a potential conduit for attacker controlled input. The organizations that internalize that now will avoid learning it the hard way when the next config file shows up in a repository they trusted.
